Bug#1036826: Please start handling \c
severity 1036826 normal thanks please don't abuse the severity. po4a is not only for groff, and many groff pages do work without it. Instead, I'd appreciate if you could do a merge request with a test file, along with the expected output. It'd save me the time to dig into the discussion of this bug. I'm not saying that I won't fix it w/o this test case. I'm just saying that providing a test case is a better approach to speedup the fix than severity abuse. Thanks for your help, Mt Le samedi 09 mars 2024 à 12:39 +, Helge Kreutzmann a écrit : > severity 1036826 important > thanks > > Hello Martin, > you have been quite in this discussion. \c occurs in more and more man > pages, and currently the build fails for them. In turn, they are no > longer translated. > > Could you kindly check if you could add support for "\c" or is there > another workaround? > > Thanks for your support! > > Greetings > > Helge signature.asc Description: This is a digitally signed message part
Bug#1058645: Hare packages for Linux
Le mercredi 21 février 2024 à 14:50 +0200, Classic a écrit : > Hello everyone, > > I built deb package for Ubuntu 22.04 > https://alexey.nyc3.cdn.digitaloceanspaces.com/hare-dist/U22/hare_0.24.0-1_amd64.deb Hello, is the source package available somewhere? I happen to be a Debian developper and could upstream your work, maybe. For the reference, previous attempt was discussed here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058645 (for Hare) and here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058646 (for qbe). It would be nice if you could keep the 1058645 bug in CC when discussing of the Debian packaging, please. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#993557: ITP: gnome-shell-extension-pop-shell -- keyboard-driven layer for GNOME with tiling window management
Hello David, did you manage to do any progress on this package, please? Where can I see your current version? I'd like to help if possible. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1061234: po4a: Consider parsing the macros .PS and .PE
Hello, how should these macro be considered? Locale::Po4a::Man proposes options to handle macros that are not known to po4a. For example, if the content of this macro should be ignored, try adding "-o untranslated PS,PE" to the command line or alias definition in your config file. Other such options exist, such as translate_joined or translate_each, etc. HTH, Mt Le dimanche 21 janvier 2024 à 08:40 +, Helge Kreutzmann a écrit : > Package: po4a > Version: 0.69-1 > Severity: wishlist > Tags: upstream > > This is *really* low priority, but mayb its easy/simple. > > manpages-l10n hase one man page with groff graphics. The graphics are > included in the macros .PS and .PE which are stripped out from the > translated set. > > Maybe the strings within this macros could be added to the translated > set? > > More details and the full discussion (unfortunately with some side > discussions) can be found at: > https://savannah.gnu.org/bugs/?59962 > > > -- System Information: > Debian Release: 12.4 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-12 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-38 > ii libsyntax-keyword-try-perl 0.28-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl 5.36.0-7+deb12u1 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-5 > ii libterm-readkey-perl 2.38-2+b1 > ii libtext-wrapi18n-perl 0.06-10 > ii libunicode-linebreak-perl 0.0.20190101-1+b5 > > po4a suggests no packages. > > -- no debconf information > signature.asc Description: This is a digitally signed message part
Bug#1058645: Do you need help with this package?
Hello, I'm wondering whether you need some help with the packaging of Hare. Is your current state available somewhere? Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1036824: po4a: Describe how to create/maintain pot file from man page
tag 1036824 fixed-upstream thanks Hello Helge, I just revamped the po4a(7) documentation to better explain the workflow using po4a only, without po4a-translate and po4a-updatepo. The result is unreleased for now, but already viewable here: https://github.com/mquinson/po4a/blob/master/doc/po4a.7.pod#using-po4a This text refers to the documentation of po4a(1) itself, available from: https://po4a.org/man/man1/po4a.1.php In particular, I added a paragraph about the deprecation of the individual scripts that you may find useful: https://github.com/mquinson/po4a/blob/master/doc/po4a.7.pod#why-are-the-individual-scripts-deprecated I think that this closes the current bug (once the fix is integrated to Debian). Please comment if you think otherwise. Thanks for your feedback and support, Mt Le mardi 06 juin 2023 à 18:46 +0200, Helge Kreutzmann a écrit : > Hello Martin, > On Mon, Jun 05, 2023 at 11:32:04PM +0200, Martin Quinson wrote: > > Every po4a-* scripts are deprecated. The right way to go is to use the main > > po4a script, using an adequate config file. I think that this is documented > > in > > po4a(1), isn't it? > > Yes, po4a is documented, but not the work flow we use. The > documentation assumes an intial "run" with a previous translation and > then po4a. (See my report you cite below). signature.asc Description: This is a digitally signed message part
Bug#1020821: retitle 1020821 to Please implement a language fallback mechanism
retitle 1020821 Please implement a language fallback mechanism thanks Hello, I'm retitling the bug to match my understanding of the issue, but please feel free to correct me if I'm wrong. Thanks, Mt signature.asc Description: PGP signature
Bug#663148: po4a: Text (-o control=...) chokes on a normal dctrl file
Hello, I am sorry I didn't answer to this bug in all these years... The support for Deb822 files seems very limited right now. Beside of the bug you reported, it fails to handle folded entries, as your Info: fields where the first line is not specific and should be added to the content afterward. Comments are also badly handled. Etc etc. I think that the best would be to reimplement it from scratch. I'm not a big fan of reimplementing things from scratch, but the existing po4a parser for control files is 50 lines long only. Not a big loss. Do you guys know a good and simple parser of such files that would be written in Perl? If it's a library I'd reuse it, and if it's part of another program I'd copy/paste and adapt it to our use case. Given the time I can devote to this project despite IRL, I need to be efficient. Thanks, and sorry for the delay, Mt signature.asc Description: This is a digitally signed message part
Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation
Hello Osamu, after a long delay, I am back on po4a. I just commited something to po4a(7) to make it more explicit that po4a-gettextize should only be used when converting an existing project to po4a, and that po4a-update should be used (or even better: po4a) instead on a regular basis. I would appreciate if you could review the change: https://github.com/mquinson/po4a/commit/c8624368d69f5c5e75444baef5b8d42eb6dbab8d Re-reading the logs of this bug, I think that this could be sufficient to consider the bug as solved. Do you agree? Nevertheless, I'm interested in what seems to be a feature missing in po4a(1): > Please also realize that my Makefile also use opencc to translate > missing translation msgstr in PO files supplimenting between zh_CN and > zh_TW peacefully. po4a command has no way to do this either. Could you please tell me more about it? I'm wondering whether the section "Filtering the translated strings" of po4a(1) could be used to solve the issue you are facing. Or maybe what you need is a sort of fallback mechanism where the translation of language B could be used when not available in language A. I guess that this fallback could be useful to many people, such as danish and swedish, portuguese and brazilian, and other language pairs. But that's only my feeling and I prefer to have a confirmation of a given need before I start implementing something. Thanks for your feedback and have a good day, Mt signature.asc Description: This is a digitally signed message part
Bug#1055345: git-buildpackage: Please document how to build against a package from experimental
Le dimanche 12 novembre 2023 à 21:00 +0100, Guido Günther a écrit : > Hi, > On Sun, Nov 05, 2023 at 09:18:58PM +0100, Martin Quinson wrote: > > Le dimanche 05 novembre 2023 à 17:27 +0100, Guido Günther a écrit : > > > > > > > > What about suggesting to bootstrap a new environment instead via: > > > > > > DIST=experimental git-pbuilder create > > > > > > This also handles adding experimental to /etc/apt/sources.list (no extra > > > setup needed). Maybe we can streamline things that way a bit? > > > > This has the drawback of taking all dependencies from experimental, which > > may > > not be what one wants. > > Is that that the case? I didn't see where in the chroot that would be > configured. Can you point me to it? I must confess that I didn't experiment with this approach because I was afraid it would give me all packages from experimental while it was not what I wanted. Only afraid of, not sure at all. The truth is that I have no idea. I am sorry for the false info if I was wrong. Thanks for your time, Mt signature.asc Description: This is a digitally signed message part
Bug#1042642: ns3: FTBFS with Sphinx 7.1, docutils 0.20: make[6]: *** [Makefile:75: html] Error 2
Hello, thanks for your hard work investigating on this. I confirm that this fixes the build. I am currently relaunching the build with a proper changelog entry before uploading to unstable. The patch I came up with is here: https://salsa.debian.org/debian/ns3/-/blob/master/debian/patches/sphinx-7 Many many thanks for your help, I was not there at all. Mt Le lundi 06 novembre 2023 à 18:12 +0100, s3v a écrit : > Dear Maintainer, > > Problematic lines seem to be [1][2][3]. > After fixing all of them, I was able to build successfully your package in > a sid chroot environment. > > Kind Regards > > [1] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/models/source/conf.py/#L68 > [2] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/manual/source/conf.py/#L68 > [3] > https://sources.debian.org/src/ns3/3.40-1/ns-3.40/doc/tutorial/source/conf.py/#L66 signature.asc Description: This is a digitally signed message part
Bug#1042642: Why should a FTBFS against packages in experimental be serious?
package src:ns3 severity 1042642 serious thanks Indeed, your package is now in unstable. Thanks for this work. I'm discussing with my upstream to fix the problem, but so far they cannot reproduce the error. Since I'm optimistic, I guess that it's because the problem was fixed in the git version already. Again, thanks for your time, Mt Le samedi 04 novembre 2023 à 20:23 +0300, Dmitry Shachnev a écrit : > Hello Martin! > > On Sat, Nov 04, 2023 at 05:13:04PM +0100, Martin Quinson wrote: > > severity 1042642 important > > thanks > > > > Hello Dmitry, > > > > I am wondering why you raised the severity of #1042642 to serious. Did I > > miss > > the part of the policy document stating that packages *must* build > > correctly > > against packages in experimental? Or is there anything else that I'm > > missing, > > maybe? > > Please see my comment in the email that bumped severity [1]. It said that > I was going to upload new Sphinx to unstable the next weekend. > > I bumped the severity a bit earlier to notify the maintainers about the > upcoming upload and give them more chance to fix these bugs before the > packages actually start to FTBFS. > > Now a week has passed, and I am going to upload sphinx tomorrow, 2023-11-05. > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042642;msg=7 > > -- > Dmitry Shachnev signature.asc Description: This is a digitally signed message part
Bug#1055345: git-buildpackage: Please document how to build against a package from experimental
Le dimanche 05 novembre 2023 à 17:27 +0100, Guido Günther a écrit : > Hi Martin, > On Sat, Nov 04, 2023 at 04:43:10PM +0100, Martin Quinson wrote: > > Package: git-buildpackage > > Version: 0.9.32 > > Severity: wishlist > > Tags: patch > > > > Hello, > > > > thanks a lot for this package, that very often saves my life when > > packaging. > > There is one thing however where gbp could be more helpful, it's when I > > have to > > build my package against a build-depend that comes from experimental. > > > > I finally found a way to do it, and I propose the following patch for the > > documentation for the next person looking for this information. I fully > > acknowledge that this documentation is somehow suboptimal, and that the gbp > > tool could be more helpful here, but the proposed documentation would > > already > > be great. > > Thanks for taking the time to document this. Some minor nits below: > > > > --- > > docs/chapters/special.xml | 25 + > > 1 file changed, 25 insertions(+) > > > > Index: b/docs/chapters/special.xml > > === > > --- a/docs/chapters/special.xml > > +++ b/docs/chapters/special.xml > > @@ -40,6 +40,31 @@ > > > > > > > > + > > + Using build-depends from experimental > > + > > This should mention that one ought to use `gbp buildpackage > --git-pbuilder` (as that is not the default). Agreed. > > + To build your package against a build-depends taken from experimental, > > you first need > > + to configure your pbuilder. To that extend, add the following to > > + ~/.pbuilderrc to instruct pbuilder to take build > > depends from > > + experimental when they cannot be satisfied from unstable. > > + > > + > > +PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends- > > experimental > > + > > Wouldn't we want to make that conditional like: > > if [ "$GBP_DIST" = "experimental" ]; then > echo "Using 'pbuilder-satisfydepends-experimental' for $GBP_DIST" > PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends- > experimental > fi Nice addition, thanks. > but I *think* this is even the default nowadays for building against > experimental. > > > + > > + You then need to add experimental to the apt configuration within the > > chroot. > > + The simplest for that is to edit the config file from outside of the > > chroot directly, > > + as follows: > > + > > +sudo bash -c "echo 'deb http://deb.debian.org/debian experimental main' >> > > /var/cache/pbuilder/base.cow/etc/apt/sources.list" > > + > > What about suggesting to bootstrap a new environment instead via: > > DIST=experimental git-pbuilder create > > This also handles adding experimental to /etc/apt/sources.list (no extra > setup needed). Maybe we can streamline things that way a bit? This has the drawback of taking all dependencies from experimental, which may not be what one wants. I agree that things could be streamlined in the tool, but documenting how to get around the corner with the current tools is already great, IMHO. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1055343: Status of the packaging of anura in Debian
Hello, I am "regularly" discussing with the authors of Anura (on their Discord channel), and the program is not ready for packaging yet. They have to sort something out so that we can use imgui from the Debian package instead of the embedded version. https://discord.com/channels/225816341737766912/1103903330972995674/1132358680692658276 Once their unvendor-imgui branch is merged into their trunk, it's time for us to package it. Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1042642: Why should a FTBFS against packages in experimental be serious?
severity 1042642 important thanks Hello Dmitry, I am wondering why you raised the severity of #1042642 to serious. Did I miss the part of the policy document stating that packages *must* build correctly against packages in experimental? Or is there anything else that I'm missing, maybe? Thanks for your explanations, Mt signature.asc Description: This is a digitally signed message part
Bug#1055345: git-buildpackage: Please document how to build against a package from experimental
Package: git-buildpackage Version: 0.9.32 Severity: wishlist Tags: patch Hello, thanks a lot for this package, that very often saves my life when packaging. There is one thing however where gbp could be more helpful, it's when I have to build my package against a build-depend that comes from experimental. I finally found a way to do it, and I propose the following patch for the documentation for the next person looking for this information. I fully acknowledge that this documentation is somehow suboptimal, and that the gbp tool could be more helpful here, but the proposed documentation would already be great. Again, thanks for this great tool and for your time. Mt -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 git-buildpackage depends on: ii devscripts 2.23.6 ii git 1:2.40.1-1 ii man-db 2.11.2-3 ii python3 3.11.4-5+b1 ii python3-dateutil 2.8.2-3 ii python3-pkg-resources 68.1.2-1 ii python3-yaml 6.0.1-1 ii sensible-utils 0.0.20 Versions of packages git-buildpackage recommends: ii cowbuilder 0.89 ii pbuilder 0.231 ii pristine-tar 1.50 ii python3-requests 2.31.0+dfsg-1 Versions of packages git-buildpackage suggests: ii python3-notify2 0.3-5 ii sudo 1.9.14p2-1 ii unzip 6.0-28 -- no debconf information --- docs/chapters/special.xml | 25 + 1 file changed, 25 insertions(+) Index: b/docs/chapters/special.xml === --- a/docs/chapters/special.xml +++ b/docs/chapters/special.xml @@ -40,6 +40,31 @@ + +Using build-depends from experimental + +To build your package against a build-depends taken from experimental, you first need +to configure your pbuilder. To that extend, add the following to +~/.pbuilderrc to instruct pbuilder to take build depends from +experimental when they cannot be satisfied from unstable. + + +PBUILDERSATISFYDEPENDSCMD=/usr/lib/pbuilder/pbuilder-satisfydepends-experimental + + +You then need to add experimental to the apt configuration within the chroot. +The simplest for that is to edit the config file from outside of the chroot directly, +as follows: + +sudo bash -c "echo 'deb http://deb.debian.org/debian experimental main' >> /var/cache/pbuilder/base.cow/etc/apt/sources.list" + + +Once everything is setup (and once you updated apt cache files with +git-pbuilder update), you can force the build of your package against +a given package from experimental by specifying the relevant version in the +debian/control. + + Importing NMUs signature.asc Description: This is a digitally signed message part
Bug#1051668: tldr-hs: Please allow to share the pages between users
Package: tldr-hs Version: 0.9.2-4 Severity: normal Dear maintainers, if I understand correctly, the pages are downloaded under ~/.local/share/tldr for each user. This is somewhat suboptimal for multi-users systems, and it would be much better to allow their download somewhere under /usr/share/tldr Updating the pages in this location could only be done by root, forcing the package to take care of them (eg with a cron page), but that would be a small relief for the users. My specific use case is that I'd like to preconfigure access to tldr to users without requiring a network access on the first use by a given user, but I'm sure that this feature would be helpful in other contexts too. Thanks for this great tool, Mt -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 tldr-hs depends on: ii git 1:2.40.1-1 ii libc6 2.37-7 ii libcmark0.30.2 0.30.2-6 ii libffi8 3.4.4-1 ii libgmp10 2:6.3.0+dfsg-2 ii zlib1g 1:1.2.13.dfsg-3 tldr-hs recommends no packages. tldr-hs suggests no packages. -- no debconf information -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1051220: libgtk-3-0: inkscape segfaults when exporting files from the command line
Package: libgtk-3-0 Version: 3.24.38-4 Severity: normal Tags: patch upstream Dear maintainers, when running `inkscape img/cache.svg --export-filename=img/cache.pdf` with the attached svg file, I get a segfault message indicating that I should report the bug. But actually, my bug was most probably already reported and fixed upstream, it's here: https://gitlab.com/inkscape/inkscape/-/issues/4177 The fix does happen to be in inkscape itself but in gtk. The patch is not part of any release yet (it should be part of 3.39 when it comes out), so the best solution would be to backport this patch in the Debian package for the time being. Could you please include that patch to be part of the next package? Thanks in advance, Martin --- PS: for the record, here are the system information of my inkscape install. Libgtk information follows -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 inkscape depends on: ii lib2geom1.2.0 1.2.2-3 ii libatkmm-1.6-1v5 2.28.3-1 ii libboost-filesystem1.74.0 1.74.0+ds1-22 ii libc6 2.37-7 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii libcairomm-1.0-1v5 1.14.4-2 ii libcdr-0.1-1 0.1.7-1 ii libfontconfig1 2.14.2-4 ii libfreetype6 2.13.2+dfsg-1 ii libgc1 1:8.2.4-1 ii libgcc-s1 13.2.0-2 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.77.2-1 ii libglibmm-2.4-1v5 2.66.6-2 ii libgomp1 13.2.0-2 ii libgsl27 2.7.1+dfsg-5 ii libgspell-1-2 1.12.2-1 ii libgtk-3-0 3.24.38-4 ii libgtkmm-3.0-1v5 3.24.8-2 ii libharfbuzz0b 8.0.1-1 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libmagick++-6.q16-8 8:6.9.11.60+dfsg-1.6 ii libpango-1.0-0 1.51.0+ds-2 ii libpangocairo-1.0-0 1.51.0+ds-2 ii libpangoft2-1.0-0 1.51.0+ds-2 ii libpangomm-1.4-1v5 2.46.3-1 ii libpng16-16 1.6.40-1 ii libpoppler-glib8 22.12.0-2+b1 ii libpoppler126 22.12.0-2+b1 ii libpotrace0 1.16-2 ii libreadline8 8.2-1.3 ii librevenge-0.0-0 0.0.5-3 ii librsvg2-common 2.54.7+dfsg-2 ii libsigc++-2.0-0v5 2.12.0-1 ii libsoup2.4-1 2.74.3-1 ii libstdc++6 13.2.0-2 ii libvisio-0.1-1 0.1.7-1+b3 ii libwpg-0.3-3 0.3.4-3 ii libx11-6 2:1.8.6-1 ii libxml2 2.9.14+dfsg-1.3 ii libxslt1.1 1.1.35-1 ii python3 3.11.4-5+b1 ii zlib1g 1:1.2.13.dfsg-3 Versions of packages inkscape recommends: ii aspell 0.60.8-6 ii fig2dev 1:3.2.9-1 ii imagemagick 8:6.9.11.60+dfsg-1.6 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.6 ii libimage-magick-perl 8:6.9.11.60+dfsg-1.6 ii libwmf-bin 0.2.13-1 ii python3-cssselect 1.2.0-2 ii python3-lxml 4.9.3-1 ii python3-numpy 1:1.24.2-1 ii python3-scour 0.38.2-3 Versions of packages inkscape suggests: pn dia pn inkscape-tutorials pn libsvg-perl pn pstoedit ii python3-packaging 23.1-1 pn python3-uniconvertor ii ruby 1:3.1 -- no debconf information --- -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libgtk-3-0 depends on: ii adwaita-icon-theme 43-1 ii hicolor-icon-theme 0.17-2 ii libatk-bridge2.0-0 2.49.90-5 ii libatk1.0-0 2.49.90-5 ii libc6 2.37-7 ii libcairo-gobject2 1.16.0-7 ii libcairo2 1.16.0-7 ii
Bug#1037791: confirmed on v3.38 -- found a fix candidate in upstream gitlab
Hello, I just confirm that this problem is still there with the next upstream release, that I packaged locally. I found a patch in upstream gitlab, and I'll now test it: https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/1452 Thanks, Mt signature.asc Description: This is a digitally signed message part
Bug#1036824: po4a: Describe how to create/maintain pot file from man page
Hello Helge, Every po4a-* scripts are deprecated. The right way to go is to use the main po4a script, using an adequate config file. I think that this is documented in po4a(1), isn't it? Which project are we speaking of? I'm really overwhelmed right now but maybe I could find some time to propose a config file for that project in the future. Sorry, Mt Le samedi 27 mai 2023 à 13:56 +0200, Helge Kreutzmann a écrit : > Package: po4a > Version: 0.69-1 > Severity: wishlist > > Some time ago several po4a tools started emitting warnings and ceased > working as before. I read that "po4a" is the way to go, however, we > seriously lack the man power (and knowledge) to rewrite the entire > machinery. However, I'm gradully trying to improve the system where > and when possible. > > For this, I have the follwing question/request: > Given that I have a man page (in nroff or mdoc format) and I want to > create a pot file from it (not po file, as this page is not yet > translated). How is this done best/correctly? > > Quite a few explanations in the po4a man pages assume you already have > some translated text. > > Currently I use something like: > > po4a-updatepo -f man \ > --option groff_code=verbatim \ > --option generated \ > --option untranslated="a.RE,\|" \ > --option unknown_macros=untranslated \ > --master "$upstream_manpage" -M utf-8 \ > -p $tmp1 | grep -v "po4a-updatepo is deprecated. The unified po4a(1) > program is more convenient and less error prone." > > (Until very recently this used po4a-gettextize, but this stopped working) > > It would be great if you could document the proper solution in the > very well written and extensive documentation. > > > -- System Information: > Debian Release: 12.0 > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing') > Architecture: amd64 (x86_64) > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-12 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-38 > ii libsyntax-keyword-try-perl 0.28-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl 5.36.0-7 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-5 > ii libterm-readkey-perl 2.38-2+b1 > ii libtext-wrapi18n-perl 0.06-10 > ii libunicode-linebreak-perl 0.0.20190101-1+b5 > > po4a suggests no packages. > > -- no debconf information > -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1035312: minetest: New upstream version available (5.7.0)
Hello, thanks for your interest. We will have to wait until after the freeze period and the release of the upcoming version of Debian before we can upload another version. This is expected for mid-june. Please come back to us after this date if we forget to upload minetest after that. Thanks, Mt Le dimanche 30 avril 2023 à 15:14 -0300, Nelson A. de Oliveira a écrit : > Source: minetest > Severity: wishlist > X-Debbugs-Cc: nao...@gmail.com > > Hi! > > When possible, could we have the latest upstream version (5.7.0) > packaged, please? > > Thank you! > > Best regards, > Nelson > > -- System Information: > Debian Release: 12.0 > APT prefers unstable > APT policy: (500, 'unstable'), (100, 'unstable-debug'), (100, > 'experimental'), (1, 'experimental-debug') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), > LANGUAGE=pt_BR:pt:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > -- no debconf information > -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#948674: Any news on the otter browser packaging?
Hello Gürkan, Le samedi 29 avril 2023 à 23:18 +0200, Gürkan Myczko a écrit : > > Here's what I have, best to use dget on it: > http://sid.ethz.ch/debian/otter-browser/ It looks very good to me. Would you consider uploading it to the archive, either directly or through the mentoring system, maybe ? Thanks for your work, Mt signature.asc Description: This is a digitally signed message part
Bug#948674: Any news on the otter browser packaging?
Hello Gürkan, The link you provided to the prospective package returns a 404, unfortunately. Could you please provide a link to your current code for other to contribute? Thanks in advance, Mt -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1032324: pybind11-dev: Missing dependency on libpython3.11-dev or python3-dev
Package: pybind11-dev Version: 2.10.3-1 Severity: normal Dear maintainers, pybind11 is using Python.h, which is installed by libpython3.11-dev on my machine. I thus think that pybind11-dev should really depend on that package, or on another package that ensure that Python.h is installed, regardless of the current version of Python. I'm not very versed in python packaging, but I think that python3-dev is a safe guess here. Thanks for this package, that's really helpful. Mt -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing'), (90, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 pybind11-dev depends on no packages. Versions of packages pybind11-dev recommends: ii libeigen3-dev 3.4.0-4 Versions of packages pybind11-dev suggests: pn pybind11-doc -- no debconf information -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1030658: More info needed on the RC bug you opened
tag 1030658 +moreinfo thanks Hello Damyan, sorry for not noticing this bug before, I thought I was subscribed to the package. It looks like a missing dependency to me. Could you please give me the output of `ldd /usr/bin/zeal` ? I tried to dig a bit to understand what's going wrong, but the runtime dependencies of the package are auto-generated as they should, and the resulting binary package seem to have the correct dependencies. Could you also please try to install libssl3 manually to see whether it helps? Thanks for reporting, Mt signature.asc Description: This is a digitally signed message part
Bug#955208: rustup was published to crates.io; I'd be great to have it packaged in Debian
Hello there, two years ago, Ximin stated that rustup cannot enter Debian until either - https://github.com/rust-lang/rustup/issues/835 OR - https://salsa.debian.org/rust-team/debcargo/-/merge_requests/22 is fixed. The thing is that the first issue was closed in between. Is there any hope that we could get rustup as a package, please? My motivation is that I want to hack on a project that won't compile if rustup is not installed, and I don't like installing anything out of dpkg. Thanks in advance and kudos for all the good work here. Mt signature.asc Description: This is a digitally signed message part
Bug#1021886: moc: Please allow URLs to start with https
Package: moc
Version: 1:2.6.0~svn-r3005-2.1
Severity: wishlist
Tags: patch
Hello,
it would be nice to be able to play online streams which URL starts with
https:// instead of http://
The idea and patch comes from:
https://github.com/jonsafari/mocp/pull/32/files
I'm using this patch locally and it works for me.
Thanks in advance,
Mt
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.19.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 moc depends on:
ii libasound2 1.2.7.2-1
ii libc6 2.35-1
ii libcurl3-gnutls 7.85.0-1
ii libdb5.3 5.3.28+dfsg1-0.10
ii libfaad2 2.10.0-2+b1
ii libflac8 1.3.4-2
ii libgcc-s1 12.2.0-3
ii libid3tag0 0.15.1b-14
ii libjack-jackd2-0 [libjack-0.125] 1.9.21~dfsg-1
ii libltdl7 2.4.7-4
ii libmad0 0.15.1b-10.1+b1
ii libmagic1 1:5.41-4
ii libmodplug1 1:0.8.9.0-3
ii libmpcdec6 2:0.1~r495-2
ii libncursesw6 6.3+20220423-2
ii libogg0 1.3.5-1
ii libopusfile0 0.12-2
ii libpopt0 1.18-3
ii librcc0 0.2.13+ds-2
ii libresid-builder0c2a 2.1.1-15+b1
ii libsamplerate0 0.2.2-2
ii libsidplay2 2.1.1-15+b1
ii libsidutils0 2.1.1-15+b1
ii libsndfile1 1.1.0-2
ii libspeex1 1.2.1-1
ii libstdc++6 12.2.0-3
ii libtagc0 1.12-1+b1
ii libtinfo6 6.3+20220423-2
ii libvorbisfile3 1.3.7-1
ii libwavpack1 5.5.0-1
moc recommends no packages.
Versions of packages moc suggests:
ii moc-ffmpeg-plugin 1:2.6.0~svn-r3005-2
-- no debconf information
--- a/files.c
+++ b/files.c
@@ -85,6 +85,7 @@
inline int is_url (const char *str)
{
return !strncasecmp (str, "http://;, sizeof ("http://;) - 1)
+ || !strncasecmp (str, "https://;, sizeof ("https://;) - 1)
|| !strncasecmp (str, "ftp://;, sizeof ("ftp://;) - 1);
}
signature.asc
Description: This is a digitally signed message part
Bug#1020108: quilt: diff for NMU version 0.66-2.2
Hello everybody, many thanks for your help. There is no need to delay your NMU any further. You could also upload it directly, I'm really happy with your help. I'd really love to see someone helping me updating the package to the latest version. quilt is in maintainance mode upstream, and it's a pitty that I fail to get the latest improvement in Debian since such a long time. Thanks again for your help, and enjoy. Mt Le samedi 15 octobre 2022 à 11:21 +0200, Christoph Biedl a écrit : > tags 1020108 + pending > user debian-rele...@lists.debian.org > usertags 1020108 + bsp-2022-10-de-karlsruhe > thank you > > Dear maintainer, > > turns out this has already been addressed in upstream git, so cherry-picking > that one is the way to go. > > To fix the issues with this package, I've prepared an NMU for quilt > (versioned as 0.66-2.2), debdiff below. An upload to DELAYED/5 will > follow shortly. Please feel free to tell me if I should delay it > longer. > > Regards, > > Christoph -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1020821: po4a-gettextize sanity check too strict, please slow-down deprecation
Hello, Here is a quick first answer. I'll check more later but I'm busy these days so I have to do a fast approximate answer, or you'll have to wait for a sloow answer. I think that the deprecation is not involved in your problem. It's another issue. I recently realized that some people were using po4a-gettextize in place of po4a-updatepo to create the po, even if that's absolutely not the expected way of using tools. That use of po4a-gettextize is not expected by the code, so thing may well go wrong, either now or in the future. This is why I decided to drop that use of po4a-gettextize. Please try to use po4a-updatepo instead and tell me if it solves the issue as I suspect. Thanks for your time and for reporting, Mt Le mardi 27 septembre 2022 à 15:40 +0900, Osamu Aoki a écrit : > Package: po4a > Version: 0.68-1 > Severity: normal > > Hi, > > I am experiencing FTBFS on debian-reference and maint-guide > > If you want to deprecate po4a-translate and po4a-updatepo and force me > to use po4a, that's sad but I understand your position. Maintenance of > them may be burden for you. But can we do this with a bit more > coordination and with transition period. > > I am facing problem with new 0.68-1 > > - Greatly improve the gettextization process > - po4a-translate and po4a-updatepo are now deprecated: > you should use po4a instead. > > Error I am facing is as follows: > > po4a-gettextize -M utf-8 -L utf-8 --format docbook -m debian-reference.en.xmlt > | \ > sed -e 's,^"Content-Type: text/plain; charset=CHARSET\\n"$,"Content-Type: > text/plain; charset=UTF-8\\n",' |\ > msgcat --no-location -o po/templates.pot.new - > You must provide the same amount of master files and localized files to > synchronize them, as po4a-gettextize is intended to synchronize master files > and previously existing translations. If just want to extract POT files of > your master files, please use po4a-updatepo. Please note that the most > convenient way of using po4a is to write a po4a.conf file and use the > integrated po4a(1) program. > if diff -I '^"POT-Creation-Date:' -q po/templates.pot po/templates.pot.new ; > then \ > echo "Don't update templates.pot" ;\ > touch po/templates.pot ;\ > rm -f po/templates.pot.new ;\ > else \ > echo "Update templates.pot" ;\ > mv -f po/templates.pot.new po/templates.pot ;\ > fi > diff: po/templates.pot: No such file or directory > diff: po/templates.pot.new: No such file or directory > > > template.pot is not generated by po4a-gettext any more > > I intensionally touch-up master file to reduce translation PO file size > by placing "DUMMY" to certain master file contents used by > po4a-gettextize. So those parts doesn't apear in po/pot and translator > have easier time. In order to attain this, I directly use > po4a-translate and po4a-updatepo from Makefile to get translated results > with the full English file with reduced size PO. > > Please also realize that my Makefile also use opencc to translate > missing translation msgstr in PO files supplimenting between zh_CN and > zh_TW peacefully. po4a command has no way to do this either. > > Since this failure seems to be induced by the newly added sanity check > to force us to migrate to use po4a, I am asking you to go slow on this > migration. Can you just give us option to avoid this failure at least > for the next release? Do you really force this sanity check now? > > I hope to come up with new build script using po4a. But unless that > happens, debian-reference and maint-guide will be out of testing. > > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.19.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages po4a depends on: > ii gettext 0.21-9 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl 5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-2 > ii libtext-wrapi18n-perl 0.06-10 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1020108: quilt: FTBFS: dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 returned exit code 2
Control: tag -1 help I seem to remember that this is a transient bug, that does not occure all the time at all. That being said, I'm not sure I already tested running the tests in parallel. Is that really a FTBFS if the failure only happens under this setting? I tend to remove the FTBFS severity on this one, but I'm not sure. I'm really short on time these days, so any help is welcome. It's maybe the occasion to upgrade the package to the new upstream release, but we have a lot of patches that I'd like to integrate upstream. It takes time because upstream is picky and only integrate sensible changes. I do not blame them for that (to the contrary), but I don't often trust myself to discuss our changes with them. The package is uptodate on salsa. Thanks for any help that could be provided. Mt Le dimanche 18 septembre 2022 à 08:40 +0200, Lucas Nussbaum a écrit : > Source: quilt > Version: 0.66-2.1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220917 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[2]: Entering directory '/<>' > > [add-filename-check.test] > > 6 commands (6 passed, 0 failed) > > [altered-series.test] > > 12 commands (12 passed, 0 failed) > > [comments.test] > > 11 commands (11 passed, 0 failed) > > [applied.test] > > 15 commands (15 passed, 0 failed) > > [dir-a-b.test] > > 11 commands (11 passed, 0 failed) > > [colon-in-patch-name.test] > > 23 commands (23 passed, 0 failed) > > [create-delete.test] > > [4] $ mkdir patches -- ok > > [6] $ echo delete > delete -- ok > > [7] $ quilt new test.diff -- ok > > [10] $ quilt add create -- ok > > [13] $ echo create > create -- ok > > [14] $ quilt refresh -- ok > > [17] $ quilt add delete -- ok > > [20] $ rm -f delete -- ok > > [21] $ quilt refresh -- ok > > [23] $ quilt header -r -- ok > > [31] $ quilt patches -v create -- ok > > [33] $ quilt patches delete -- ok > > [36] $ quilt pop -q -- ok > > [40] $ quilt patches create -- ok > > [42] $ quilt patches -v delete -- ok > > [44] $ quilt patches -- /dev/null dev/null null --- -- failed > > grep: warning: stray \ before / != ~ > > grep: warning: stray \ before / != ~ > > grep: warning: stray \ before / != ~ > > [46] $ echo create > create -- ok > > [47] $ rm -f delete -- ok > > [48] $ patch -p1 --dry-run < patches/test.diff -- ok > > 19 commands (18 passed, 1 failed) > > make[2]: *** [Makefile:411: test/.create-delete.ok] Error 1 > > make[2]: *** Waiting for unfinished jobs > > [annotate.test] > > 31 commands (31 passed, 0 failed) > > [duplicate-patch-in-series.test] > > 9 commands (9 passed, 0 failed) > > [conflicts.test] > > 39 commands (39 passed, 0 failed) > > [auto-refresh.test] > > 14 commands (14 passed, 0 failed) > > [dotglob.test] > > 7 commands (7 passed, 0 failed) > > [delete.test] > > 34 commands (34 passed, 0 failed) > > [backup-files.test] > > 119 commands (119 passed, 0 failed) > > make[2]: Leaving directory '/<>' > > dh_auto_test: error: make -j8 check "TESTSUITEFLAGS=-j8 --verbose" VERBOSE=1 > > returned exit code 2 > > > The full build log is available from: > http://qa-logs.debian.net/2022/09/17/quilt_0.66-2.1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20220917;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20220917=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as 'affects'- > ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#991788: Same bug here
Hello, I'm having the same bug. Me too I have to switch to the console with Ctrl-Alt-F1 to revive the graphical console. I found that the following is sufficient to revive the display from the blank screen: chvt 7; DISPLAY=:0 xrandr --auto The second part of the workaround was found in the logs of this bug, but the first part is easier than the previously proposed hack: delaying the xrandr and manually switching to the vt 7. My settings: $ dpkg -l xfce4 upower light-locker nvidia-kernel-dkms|grep ii; uname -a; lspci |grep -i nvidia ii light-locker 1.8.0-3 amd64simple screen locker for lightDM display manager ii nvidia-kernel-dkms 470.141.03-1 amd64NVIDIA binary kernel module DKMS source ii upower 0.99.20-1amd64abstraction for power management ii xfce4 4.16 all Meta-package for the Xfce Lightweight Desktop Environment Linux cafuron 5.18.0-4-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.16-1 (2022-08-10) x86_64 GNU/Linux 01:00.0 3D controller: NVIDIA Corporation TU117GLM [Quadro T1000 Mobile] (rev a1) Thanks,
Bug#1018966: widelands-data: RC
Hello Bastien, thanks for your patch. I discussed the MR on salsa (in short, I'd like to understand why my current setup is not working and what it is that you try to fix). In addition, please note that widelands does not build on salsa's CI because of its size. You'll have to test your patch manually, I fear ;) If you know how to get its CI working on salsa, I'm really interested, of course. Thanks again for your help, Mt > This is in fact an RC bug that should have been catch by piuparts > > Patch here not tested please test by runing CI on salsa > https://salsa.debian.org/games-team/widelands/-/merge_requests/2 -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1018966: Information needed about your bug against widelands
Hello waxhead, could you please tell us what is the result of the following command on your machine? ls -la /usr/share/games/widelands/data/i18n/fonts/Culmus/TaameyFrankCLM-Medium.ttf This file is included in the widelands-data package, that seem installed on your machine, so I fail to understand how things could go wrong. Thanks in advance, Mt signature.asc Description: This is a digitally signed message part
Bug#1018697: deb-scrub-obsolete: please document the RELEASE names
tags 1018697 +pending thanks Le lundi 29 août 2022 à 12:52 +0100, Jelmer Vernooij a écrit : > tags 1018697 +confirmed > thanks > > Hi Martin, > > Thanks for the bug report. > > On Mon, Aug 29, 2022 at 09:40:58AM +0200, Martin Quinson wrote: > > I am always reluctant to apply the merge requests of deb-scrub-obsolete, > > because I'm not sure of which release I cut off while applying these > > changes. > > It would be really helpful if the script could augment the changelog to add > > the > > release name since which the removed versionning is useless, please. > > There is a release name in the changelog entry at the moment. Do you > have a proposed format/wording for the changelog? My bad. I should have re-tested it before filling this bug report. Older MR opened by the Debian Janitor did not mention it, so I have many such MR rotting on salsa, but they were fixed in between. Ahem, I'm ashamed. Taging the bug as pending as only the following was valid, and you fixed it. Thanks! > > Along the same line, it could be helpful to document in the deb-scrub- > > obsolete > > manpage the list of accepted releases. In particular, I'm wondering whether > > I > > have to use a codename such as bookworm, or whether an alias such as old- > > old- > > stable is acceptable. > Both should work, but I've just added a note in the manpage. Thanks! > > I'll leave the bug report open for the first issue. > > Cheers, > > Jelmer signature.asc Description: This is a digitally signed message part
Bug#1018697: deb-scrub-obsolete: please document the RELEASE names
Package: lintian-brush Version: 0.128 Severity: wishlist Dear maintainer, first of all, thanks for this great package, that's really helpful. I am always reluctant to apply the merge requests of deb-scrub-obsolete, because I'm not sure of which release I cut off while applying these changes. It would be really helpful if the script could augment the changelog to add the release name since which the removed versionning is useless, please. Along the same line, it could be helpful to document in the deb-scrub-obsolete manpage the list of accepted releases. In particular, I'm wondering whether I have to use a codename such as bookworm, or whether an alias such as old-old- stable is acceptable. Sorry for having two related points in the same bug report. I hope it's OK given how close they are. Thanks again for this great package, Mt -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 lintian-brush depends on: ii devscripts 2.22.2 ii python3 3.10.4-1+b1 ii python3-breezy 3.2.2-2 ii python3-debian 0.1.46 ii python3-debmutate 0.54 ii python3-distro-info 1.1 ii python3-dulwich 0.20.44-1 ii python3-iniparse 0.5-1 ii python3-iso8601 1.0.2-1 ii python3-ruamel.yaml 0.17.16-1 ii python3-tqdm 4.64.0-2 ii python3-upstream-ontologist 0.1.25-2 Versions of packages lintian-brush recommends: ii debhelper 13.8 ii decopy 0.2.4.6-0.1 ii dos2unix 7.4.3-1 ii gpg 2.2.35-3 ii lintian 2.115.2 ii ognibuild 0.0.13-1 ii python3-asyncpg 0.25.0-2 ii python3-bs4 4.11.1-1 ii python3-docutils 0.17.1+dfsg-2 ii python3-levenshtein 0.12.2-2+b1 ii python3-lxml 4.8.0-1 ii python3-markdown 3.3.7-1 ii python3-pyinotify 0.9.6-2 ii python3-semver 2.10.2-3 ii python3-tomlkit 0.9.2-1 Versions of packages lintian-brush suggests: ii brz-debian 2.8.69 ii git-buildpackage 0.9.28 pn gnome-pkg-tools ii po-debconf 1.0.21+nmu1 pn postgresql-common -- no debconf information -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1010804: Thanks for the patch
Hello, I just tested your patch and it works. I will upload the new package shortly. Thanks for your work, Mt. signature.asc Description: This is a digitally signed message part
Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize
Package: po4a tag 1017742 fixed-upstream thanks Hello, I just fixed the gettextization process, and I think it's now much better. The version I introduced in last version was indeed really suboptimal. Now, if I gettextize these two files (presented side by side): ``` # hello | # HELLO | ## hello | ## SUBTITLE | hello | SAMPLE PARAGRAPH. ``` I get a pot file with a single msgid: ``` #, fuzzy, markdown-text, no-wrap msgid "hello" msgstr "" "#-#-#-#-# file1:1 (type Title #) #-#-#-#-#\n" "HELLO\n" "#-#-#-#-# file1:3 (type: Title ##) #-#-#-#-#\n" "SUBTITLE\n" "#-#-#-#-# file1:5 (type: Plain text) #-#-#-#-#\n" "SAMPLE PARAGRAPH." ``` I think it's much much better than the previous thing. Thanks again for reporting the issue, I'm glad of that new version :) Bye, Mt. Le samedi 20 août 2022 à 10:43 +0200, Martin Quinson a écrit : > > > - Le 19 Aoû 22, à 21:13, Helge Kreutzmann deb...@helgefjell.de a écrit : > > > Package: po4a > > Version: 0.67-2 > > Severity: wishlist > > > > Since recently po4a-gettextize adds spaces at the end of strings > > during gettextisation, if strings occure multiple times in the master > > file (or translation). > > > > In production, multiple indentical strings in the original file are > > only stored once in the po file (as they are translated the same). > > > > Therefore, translators need to review those strings carefully and > > remove those entries from the po file, which have this final space > > added. In this process they need to choose the most appropriate > > translation to keep. > > > > Currently, this can be quite difficult, as the string can occur > > multiple times and the trailing space(s) are difficult to spot in > > large files. Also these trailing spaces are hard to get a good regular > > expression for searching. > > > > Therefor I kindly ask you if you could mark those strings in addition > > (!) with a suitable translator comment (e.g. "Potential duplicate > > string, review and consolidate"). This would users allow to use msggrep(1) > > with the option -C to filter them out for review. > > > > Thanks for considering. > > Your bug report makes me realize that the current behavior is perfectly > broken. I was hopping for the next msgmerge to merge the alternative > translations of the same msgid, but I realize that they will most probably be > dropped in the process. > > Mmm. Let me think about it, I'll try to reimplement this thing so that the > carful review that you describe becomes automatically done during the > gettexization. > > Many thanks for reporting, > Mt -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1017837: po4a: This page defines a new macro - cannot get rid of error message
Package: po4a
tag 1017837 fixed-upstream
thanks
Hello,
thanks for the report. This is because your macro definition provides a comment
after the macro name, defeating our handling. This is fixed in upstream git.
Thanks,
Mt
Le dimanche 21 août 2022 à 13:05 +0200, Helge Kreutzmann a écrit :
> Package: po4a
> Version: 0.67-2
> Severity: normal
>
> If I try to generate the pot file for e.g. icewm.1, using:
> po4a-gettextize -f man --option groff_code=verbatim --option generated --
> option untranslated="a.RE,\|" --option unknown_macros=untranslated --master
> ../upstream/debian-unstable/man1/icewm.1 -M utf-8 > /tmp/bazbar.pot
>
> (Here ../upstream/debian-unstable/man1/icewm.1 refers to the man page
> icewm.1 as found in icewm-common in debian-unstable).
>
> I get the following error messages:
> po4a::man: This page defines a new macro 'Sp \" Vertical space (when we can't
> use .PP)' with '.de', but you did not specify the expected po4a behavior when
> 'Sp \" Vertical space (when we can't use .PP)' is used. You will get an error
> if this macro is actually used in your page.
> Add your macro to one of the 'untranslated', 'noarg', 'translate_joined',
> 'translate_each', 'no_wrap' or 'inline' parameters to avoid issues.
> For example, passing '-o untranslated=Sp \" Vertical space (when we can't use
> .PP)' to po4a will ensure that the defined macro remains hidden from
> translators.
> Please refer to the manpage of Locale::Po4a::Man for more info on these
> parameters.
>
> po4a::man: This page defines a new macro 'Vb \" Begin verbatim text' with
> '.de', but you did not specify the expected po4a behavior when 'Vb \" Begin
> verbatim text' is used. You will get an error if this macro is actually used
> in your page.Add your macro to one of the 'untranslated', 'noarg',
> 'translate_joined', 'translate_each', 'no_wrap' or 'inline' parameters to
> avoid issues.
> For example, passing '-o untranslated=Vb \" Begin verbatim text' to po4a will
> ensure that the defined macro remains hidden from translators.
> Please refer to the manpage of Locale::Po4a::Man for more info on these
> parameters.
>
> po4a::man: This page defines a new macro 'Ve \" End verbatim text' with '.de',
> but you did not specify the expected po4a behavior when 'Ve \" End verbatim
> text' is used. You will get an error if this macro is actually used in your
> page.
> Add your macro to one of the 'untranslated', 'noarg', 'translate_joined',
> 'translate_each', 'no_wrap' or 'inline' parameters to avoid issues.
> For example, passing '-o untranslated=Ve \" End verbatim text' to po4a will
> ensure that the defined macro remains hidden from translators.
> Please refer to the manpage of Locale::Po4a::Man for more info on these
> parameters.
>
> These messages are new, they are not present in older versions of po4a, e.g.
> in stable.
>
> So I try to do as the message says:
> po4a-gettextize -f man --option groff_code=verbatim --option generated -o
> untranslated=Sp \" Vertical space (when we can't use .PP) --option
> unknown_macros=untranslated --master ../upstream/debian-unstable/man1/icewm.1
> -M utf-8 > /tmp/bazbar.pot
> -bash: Syntaxfehler beim unerwarteten Symbol »(«
>
> (English: Syntax error at the unexpected symbol "(")
>
> That one is easy, the suggestion misses quoting. Now:
> po4a-gettextize -f man --option groff_code=verbatim --option generated -o
> untranslated="Sp \" Vertical space (when we can't use .PP)" --option
> unknown_macros=untranslated --master ../upstream/debian-unstable/man1/icewm.1
> -M utf-8 > /tmp/bazbar.pot
> po4a::man: This page defines a new macro 'Sp \" Vertical space (when we can't
> use .PP)' with '.de', but you did not specify the expected po4a behavior when
> 'Sp \" Vertical space (when we can't use .PP)' is used. You will get an error
> if this macro is actually used in your page.
> Add your macro to one of the 'untranslated', 'noarg', 'translate_joined',
> 'translate_each', 'no_wrap' or 'inline' parameters to avoid issues.
> For example, passing '-o untranslated=Sp \" Vertical space (when we can't use
> .PP)' to po4a will ensure that the defined macro remains hidden from
> translators.
> Please refer to the manpage of Locale::Po4a::Man for more info on these
> parameters.
>
> po4a::man: This page defines a new macro 'Vb \" Begin verbatim text' with
> '.de', but you did not specify the expected po4a behavior when 'Vb \" Begin
> verbatim text' is used. You will get an error if this macro is actually used
> in your page.Add your macro to one of the 'untranslated', 'noarg',
> 'translate_joined', 'translate_each', 'no_wrap' or 'inline' parameters to
> avoid issues.
> For example, passing '-o untranslated=Vb \" Begin verbatim text' to po4a will
> ensure that the defined macro remains hidden from translators.
> Please refer to the manpage of Locale::Po4a::Man for more info on these
> parameters.
>
> po4a::man: This page defines a new macro 'Ve \" End verbatim text' with '.de',
> but you did not specify the
Bug#1016754: po4a: Incorrect bold handling for manpages bug 2
- Le 20 Aoû 22, à 5:24, Helge Kreutzmann deb...@helgefjell.de a écrit : > Hello Martin, > On Sat, Aug 20, 2022 at 02:25:36AM +0200, Martin Quinson wrote: >> thanks for the additional info. >> >> Could you please try to reduce the files to simplify my debugging effort? >> It'd >> be great if you could come up with a file as simple as possible, ie, one >> short >> paragraph only if possible, and using UPPERCASE as a translation instead of >> german. We have a lot of such files in our test suite. Search for example for >> .man, .pot, .po and .trans files eg in t/fmt/man. (.norm is the normalized >> file, ie the file after po4a parsing but with no translation while .trans is >> the translated file, using the po file). >> >> That would be really precious to me. > > I'll try, however, it might take some time. If it takes too long, then don't convert from German to upperside fake locale. Reducing the example is the most important. Thanks, Mt
Bug#1017742: po4a: Please provide marker for double strings during po4a-gettextize
- Le 19 Aoû 22, à 21:13, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.67-2 > Severity: wishlist > > Since recently po4a-gettextize adds spaces at the end of strings > during gettextisation, if strings occure multiple times in the master > file (or translation). > > In production, multiple indentical strings in the original file are > only stored once in the po file (as they are translated the same). > > Therefore, translators need to review those strings carefully and > remove those entries from the po file, which have this final space > added. In this process they need to choose the most appropriate > translation to keep. > > Currently, this can be quite difficult, as the string can occur > multiple times and the trailing space(s) are difficult to spot in > large files. Also these trailing spaces are hard to get a good regular > expression for searching. > > Therefor I kindly ask you if you could mark those strings in addition > (!) with a suitable translator comment (e.g. "Potential duplicate > string, review and consolidate"). This would users allow to use msggrep(1) > with the option -C to filter them out for review. > > Thanks for considering. Your bug report makes me realize that the current behavior is perfectly broken. I was hopping for the next msgmerge to merge the alternative translations of the same msgid, but I realize that they will most probably be dropped in the process. Mmm. Let me think about it, I'll try to reimplement this thing so that the carful review that you describe becomes automatically done during the gettexization. Many thanks for reporting, Mt
Bug#1016754: po4a: Incorrect bold handling for manpages bug 2
Hello Helge, thanks for the additional info. Could you please try to reduce the files to simplify my debugging effort? It'd be great if you could come up with a file as simple as possible, ie, one short paragraph only if possible, and using UPPERCASE as a translation instead of german. We have a lot of such files in our test suite. Search for example for .man, .pot, .po and .trans files eg in t/fmt/man. (.norm is the normalized file, ie the file after po4a parsing but with no translation while .trans is the translated file, using the po file). That would be really precious to me. Thanks in advance, Mt
Bug#1016754: po4a: Incorrect bold handling for manpages bug 2
Hello, could you please be more specific on what's going wrong? You say that the "english is in roman, while the translated text is in German". Well. The translation being in German does not sound like a bug to me :) I tried to check on the rendered manpages, but I don't see any difference between the english and german text here. They are both rendered as regular text. I'm using `man -l ` to render the page, so maybe that's why I don't see any difference. Please tell me how to render if I'm not doing it right. Thanks for the info, Mt - Le 6 Aoû 22, à 17:56, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.67-2 > Severity: normal > X-Debbugs-Cc: Mario Blättermann > > I'm the Debian maintainer of manpages-l10n and support upstream > (Mario) in maintaing the po based translations of manpages. > > I noticed the following incorrect bold formatting after some tables. > Search for "the innermost subdirectories are removed" in the english > original and for "werden die innersten Unterverzeichnisse" in the > german translations (all attached, including the intermediary po > file). > > The english original is in roman font, while the translated text is in > German. This specific paragraph looks like the following in the po > file: > > #. type: Plain text > #: archlinux debian-bullseye debian-unstable fedora-36 fedora-rawhide > #: mageia-cauldron opensuse-leap-15-4 opensuse-tumbleweed > msgid "" > "In case of I the innermost subdirectories are removed " > "when the unit is stopped\\&. It is possible to preserve the specified " > "directories in this case if I is configured to " > "B or B (see below)\\&. The directories specified with " > "I, I, I, " > "I are not removed when the unit is stopped\\&." > msgstr "" > "Im Falle von I werden die innersten Unterverzeichnisse " > "entfernt, wenn die Unit gestoppt wird\\&. Es ist möglich, in diesem Fall die > " > "festgelegten Verzeichnisse zu erhalten, falls I " > "auf B oder B konfiguriert ist (siehe unten)\\&. Die mit " > "I, I, I, " > "I festgelegten Verzeichnisse werden nicht entfernt, > " > "wenn die Unit gestoppt wird\\&." > > I could not detect anything wrong here, so I suspect that something > got wrong in the table above (table 2). I noticed that the original > includes the strings in the table in \fI$XDG_CONFIG_HOME\fR, while the > translation uses \fI$XDG_CONFIG_HOME\fP. > > I tried changing the last \fP (and all) to an \fR, but this did not > change this issue. > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL > set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-6 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-1+b3 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de > Dipl.-Phys. http://www.helgefjell.de/debian.php >64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#1016753: po4a: Incorrect bold handling for manpages bug 1
tag 1016753 fixed-upstream thanks Hello, I believe that this bug is fixed upstream by commit https://github.com/mquinson/po4a/commit/6b5139e7c5a7d789f51f8912cd2a6a835194c84b Thanks for reporting, Mt - Le 6 Aoû 22, à 17:55, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.67-2 > Severity: normal > X-Debbugs-Cc: Mario Blättermann > > I'm the Debian maintainer of manpages-l10n and support upstream > (Mario) in maintaing the po based translations of manpages. > > I noticed the following incorrect bold formatting in table headings, > when the translation is spanning more than one line in the po file. > Exactly at the line break in the po file, the bold formatting is > stopped. > > The english orginal file does not line wrap these lines, so maybe a > ,nowrap is missing here? > > This is an example, the full files are attached. > > .br > .B Table\ \&1.\ \ limit directives, their equivalent ulimit shell > commands and the unit used > .TS > > This becomes the following in the po file: > #. type: Plain text > #: archlinux debian-bullseye debian-unstable fedora-36 fedora-rawhide > #: mageia-cauldron opensuse-leap-15-4 opensuse-tumbleweed > msgid "" > "B "shell commands and the unit used>" > msgstr "" > "B "Ulimit-Shell-Befehle und die verwandte Einheit>" > > and thus the following in the German man page: > > .br > \fBTabelle\ \&1.\ \, ihre äquivalenten > Ulimit\-Shell\-Befehle und die verwandte Einheit\fP > .TS > > In the rendered man pages, bold font stops after "äquivalenten". If I > remove the line break manually in the generated man page, then the > entire line is bold. > > This happens consistently for all table headings in this man page. > > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL > set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-6 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-1+b3 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de > Dipl.-Phys. http://www.helgefjell.de/debian.php >64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#984736: status report on cron -> cronie transition?
Hello, Could someone please point me on the current status here? There is many patches in cron's package, and probably even more knowledge in the existing cron codebase. How/when will we able to say that it's now OK to switch to cronie? I have the feeling that switching from cron to cronie could be easier if we had tests for these softwares. I've found some tests in debian/tests of cron, but they don't seem numerous enough to help here. Maybe something around cwrap.org could help? Thanks for any advice, Mt signature.asc Description: This is a digitally signed message part
Bug#1017382: RM: zeal [armel ppc64el s390x] -- ANAIS; this new version depends on qtwebengine5 that does not exist on all Arch
Package: ftp.debian.org Severity: normal thanks thanks for your help signature.asc Description: This is a digitally signed message part
Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)
Hello, Le samedi 06 août 2022 à 06:20 +0200, Helge Kreutzmann a écrit : > > On Sat, Aug 06, 2022 at 12:23:48AM +0200, Martin Quinson wrote: > > the short answer is that po4a-gettextize is not intended to be used on a > > regular > > basis. It's only intended for the first run when you want to convert an > > existing > > translation to the po-based workflow. Once it's done, you're supposed to use > > po4a-updatepo to create an empty PO file. Even better, you should use po4a > > directly instead of the deprecated atomic commands. > > Ok, so this would be incorrect usage in sgt-puzzles? It did work for > the past ~ 13 years. Then it might be helpful to add a note that > certain use cases are not working anymore. > > Should this bug be cloned to sgt-puzzles for updating its > infrastructure? The fact is that I never imagined that someone would use po4a-gettextize on a regular basis, to create the empty POT file. I would have added a note in the changelog if I knew. I see the intend now, but this is not a usecase that I plan to maintain. I just added a check to po4a-gettextize which makes it break if you call it without localized files, as you would do to generate the empty POT files. My rational here is that the gettextization (ie, the resynchronization of a master file and a localized file to generate a valid PO file that can be used afterward in a po4a-based workflow) is a really tedious process. I prefer the po4a-gettextize script to dedicate to this usage, trying to smooth it as much as possible. This is not really compatible with its use as in sgt-puzzles. So, yes, the infrastructure of sgt-puzzles should be updated as it will fail with the next upcoming release of po4a. Sorry about that. The easiest should be to simply use po4a-updatepo with an unexistant POT file instead of po4a- gettextize, but the best would be to write a simple po4a.conf file and switch to the integrated po4a program. Invoking `make -f Makefile.doc update-po` now fails with the following error message: | You must provide both master files and localized files to po4a-gettextize, as | it is intended to synchronize master files and previously existing translations. | If just want to extract POT files of your master files, please po4a-updatepo. | But the most convenient way of using po4a is to write a po4a.conf file and use | the integrated po4a(1) program. Changing po4a-gettextize to po4a-updatepo seems to fix everything. > > The extra spaces that you see are intended to help the gettextization > > process, as explained in the po4a-gettextize manpage. > > At least I don't fully understand this text, even though I translated > it. (See below) > > > I'm not sure of how I can help you here. What piece of documentation should > > be updated? > > > What is missing here is how and when these strings are merged back, i.e. what > the translator or package maintainer should do to get to the desired > situation (i.e. each string only appearing once). I tried to rewrite the documentation and apply your comments. Please check the new version and report any remaining issue. https://github.com/mquinson/po4a/blob/master/po4a-gettextize#L24 > Could you add an example here? I.e. like I did below with my example? > In your text above (in the e-mail) you state that you should use > po4a-updatepo or po4a, here you mention msgmerge. Probably clarifying > this would help as well. I didn't add any example, but the new text is much more detailed so maybe that's enough? Thanks for your precious feedback, Mt > signature.asc Description: This is a digitally signed message part
Bug#1016695: po4a: Strange behaviour with repeated strings (in halibut backend)
Hello, the short answer is that po4a-gettextize is not intended to be used on a regular basis. It's only intended for the first run when you want to convert an existing translation to the po-based workflow. Once it's done, you're supposed to use po4a-updatepo to create an empty PO file. Even better, you should use po4a directly instead of the deprecated atomic commands. The extra spaces that you see are intended to help the gettextization process, as explained in the po4a-gettextize manpage. I'm not sure of how I can help you here. What piece of documentation should be updated? Thanks for using po4a, Mt Le vendredi 05 août 2022 à 16:02 +0200, Helge Kreutzmann a écrit : > Package: po4a > Version: 0.67-2 > Severity: normal > Tags: upstream > X-Debbugs-Cc: Ben Hutchings > > > I'm the translator of the German translation for the documentation of > sgt-puzzles. It is a Debian-only patch at the moment for the halibut > based sources. > > A few days ago Ben (the Debian maintainer) updated the package and > requested me to update the German translation. While doing so he > noticed a strange change in po4a behaviour: > > (Some) strings, which are repeated (because the same text appears in > multiple places in the documentation resp. many man pages) are > inserted several times into de.po, except that an increasing number of > spaces is added, i.e. > > "dog" would become > "dog" > "dog " > "dog " > "dog " > and so on. > > While updating the German translation of po4a I remember translating > something along these lines, though I did not fully understand its > meaning. > > This behaviour defeats part of the idea of the po format. Unless the > orginal author indicates this, identical strings in the original text > should be translated identical as well. > > Now for some reason po4a makes identical strings artificially different. > > In the toy example above, this could become: > "Hund" > "Rüde " > "Gerüstklammer " > "Schlepphaken " > … > > So now the same string is translated differently *and* the > translation receives also (varying) additional trailing spaces. (As a > translator, you usually reproduce space at the beginning and end). > > In this toy example this might be noticed easily, but usually po4a is > used for (longer) paragraphs - and translators might not realize they > already translated them and would retranslate them - additional work > and, as stated above, potentially inconsistent translations. > > Thus please revert to the previous behaviour of po4a *or* ensure that > identical text is shown only once in the *.po(t) files. > > In case you want to investigate yourself, do the following in > unstable: > > apt-get source sgt-puzzles > cd sgt-puzzles-20191231.79a5378/ > make -f debian/rules build > make -f Makefile.doc update-po > > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.18.15 (SMP w/12 CPU threads) > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.21-6 > ii libpod-parser-perl 1.65-1 > ii libsgmls-perl 1.03ii-37 > ii libsyntax-keyword-try-perl 0.27-1 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b2 > ii perl 5.34.0-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b2 > ii libterm-readkey-perl 2.38-1+b3 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b4 > > po4a suggests no packages. > > -- no debconf information > -- Pour une évaluation indépendante, transparente et rigoureuse ! Je soutiens la Commission d'Évaluation de l'Inria. signature.asc Description: This is a digitally signed message part
Bug#1015754: man-db: man should hint about uninstalled manpages
Package: man-db Version: 2.10.2-1 Severity: wishlist Hello, It would be great if man-db could hint about uninstalled manpages. One possible use-case would be when requesting the manpage of pthread_mutex_create when glibc-doc is not installed. Right now, it displays: "No manual entry for pthread_mutex_create" My idea is that it would be much more user-friendly to display something like "The manual entry of pthread_mutex_create is not available. Please install the package glibc-doc to retrieve it." I understand that the information requires a global knowledge over the archive and that it will be outdated very easily. I still think that it'd be a good improvement for our users to provide this information. Several implementations are possible, such as an external package providing the information about all existing packages in the Debian archive. It should be possible to keep it kinda up to date in testing, and almost perfectly up to date in stable, I think. I would be interested in helping here, but I first need to know about your feeling about this feature. There is no point thinking of an infrastructure to retrieve the info if you don't want to include this feature at the end. Either way, thanks for you hard work for Debian, Colin. Have a good one, Mt -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-2-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 man-db depends on: ii bsdextrautils 2.38-4 ii bsdmainutils 12.1.7+nmu3 ii debconf [debconf-2.0] 1.5.79 ii groff-base 1.22.4-8 ii libc6 2.33-7 ii libgdbm6 1.23-1 ii libpipeline1 1.5.6-1 ii libseccomp2 2.5.4-1 ii zlib1g 1:1.2.11.dfsg-4 man-db recommends no packages. Versions of packages man-db suggests: ii apparmor 3.0.4-3 ii chromium [www-browser] 103.0.5060.53-1 ii firefox-esr [www-browser] 91.11.0esr-1 pn groff ii hv3 [www-browser] 3.0~fossil20110109-8 ii konqueror [www-browser] 4:21.12.3-1 ii less 590-1 ii lynx [www-browser] 2.9.0dev.10-1 -- debconf information: man-db/auto-update: true man-db/install-setuid: false signature.asc Description: This is a digitally signed message part
Bug#1014413: ITS: zeal. I would like to help packaging zeal to revive it
Package: zeal Version: 1:0.6.1-1.2 Severity: important Hello, I think that the packaging of Zeal stalled somehow in the recent years. The last maintainer upload was back in 2018, and there were 2 NMU since then. There is a MR on salsa, but no answer from the maintainer. I'm not blaming anyone here, it's just that I do have interest in this package and I intend to help if I can. Please ChangZhuo tell me how I can help you. If you don't answer before July 26., I will upload a new version adding myself as a co-maintainer. My dream would be to go for co-maintenance here, and I would love to hear from you so that I can start working on the update before end-July if possible. Thanks for all the good work you've done so far, and for your future answer. Mt -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 zeal depends on: ii libarchive13 3.6.0-1 ii libc6 2.33-7 ii libgcc-s1 12.1.0-2 ii libqt5concurrent5 5.15.2+dfsg-16+b2 ii libqt5core5a 5.15.2+dfsg-16+b2 ii libqt5gui5 5.15.2+dfsg-16+b2 ii libqt5network5 5.15.2+dfsg-16+b2 ii libqt5sql5-sqlite 5.15.2+dfsg-16+b2 ii libqt5webkit5 5.212.0~alpha4-16 ii libqt5widgets5 5.15.2+dfsg-16+b2 ii libqt5x11extras5 5.15.2-2 ii libsqlite3-0 3.38.5-1 ii libstdc++6 12.1.0-2 ii libx11-6 2:1.7.5-1 ii libxcb-keysyms1 0.4.0-1+b2 ii libxcb1 1.14-3 zeal recommends no packages. zeal suggests no packages. -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#1010804: Segfault when applying this patch
package frogatto
tag 1010804 - patch
tag 1010804 + helpneeded
thanks
Hello,
I confirm that the package is not building without this patch, and that the
build proceeds with this patch. But the problem is that the code is segfaulting
systematically when I build the package with this patch. The failure occures
everytime I get out of the house, at the very beginning of the game (all
settings default).
At first I thought it was unrelated, but the valgrind trace is the following:
==549940== Jump to the invalid address stated on the next line
==549940==at 0x0: ???
==549940==by 0x5B62C4: water::draw_area(water::area const&, int, int, int,
int) const (water.cpp:169)
==549940==by 0x5B6705: water::draw(int, int, int, int) const (water.cpp:125)
==549940==by 0x451763: level::draw(int, int, int, int) const
(level.cpp:1930)
==549940==by 0x2FC8C9: render_scene(level const&, screen_position&, entity
const*, bool) (draw_scene.cpp:358)
==549940==by 0x48753B: level_runner::play_cycle() (level_runner.cpp:1410)
==549940==by 0x488B33: level_runner::play_level() (level_runner.cpp:713)
==549940==by 0x1E341E: main (main.cpp:830)
==549940== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==549940==
==549940==
==549940== Process terminating with default action of signal 11 (SIGSEGV)
==549940==at 0x4DED07F: raise (raise.c:45)
==549940==by 0x4DED1FF: ??? (in
/usr/lib/x86_64-linux-gnu/libpthread-2.33.so)
And the line pointed is the following:
#if defined(TARGET_OS_HARMATTAN) || defined(TARGET_PANDORA) ||
defined(TARGET_TEGRA) || defined(TARGET_BLACKBERRY)
if (glBlendEquationOES) {
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);
}
#elif defined(GL_OES_blend_subtract)
glBlendEquationOES(GL_FUNC_REVERSE_SUBTRACT_OES);<-- HERE!
THIS IS LINE 169
#elif defined(USE_GLES2)
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
#else
if(GLEW_EXT_blend_equation_separate && (GLEW_ARB_imaging ||
GLEW_VERSION_1_4)) {
glBlendEquation(GL_FUNC_REVERSE_SUBTRACT);
} else {
const int max_color = std::max(water_color[0],
std::max(water_color[1], water_color[2]));
water_color[0] = (max_color - water_color[0])/8;
water_color[1] = (max_color - water_color[1])/8;
water_color[2] = (max_color - water_color[2])/8;
}
#endif
So I feel bad about applying the patch and uploading the package to the archive.
Any help is welcomed. The package is uptodate on salsa.
Mt
signature.asc
Description: This is a digitally signed message part
Bug#991566: r-cran-bookdown is so old that it fails to even start
retitle 991566 r-cran-bookdown: Please package version 0.25
severity 991566 grave
thanks
Hello,
I just followed the instructions given at
https://bookdown.org/yihui/bookdown/get-started.html but I installed the debian
version of the packages instead.
The command `Rscript -e "bookdown::render_book('index.Rmd',
'bookdown::gitbook')"` gives me the following error message:
```
output file: bookdown-demo.knit.md
/usr/bin/pandoc +RTS -K512m -RTS bookdown-demo.utf8.md --to html4 --from
markdown+autolink_bare_uris+tex_math_single_backslash --output
bookdown-demo.html --lua-filter
/usr/lib/R/site-library/bookdown/rmarkdown/lua/custom-environment.lua
--lua-filter /usr/lib/R/site-library/rmarkdown/rmarkdown/lua/pagebreak.lua
--lua-filter /usr/lib/R/site-library/rmarkdown/rmarkdown/lua/latex-div.lua
--metadata-file /tmp/RtmpeK0v3x/filedc634e3f7795 --wrap preserve --standalone
--section-divs --table-of-contents --toc-depth 3 --template
/usr/lib/R/site-library/bookdown/templates/gitbook.html --highlight-style
pygments --number-sections --css style.css --include-in-header
/tmp/RtmpeK0v3x/rmarkdown-strdc63614fa11d.html --mathjax --filter
/usr/bin/pandoc-citeproc
Error in move_files_html(output, lib_dir) :
object 'is_abs_path' not found
Calls: ... render_cur_session -> -> ->
move_files_html
Execution halted
```
I reported this bug upstream, but they closed it saying that the bookdown
package is ways too old to be of any use, and that I should install the package
directly instead. They are right in some sense, but I'd prefer to use the
Debian packages if possible.
https://github.com/rstudio/bookdown-demo/issues/67
Could you please update the package? I'm tagging the bug as grave since the
package seems unusable as is.
Thanks in advance,
Mt
Bug#1002303: forwarded
forwarded 1002303 https://github.com/mquinson/po4a/issues/343 thanks Hello, thanks for the report. I forwarded it to the github issues tracker to give it a wider exposition. Thanks for your time, Mt -- The only merit of this paper is to demonstrate all what you have to not do when writing an article. -- Bastard Reviewer From Hell signature.asc Description: PGP signature
Bug#998196: More info about this bug
Hello, This bug was already reported as https://github.com/mquinson/po4a/issues/281 You can find more detail of what was going on in there. But thanks for reporting again because I completely forgot about that old bug, and your submission triggered me to actually fix the bug. Bye, Mt.
Bug#998196: tagging 998196
tags 998196 + pending thanks Fixed in upstream git. Thanks for reporting, Mt signature.asc Description: PGP signature
Bug#969175: minetest: No text visible with Polish locale
Hello Does installing the fonts-droid-fallback package also fix the problem? I must confess I'm not even sure that this package exists on buster... Thanks, Mt - Le 23 Sep 21, à 12:55, Maks Nowak a écrit : > Hello > Bug appears in buster (amd64 10.10 + 0.4.17.1+repack-1b1) > Could not reproduce in buster-backports > Could not reproduce in Bullseye. > Minetest reading: [ https://forum.minetest.net/viewtopic.php?t=19662 | > https://forum.minetest.net/viewtopic.php?t=19662 ] [ > https://github.com/minetest/minetest/issues/11349 | > https://github.com/minetest/minetest/issues/11349 ] My findings: > cd /usr/share/fonts/truetype > cp freefont/ [ http://freesans.ttf/ | FreeSans.ttf ] droid/ [ > http://droidsansfallbackfull.ttf/ | DroidSansFallbackFull.ttf ] > and text is visible. > Regards > Maks
Bug#993086: Please package new upstream
Le Tue, Aug 31, 2021 at 08:59:41PM +0200, Julien Puydt a écrit : > > > An helping hand would be really welcome here. We could use salsa to > > collaborate in the update. Please push your changes there when you have > > some. > > > > I finally found some time to open the tracker to see what needed to be > done... Only to see that the latest uploaded version wasn't on salsa. > > Adrian, did you forget a git push --tags? Hello, I just integrated the changes of Adrian (coming from the source package in the archive) to the git on salsa. Thanks again for these changes, back then. Julien, if you want to proceed with packaging the next upstream release, please do so: the new term is rather overwhelming here. Thanks, Mt. -- Les chats, c'est vraiment des branleurs. -- Alain Chabat signature.asc Description: PGP signature
Bug#895222: ITP: howardhinnant-date -- date and time library based on the C++11/14/17 header
Hello Matthijs, any progress on this package? It has been a while, so I was wondering if you managed to get somewhere with this package. If you have something, it'd be great if you could push your work somewhere so that we could help you, if needed. Thanks a lot, Mt. -- La poésie est la preuve la plus flagrante de l'existence de l'homme. -- Gabriel García Márquez signature.asc Description: PGP signature
Bug#993086: Please package new upstream
Hello, sorry for the delay. I'm not very active in minetest these days, and I was buzy updating my other (numerous) outdated packages now that the freeze is over. An helping hand would be really welcome here. We could use salsa to collaborate in the update. Please push your changes there when you have some. Thanks in advance, Mt - Le 27 Aoû 21, à 12:12, Julien Puydt julien.pu...@gmail.com a écrit : > Package: minetest > Version: 5.3.0+repack-2.1 > Severity: wishlist > > I have at least two minetest-mod-* packages (craftguide and moreblocks) > expecting minetest >= 5.4.0 . > > Can you update the package? Perhaps I can lend a hand? > > Cheers, > > J.Puydt
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Thanks for the additional info, and for the patch in the first place. I'll upload it asap. Thx, Mt. signature.asc Description: PGP signature
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, I'm sorry to ask, but I fear I need additional information, please. It seems to me that this patch merely circumvent the change in ImageMagik to allow the handling of eps file during the construction of the package. Am I right, or is it only disabling the dangerous parts of the converter while retrieving the parts we need? Sorry to ask, I'm very bad with ImageMagik. Even if it's re-enabling the conversion of eps files for the package building, I guess that this is a good emergency solution to not delay the release too much, provided that we trust the eps files that come with ns-3. Thanks for the proposal. But I would prefer not to live with such a complex and even somewhat dangerous patch in my package, so I'm curious about other solutions that would allow to convert eps to png without ImageMagik. Maybe using gimp and Script-Fu? Thanks for that patch anyway, Mt Le Fri, Jul 16, 2021 at 06:21:21PM +0200, Dennis Filder a écrit : > Control: tag -1 patch > > With this patch the build finished for me. > > Regards, > Dennis Filder > Description: Override overly strict ImageMagick security policy (#987504) > This patch derives a more permissive ImageMagick security policy from > the system default. > Author: Dennis Filder > Last-Update: 2021-07-16 > Bug-Debian: https://bugs.debian.org/991061 > --- a/ns-3.31/doc/models/Makefile > +++ b/ns-3.31/doc/models/Makefile > @@ -496,6 +496,8 @@ > > RESCALE = ../../utils/rescale-pdf.sh > > +POLFILE = "/etc/$(shell convert -version|sed -n '/^Version: /s@Version: > ImageMagick \([[:digit:]]\+\)\..*@ImageMagick-\1@p')/policy.xml" > + > %.eps : %.dia > @echo dia $(notdir $<) > @$(DIA) -t eps $< -e $@ >/dev/null > @@ -506,7 +508,9 @@ > > %.png : %.eps > @echo convert $(notdir $<) > - @$(CONVERT) $< $@ >/dev/null > + test -d ../../../debian/tmp/ImageMagick || mkdir -p > ../../../debian/tmp/ImageMagick > + test -f ../../../debian/tmp/ImageMagick/policy.xml || sed -e '/ domain="coder" rights="none" pattern="PS" .>/s@"none"@"read|write"@' > "$(POLFILE)" > ../../../debian/tmp/ImageMagick/policy.xml > + XDG_CONFIG_HOME="$(shell pwd)/../../../debian/tmp" $(CONVERT) $< $@ > >/dev/null > > %.pdf : %.eps > @echo epstopdf $(notdir $<) > @@ -556,6 +560,7 @@ > clean: > -rm -rf $(BUILDDIR)/* > -rm -rf $(SOURCETEMP) > + -rm -Rf ../../../debian/tmp/ImageMagick > > frag: pickle > @if test ! -d $(BUILDDIR)/frag; then mkdir $(BUILDDIR)/frag; fi -- The web was not envisioned as a form of television when it was invented. But, like it or not, it is rapidly resembling TV: linear, passive, programmed and inward-looking. -- Hossein Derakhshan https://medium.com/matter/the-web-we-have-to-save-2eb1fe15a426 signature.asc Description: PGP signature
Bug#990923: minetest: diff for NMU version 5.3.0+repack-2.1
> -- Le 15 Juil 21, à 18:59, Adrian Bunk b...@debian.org a écrit : > Dear maintainer, > > I've prepared an NMU for minetest (versioned as 5.3.0+repack-2.1) and > uploaded it to DELAYED/1. Please feel free to tell me if I should cancel it. Dear Adrian, I'm only co-maintainer, and not very active on this package since years (I should probably remove myself from the uploader list), but I would like to thank you for your time. Thanks again, Mt
Bug#991061: ns3 FTBFS with imagemagick with the #987504 change
Hello, thanks for the report. I've read through the bugs both in debian and ubuntu, and I found the location of the issue in the package (ns3 is quite a large package). ns-3.31/doc/models/Makefile reads (many lines omitted): ``` CONVERT = convert # specify figures from which .png and .pdf figures need to be # generated (all dia and eps figures) IMAGES_EPS = \ $(FIGURES)/lena-dual-stripe.eps \ %.png : %.eps @echo convert $(notdir $<) @$(CONVERT) $< $@ >/dev/null ``` Now, the question is about what is the best move from here. I cannot do as in the bug I've seen by Ubuntu where the eps doc was disabled, as we use(d) convert to move the other way around, eps -> png. Is there another way to convert eps to png that I could use (according to google, ImageMagik is THE way to go here), or shall I ship a broken documentation? Any advice would be welcome here. Thanks, Mt. - Le 13 Juil 21, à 15:59, Adrian Bunk b...@debian.org a écrit : > Source: ns3 > Version: 3.29+dfsg-3 > Severity: serious > Tags: ftbfs > > https://tests.reproducible-builds.org/debian/rb-pkg/buster/amd64/ns3.html > > ... > convert lena-dual-stripe.eps > convert-im6.q16: attempt to perform an operation not allowed by the security > policy `PS' @ error/constitute.c/IsCoderAuthorized/408. > convert-im6.q16: no images defined `source-temp/figures/lena-dual-stripe.png' > @ > error/convert.c/ConvertImageCommand/3258. > make[2]: *** [Makefile:475: source-temp/figures/lena-dual-stripe.png] Error 1 > > > See #987504 for background.
Bug#403619: ITP: languagetool -- rule-based language checker
BTW, Andrej, thanks for all the work you've done so far. For all the
info I was summarizing in my previous mail, I was merely following
your tracks.
Do you happen to have a repository somewhere with your current attempt
at packaging LT? Earlier in the bug logs, some people proposed such
initial packaging effort, but it was on alioth and other now
decomissionned infrastructures. If you have something, it'd probably
be a good idea to create a project on salsa.
Thanks again for your time,
Mt
--
You have a problem and decide to use regexps.
Now you have \[0-9\]\{1,\}|\d+ problems.
signature.asc
Description: PGP signature
Bug#403619: ITP: languagetool -- rule-based language checker
On Sun, 13 Dec 2020, at 10:03, Andrej Shadura wrote: > I started working on it back then but I ran into a dependency on > opennlp-models, which come with no license. I tried to find a > workaround but I couldn’t find enough time for that. Just a few informations for the next person interested in it. The opennlp-models have no licencing info because they are models trained on a copyright protected corpus, and it is not clear what happens in such situation. http://mail-archives.apache.org/mod_mbox/opennlp-dev/201912.mbox/browser Github seems to consider that ML is a great IP washer with its copilot, but I'm not sure that this is a good example for the rest of us :) This specific issue is also discussed here: https://github.com/languagetool-org/languagetool/issues/2259 This sounds like a great challenge to me. I'd love to help unlocking this problem, but I have no idea of what it takes to train new models in the first place, not to speak about ensuring that the result has a clean open-source licence. Any hint would be more than welcome here. Bye, Mt. -- Dans le passé, il y avait plus de futur que maintenant. -- Le Chat signature.asc Description: PGP signature
Bug#927076: xournalpp packaging in Debian
> Okay, I used a git snapshot for the version and tarball, and all seems well. Excellent! that's a very good news. It's impressive to see all tests to pass from the first attempt. lintian finds a small issue in the debian/copyright file, but that's all that I see. https://salsa.debian.org/debian/xournalpp/-/jobs/1742060#L32 Thanks, Mt
Bug#927076: xournalpp packaging in Debian
Thanks, it helps the salsa pipeline. But it fails right after, because the git content is too different from the tarball of 1.0.20... I guess there is no easy way to make this pipeline work before the release of 1.1.0. I tend to think that our issues come from the remote tracking of upstream's git in the debian one. In the other packages I'm involved in, we only use `gbp import-orig` to get new upstream content, while keeping the pristine-tar branch in sync. I understand that the situation is very specific for xournalpp, as you wanted to get ready for the upcoming release, but maybe in the future it'd be easier to stick to the classical git-buildpackage workflow? That being said, if you have another workflow that work (on salsa also), I'd be glad to learn new tricks ;) I'm not very well connected to the xournal world. Do you have any hint of when the next release will occur? Thx, Mt
Bug#927076: xournalpp packaging in Debian
I fully agree for not uploading before 1.1.0, so I'd go for the easiest way to please uscan: probably not -hotfix. I prefer not to mess with uscan files, as I confess to I kinda dislike this formalism. But if you insist, I can do. Mt -- It is easier to port a shell than a shell script. -- Larry Wall signature.asc Description: PGP signature
Bug#927076: xournalpp packaging in Debian: how can we help?
Le Mon, Jun 28, 2021 at 12:52:02AM +0100, Barak A. Pearlmutter a écrit : > There is a pristine-tar branch on both salsa and my GitHub fork repo I *think* that the issue comes from uscan: | W: Unable to locate package xournalpp | Trying uscan --download --download-current-version ... | uscan warn: In debian/watch no matching hrefs for version 1.1.0 in watch line | https://github.com/xournalpp/xournalpp/tags (?:.*?/)(?:[-_]?(\d[\-+\.:\~\da-zA-Z]*))(?i)(?:\.(?:tar\.xz|tar\.bz2|tar\.gz|zip|tgz|tbz|txz)) | Could not find any location for xournalpp_1.1.0.orig.tar.* Maybe we should downgrade the entry in debian/changelog to an already released version such as 1.0 to please uscan? Thanks, Mt. -- J'ai un COT. C'est comme un TOC, mais dans l'ordre comme il faut. I have a CDO. It's like OCD, but in alphabetical order as it should be. signature.asc Description: PGP signature
Bug#927076: xournalpp packaging in Debian: how can we help?
Ok, the pipeline is launched. Thanks for the invitation ;) I would not say that I'm very involved, actually. If I can help, I'm glad, but if I don't have to, I'm happy :) If you have difficulties with something, drop me an email. As for the pipeline, it failed, because it seems that there is no pristine-tar branch in the git. I thought that you were using git-buildpackage, but maybe I'm wrong? Mt
Bug#927076: xournalpp packaging in Debian: how can we help?
Thanks for the update (and for all the work). Is it OK if I change what needs to be so that the package gets automatically built on salsa's CI, with lintian and everything launched on it? (I'm a DD so I have the technical right to do so, but I'm asking for your permission anyway) Thanks, Mt.
Bug#927076: xournalpp packaging in Debian: how can we help?
Hello Barak, I'm glad to see that you are still progressing in the packaging of xournalpp. Last year, you said that the main show stopper was the svg licenses, that were unclear. But if I understand correctly, you fixed it too with the following commit. https://salsa.debian.org/debian/xournalpp/-/commit/c58bef48700738fc05e48bc1d4f61cf3830f708c Now, the debian/copyright file looks good to me. Am I right? Is there anything else that should be done, or are we only waiting for the Debian release before you can upload this package to unstable? How could we help? I have another question about the version of xournalpp that you are packaging. It seems to me that you are tracking upstream master, right? Wouldn't it be preferable to track released versions instead? I'm unsure here as I did not dig into upstream releasing policy, so my first feeling may well be wrong. Finally, would you mind if I change what should be on the repo to activate the automatic build pipelines from https://salsa.debian.org/salsa-ci-team/pipeline ? That would give us the packages as build artefact, so that I can use your version of the package without building locally ;) Thanks for all the good job done here, Mt. -- The great thing about TCP jokes is that you always get them. signature.asc Description: PGP signature
Bug#986883: unblock: simgrid/3.25+dfsg-5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package simgrid [ Reason ] simgrid is marked for removal for April 28., because of #858498 that is Serious; this upload fixes that bug. [ ImpactThe ] bug is that the so link of a library can be dead because of a missing dependency between the simgrid packages. This upload removes the solink because the library in question is the JNI bindings, so no user will ever want to link native code against this java- specific library. [ Tests ] Simgrid comes with a rather large test suite in the build tree. Lintian was also ran. [ Risks ] The code is completely trivial. The change is basically to remove the solink from the debian/??.install, and rm it before installing in d/rules. [ 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 ] (Anything else the release team should know: I'm thankful to your work and the time you dedicate to the project :) unblock simgrid/3.25+dfsg-5 -- If you do not expect the unexpected, you will not find it. -- Heraclitus diff -Nru simgrid-3.25+dfsg/debian/changelog simgrid-3.25+dfsg/debian/changelog --- simgrid-3.25+dfsg/debian/changelog 2020-06-14 15:25:31.0 +0200 +++ simgrid-3.25+dfsg/debian/changelog 2021-04-13 09:59:59.0 +0200 @@ -1,3 +1,15 @@ +simgrid (3.25+dfsg-5) unstable; urgency=medium + + * Don't install the libsimgrid-java.so symlink as nobody will ever +want to compile any native code against our JNI bindings. + +This saves a dependency from libsimgrid-dev onto libsimgrid-java +that would be needed to ensure that this link is never dead, but +this would make the whole java world as a dependency of simgrid +development (Closes: #858498). + + -- Martin Quinson Tue, 13 Apr 2021 09:59:59 +0200 + simgrid (3.25+dfsg-4) unstable; urgency=medium * Don't build-depend on libunwind that is only needed by the diff -Nru simgrid-3.25+dfsg/debian/libsimgrid-dev.install simgrid-3.25+dfsg/debian/libsimgrid-dev.install --- simgrid-3.25+dfsg/debian/libsimgrid-dev.install 2020-06-14 15:25:31.0 +0200 +++ simgrid-3.25+dfsg/debian/libsimgrid-dev.install 2021-04-13 09:59:59.0 +0200 @@ -22,7 +22,6 @@ usr/share/man/man1/simgrid_update_xml.1 usr/lib/pkgconfig/simgrid.pc -usr/lib/libsimgrid-java.so usr/lib/libsimgrid.so usr/bin/tesh diff -Nru simgrid-3.25+dfsg/debian/rules simgrid-3.25+dfsg/debian/rules --- simgrid-3.25+dfsg/debian/rules 2020-06-14 15:25:31.0 +0200 +++ simgrid-3.25+dfsg/debian/rules 2021-04-13 09:59:59.0 +0200 @@ -56,14 +56,23 @@ # Make install and prepare package building override_dh_auto_install: dh_auto_install + # Manually install the python module, since upstream fails to do so mkdir -p debian/tmp/usr/lib/python3/dist-packages cp obj-*/lib/simgrid.cpython*.so debian/tmp/usr/lib/python3/dist-packages chrpath -d debian/tmp/usr/lib/python3/dist-packages/simgrid.cpython*.so + # Fix chrpath of binaries chrpath -d debian/tmp/usr/bin/graphicator chrpath -d debian/tmp/usr/lib/simgrid/smpimain mv debian/tmp/usr/bin/graphicator debian/tmp/usr/bin/simgrid-graphicator + + # Remove the so link of the JNI library, as is does not fit in + # libsimgrid-dev without inducing a dependency from simgrid-dev to the + # whole java world, and this library is of no use in the + # native world, only useful in Java (that does not need the so link) + rm debian/tmp/usr/lib/libsimgrid-java.so + # move doc to correct place # mkdir -p debian/tmp/usr/share/doc/simgrid # mv debian/tmp/usr/doc/simgrid/* debian/tmp/usr/share/doc/simgrid/ signature.asc Description: PGP signature
Bug#858498: Please reject simgrid_3.27+dfsg-1
Hello FTP masters, I'm sorry for the extra burden, but I uploaded the new upstream release to unstable by error instead of experimental. This upload needs to be canceled so that I can fix the version in testing. #858498 is RC and was reopened an hour ago. Sorry again for the extra burden, Mt. signature.asc Description: PGP signature
Bug#976704: po4a: Missing dependency on libpod-parser-perl
Hello Helge, it seems to me that this is an upstream bug that you will never encounter when using the Debian package (neither source nor binary). Do you agree? Thanks for reporting, Mt - Le 7 Déc 20, à 9:24, Helge Kreutzmann deb...@helgefjell.de a écrit : > Package: po4a > Version: 0.61-1 > Severity: important > > Trying to build po4a upstream itself (with po4 installed by Debian) > fails with: > > helge@samd:/tmp/po4a-doc$ LC_ALL=C ./Build > Created META.yml and META.json > Discard blib/man/ca/man1/po4a-display-man.xml (6 of 24 strings; only 25% > translated; need 80%). > Discard blib/man/ca/man1/po4a-display-pod.xml (6 of 23 strings; only 26.08% > translated; need 80%). > Unknown format type: pod. > po4a::chooser: Module loading error: Can't locate Pod/Parser.pm in @INC (you > may > need to install the Pod::Parser module) (@INC contains: lib /etc/perl > /usr/local/lib/x86_64-linux-gnu/perl/5.32.0 /usr/local/share/perl/5.32.0 > /usr/lib/x86_64-linux-gnu/perl5/5.32 /usr/share/perl5 > /usr/lib/x86_64-linux-gnu/perl-base > /usr/lib/x86_64-linux-gnu/perl/5.32 > /usr/share/perl/5.32 /usr/local/lib/site_perl) at > lib/Locale/Po4a/Pod.pm line > 14. > BEGIN failed--compilation aborted at lib/Locale/Po4a/Pod.pm > line 14. > Compilation failed in require at (eval 39) line 1. > BEGIN failed--compilation aborted at (eval 39) line 1. > > List of valid formats: > - asciidoc: AsciiDoc format. > - dia: uncompressed Dia diagrams. > - docbook: DocBook XML. > - guide: Gentoo Linux's XML documentation format. > - ini: INI format. > - kernelhelp: Help messages of each kernel compilation option. > - latex: LaTeX format. > - man: Good old manual page format. > - pod: Perl Online Documentation format. > - rubydoc: Ruby Documentation (RD) format. > - sgml: either DebianDoc or DocBook DTD. > - texinfo: The info page format. > - tex: generic TeX documents (see also latex). > - text: simple text document. > - wml: WML documents. > - xhtml: XHTML documents. > - xml: generic XML documents (see also docbook). > - yaml: YAML documents. > Died at Po4aBuilder.pm line 184. > > > After installing libpod-parser-perl, the build suceedes. > > Please note that the information below, that po4a depends on > libpod-parser-perl is incorrect: > root@samd:~# LC_ALL=C apt-get remove libpod-parser-perl > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages will be REMOVED: > libpod-parser-perl > 0 upgraded, 0 newly installed, 1 to remove and 2 not upgraded. > After this operation, 260 kB disk space will be freed. > Do you want to continue? [Y/n] > > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: > LC_ALL > set to de_DE.UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages po4a depends on: > ii gettext 0.19.8.1-10 > ii libpod-parser-perl 1.63-2 > ii libsgmls-perl 1.03ii-36 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b1 > ii perl5.32.0-5 > ii perl-modules-5.22 [libpod-parser-perl] 5.22.2-5 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4+b1 > ii libterm-readkey-perl 2.38-1+b2 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b3 > > po4a suggests no packages. > > -- no debconf information > > -- > Dr. Helge Kreutzmann deb...@helgefjell.de > Dipl.-Phys. http://www.helgefjell.de/debian.php >64bit GNU powered gpg signed mail preferred >Help keep free software "libre": http://www.ffii.de/
Bug#976842: sem_init(3): misleading documentation of the pshared argument
Package: manpages-dev Version: 5.09-2 Severity: normal Hello, the manpage of sem_init(3) reads: The pshared argument indicates whether this semaphore is to be shared between the threads of a process, or between processes. but in fact, this is exactly the opposite (as the name implies). This argument indicates whether the semaphore is to be shared between several processes, or to be private to the current process and shared only between threads of that process. This is confirmed for example by the Open Group version of the same documentation: https://pubs.opengroup.org/onlinepubs/007908799/xsh/sem_init.html Also in the same line: the solaris documentation: https://docs.oracle.com/cd/E19120-01/open.solaris/816-5137/sync-19683/index.html Thanks for packaging this documentation and for centralizing all this work. Mt -- System Information: Versions of packages manpages-dev depends on: ii manpages 5.09-2 -- no debconf information -- Pour ne plus rire jaune, voyez rouge. signature.asc Description: PGP signature
Bug#966280: dpkg-source should ignore CRLF vs. LF differences
Package: dpkg Version: 1.19.7 Severity: normal Hello, when trying to build the new upstream version of Widelands with git- buildpackage, I had an error message saying that some files were modified out of the debian/ directory. It turns out that the difference is only about the line endings: some files of the upstream tarball are encoded with CRLF while most of them are LF only. When importing the files in the upstream branch of my git, the CRLF are automatically converted to LF by git, but when dpkg-source compares the content of the current dir (ie, the checkout) with the content of the tarball, it fails with a rather uninformative error message: dpkg-source: info: local changes detected, the modified files are: widelands-21/cmake/Modules/FindSDL2_image.cmake widelands-21/cmake/Modules/FindSDL2_mixer.cmake widelands-21/cmake/Modules/FindSDL2_ttf.cmake widelands-21/data/maps/Twin_Lagoons_v2.wmf/elemental widelands-21/src/third_party/eris/README.eris dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/widelands_21-1.diff.YyKJqP My first glance at the diff was not enough to understand the pb, stupid me. Instead it took me several hours to understand the issue. I repacked and reimported my upstream tarball quite a few times before that. Then, I had to manually repack the upstream archive after dos2unix'ing the relevant files to fix it. I think that it'd be really better if dpkg-source would ignore those difference in the first place. I'm not completely sure, but I think that this is what the --strip-trailing-cr option of diff is meant for. Thanks for the fish, Mt -- Package-specific info: System tainted due to merged-usr-via-symlinks. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_USER, TAINT_WARN Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 dpkg depends on: ii libbz2-1.0 1.0.8-3 ii libc62.31-1 ii liblzma5 5.2.4-1+b1 ii libselinux1 3.0-1+b3 ii tar 1.30+dfsg-7 ii zlib1g 1:1.2.11.dfsg-2 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt2.1.7 pn debsig-verify -- no debconf information -- A theory is something nobody believes, except the person who made it. An experiment is something everybody believes, except the person who made it. signature.asc Description: PGP signature
Bug#962652: plm: Exercise not working : useless error message
Hello, The problem is that this exercise have two worlds. You can switch between worlds by clicking on the combobox showing "Swiss cheese" in your interface. As you can see, there is no (easy) way to hardcode a path for the buggles that will lead to the solution. It is very often the case in PLM that several worlds are used to have more than one test case for the code provided by the user. They act as separate unit tests for the proposed solution. The same code is run by every buggles in every worlds (some exercises have multiple buggles on the same world, too). In this case, you could still determine which is buggle is running by looking at the local configuration (where the walls are), and then hardcode a solution for each of them. So the exercise is not as robust as one could hope, but I'm not sure that it is worth fixing it. The maze lesson is just for fun anyway, the pedagogical value is not very high. A better fix would be to: - Change the error message to hint about the possibility that it occured in another world than the one currently displayed - Make the combobox blink in red for the same effect I think I prefer the first solution, because I'd like to change the PLM interface to move toward JavaFX so I prefer to not invest too much time to fix that swing interface. Do you confirm my analysis and validate my proposed fix? Thanks for your interest, Mt. - Le 11 Juin 20, à 12:06, Georges Khaznadar georg...@debian.org a écrit : > Package: plm > Version: 2.8.1-1 > Severity: normal > > Dear Maintainer, > > * I started plm, with locale=fr.FR-UTF8, and selected Python > language, then chose exercise #1: "RandomMouseMaze" > * I wrote a program to drive the buggle to its destination; > you can check the program in the attached screenshot and > attached source file. > * The target of the exercise was reached, but a spurious > warning is emitted when the buggle reaches a fork in the > maze, just after the interpretation of the substring > "DAGAGADAADAA". When the target is reached, I can read a > report about the program's behaviour which I cannot > understand. > > > *** End of the template - remove these template lines *** > > > > -- System Information: > Debian Release: bullseye/sid > APT prefers stable > APT policy: (900, 'stable'), (499, 'testing'), (400, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_FR.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 plm depends on: > ii default-jdk 2:1.11-72 > ii java-wrappers0.3 > ii jruby9.1.17.0-3 > ii jython 2.7.2+repack1-1 > ii libgettext-commons-java 0.9.6-6 > ii libhttpclient-java 4.5.11-1 > ii libhttpcore-java 4.4.13-1 > ii libhttpmime-java 4.5.11-1 > ii libjgit-java 3.7.1-6 > ii libjson-simple-java 2.3.0-1 > ii libmiglayout-java5.1-2 > ii librsyntaxtextarea-java 2.5.8-1 > ii scala2.11.12-4 > ii scala-library2.11.12-4 > > plm recommends no packages. > > plm suggests no packages. > > -- no debconf information > > *** /tmp/random_mouse_maze.py > chemin="DAGAGADAADAADAAGADA" > for c in chemin: >if c=="D": > droite() >elif c=="G": > gauche() >elif c=="A": > avance()
Bug#962368: frogatto-data: Source-only upload not automatically built for non-free packages
Hello, thanks for pointing me to this, I didn't know. And even now, I'm not sure of whether frogatto-data is auto-buildable. The reason why it's non-free is because the licence file states: "The Frogatto game and all content is available for download free of charge from http://www.frogatto.com. The game may be redistributed for non-commercial purposes so long as the entire package is kept in-tact and unmodified. This license must also be included and kept in-tact. It is forbidden to distribute the game, or any portion thereof for any commercial or revenue-generating purpose." Under this light, should I mark the package as auto-buildable? I tend to think so but would appreciate your guidance. In the meanwhile, I'll do a source+binary upload of the package. Thanks again, Mt. - Le 7 Juin 20, à 0:05, Boyuan Yang by...@debian.org a écrit : > Source: frogatto-data > Severity: serious > Version: 1.3.1+dfsg-2 > X-Debbugs-CC: mquin...@debian.org > > Dear Debian frogatto-data maintainers, > > Thanks for updating package frogatto-data in Debian. However, you just > made a source-only upload against a non-free package, which would cause > problems. > > By default, Debian's buildd will not build non-free packages due to > licensing concerns. If your package has no licensing concerns, please > follow instructions as written in the Developers Reference [1] to mark > the package as auto-buildable. If not, please make a binary-only upload > (or a source+binary upload) to actually make sure that the deb package > exists in the archive. > > -- > Regards, > Boyuan Yang > > [1] > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#marking-non-free-packages-as-auto-buildable
Bug#962243: po4a: POD parser marks =begin/=for/=end format name for translation
Hello Guillem, thanks for the report. I agree that we should move on to Pod::Simple. I started a discussion with the pod-people for guidance, but the ball seems to be on my side now. Too bad I cannot get it rolling right now :( https://www.nntp.perl.org/group/perl.pod-people/2020/05/msg2106.html Any help would be really appreciated here... Thanks, Mt. On Fri, Jun 05, 2020 at 03:27:49AM +0200, Guillem Jover wrote: > Package: po4a > Version: 0.59.1-1 > Severity: normal > > Hi! > > The POD parser marks the format name in =begin/=for/=end tags as > translatable, but this text should not be translated as it is part of > the syntax. I've very briefly checked the po4a and Pod::Parser code > and didn't see an obvious way to handle this, but then realized that > Pod::Parser is being phased out in favor of Pod::Simple, which does > seem to support handling these tags explicitly. > > Here's a test case: > > ,--- format.pod --- > =head1 Title > > =begin format-block > > Some format-specific text. > > =end format-block > > Some B text. > > =for format-for More format-specific text. > `--- > > ,--- po4a-gettextize -f pod -m format.pod --- > […] > #. type: =head1 > #: format.pod:1 > msgid "Title" > msgstr "" > > #. type: =end > #: format.pod:3 format.pod:7 > msgid "format-block" > msgstr "" > > #. type: textblock > #: format.pod:5 > msgid "Some format-specific text." > msgstr "" > > #. type: textblock > #: format.pod:9 > msgid "Some B text." > msgstr "" > > #. type: =for > #: format.pod:11 > msgid "format-for More format-specific text." > msgstr "" > `--- > > Both «format-block» and «format-for» should not be appearing here. :) > > Thanks, > Guillem -- L'enseignement des résultats de la science n'est jamais un enseignement scientifique. -- Gaston Bachelard. signature.asc Description: PGP signature
Bug#962118: screenkey: Produces invalid config file, throwing an exception at startup
Package: screenkey
Version: 1:0.10~rc1-1
Severity: normal
Dear maintainer,
I launched screenkey a few times, but now when I try to do so, I get the
following output in my terminal:
---
Traceback (most recent call last):
File "/usr/bin/screenkey", line 104, in
main()
File "/usr/bin/screenkey", line 96, in main
app = sc.Screenkey(logger=logger, options=options,
show_settings=args.show_settings)
File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 108, in
__init__
self.set_active_monitor(self.options.screen)
File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 173, in
set_active_monitor
self.update_geometry()
File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 230, in
update_geometry
inverse_offset_x = g[4]
IndexError: list index out of range
---
I straced the program, and it seems to read from
/home/mquinson/.config/screenkey.json, which content follows (I did not change
it myself):
---
{"no_systray": false, "timeout": 1.0, "recent_thr": 0.1, "compr_cnt": 3,
"ignore": [], "position": "fixed", "persist": false, "font_desc": "Sans Bold",
"font_size": "medium", "font_color": "white", "bg_color": "black", "opacity":
0.8, "key_mode": "composed", "bak_mode": "baked", "mods_mode": "normal",
"mods_only": false, "multiline": false, "vis_shift": false, "vis_space": true,
"geometry": [589, 877, 503, 120], "screen": 0, "window": null}
---
When I remove this file from my disk, screenkey starts properly again. I'm
surprised because, like I said, I never modified this file myself. I remember
playing with the settings using the graphical tool that appeared in my tool
tray, but I cannot remember of what I modified, sorry.
Thanks for maintaining this package,
Mt
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-2-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_USER
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages screenkey depends on:
ii libx11-6 2:1.6.9-2+b1
ii python33.8.2-3
ii python3-cairo 1.16.2-3
ii python3-gi 3.36.0-3
screenkey recommends no packages.
screenkey suggests no packages.
-- no debconf information
--
Strong reject, for obvious reasons. -- Bastard Reviewer From Hell
signature.asc
Description: PGP signature
Bug#960892: another fix
Control: -1 fixed-upstream Thanks On Fri, May 22, 2020 at 02:35:34AM +0200, Axel Beckert wrote: > Hi Martin. > > Martin Quinson wrote: > > I gave another try to this fix, and the current git version of po4a > > manages to build aptitude even with the recent patch removed. > > > > Could you please give it a try, just to ensure that I didn't mess up > > my verification? > > Can confirm. Thanks for caring! Thanks for this test. I'm happy that this bug is gone now. I will release a new upstream version on Sunday. I'm just giving a few days to the translators to update their work since the fix introduced some strings, and since you have a temporarily fix in aptitude. Have a good one, Mt. -- Walking on water and developing software from a specification are easy if both are frozen. signature.asc Description: PGP signature
Bug#960892: another fix
Hello, I gave another try to this fix, and the current git version of po4a manages to build aptitude even with the recent patch removed. Could you please give it a try, just to ensure that I didn't mess up my verification? Thanks in advance, Mt. -- Reject: The reference on the SimGrid toolkit is outdated. -- Bastard Reviewer From Hell signature.asc Description: PGP signature
Bug#960892: po4a: --srcdir ignored by [po_directory]
Hello, your patch was included in an upstream release. The debian package should be updated shortly. Thanks for your patience, Mt. -- You have a problem and decide to use floats. Now you have 2.0001 problems. signature.asc Description: PGP signature
Bug#960945: po4a: Double spacing generated when source contains parens on EOL
Hello, On Tue, May 19, 2020 at 01:53:05AM +0200, Guillem Jover wrote: > Hi! > > On Mon, 2020-05-18 at 22:12:04 +0200, Martin Quinson wrote: > > - Le 18 Mai 20, à 18:58, Guillem Jover guil...@debian.org a écrit : > > > > When there is a closing parenthesis at the end of line, po4a parses it > > > and injects two spaces in the msgid text. I've noticed this when > > > reviewing the generated «.po» files from both troff and POD source. [...] > > actually, the POD parser in po4a is implemented with a third party > > library. I cannot do anything unless I completely reimplement the > > parser myself. > > But this affects also the man parser, so I assumed this would be a > problem with po4a itself, otherwise I'm happy to get this reassigned > to perl, as Pod::Parser seems to the external module used? Ahem, sorry, I read it too quickly earlier. In this case, I tend to blame libtext-wrapi18n-perl but I'll have to do some more tests before reassigning. > > I would rather advise to use asciidoc for a newly written documentation. > > I'm considering converting the po4a doc to this format, actually. > > For more complex documentation asciidoc would also be my preference. > But for man pages I think POD is fairly adequate, in terms of format > complexity, availability and dependency weight. For dpkg there's also > the additional constraint of not wanting to have to require new stuff, > and perl is already a build dependency. :) Ah. You mean you're not only translating the doc, you also want to display it to the users? Ok, fair enough, I forgot about this little detail :) Thanks for your interest into po4a, Mt. -- La moitié des chercheurs passe son temps à remplir des demandes que l’autre moitié perd beaucoup de temps à lire. -- André Brahic signature.asc Description: PGP signature
Bug#960945: po4a: Double spacing generated when source contains parens on EOL
Hello Guillem, actually, the POD parser in po4a is implemented with a third party library. I cannot do anything unless I completely reimplement the parser myself. I would rather advise to use asciidoc for a newly written documentation. I'm considering converting the po4a doc to this format, actually. Sorry, Mt. - Le 18 Mai 20, à 18:58, Guillem Jover guil...@debian.org a écrit : > Package: po4a > Version: 0.58.1 > Severity: normal > > Hi! > > When there is a closing parenthesis at the end of line, po4a parses it > and injects two spaces in the msgid text. I've noticed this when > reviewing the generated «.po» files from both troff and POD source. > > Here's a test case: > > ,--- test.pod --- > =head1 NAME > > test - some test > > =head1 DESCRIPTION > > Some B(5) > some other (parenthetical text) > which produce (only when at the end of line) double spacing, > in the generated (.po) > file. > `--- > > ,--- sh --- > $ po4a-gettextize -f pod -m test.pod > […] > #. type: textblock > #: test.pod:7 > msgid "" > "Some B(5) some other (parenthetical text) which produce (only when " > "at the end of line) double spacing, in the generated (.po) file." > msgstr "" > `--- > > Of course one problem that fixing this is that it will imply probably > tons of fuzzying, which might even flip-flop depending on the po4a > version used, so perhaps an explicit option would be required here to > control the behavior, not sure. :/ > > Thanks, > Guillem
Bug#960949: po4a: Cannot match some generic text in addenda header
Hello Guillem, thanks for your interest. I was thinking about a specific mode=eof that would not need a position nor a boundary to put the addendum at the end of the file. Would it fit your needs? Bye, Mt. - Le 18 Mai 20, à 19:31, Guillem Jover guil...@debian.org a écrit : > Package: po4a > Version: 0.58.1-1 > Severity: normal > > Hi! > > While converting the dpkg man pages from troff to POD, I needed to > convert the addenda too, which was using this header for all addenda: > > ,--- > PO4A-HEADER:mode=after;position=^\.TH;beginboundary=FakePo4aBoundary > `--- > > Which is nice and generic. But for POD I had to use a different one per > locale, such as: > > ,--- > PO4A-HEADER:mode=after;position=^=head1 NOM;beginboundary=FakePo4aBoundary > `--- > > Because I was unable to match neither «^=encoding» nor the > «GENERATED FILE» string inserted by po4a on the output files. And while > the second might be fragile, as it could change, the former is part of > the source, so under the developer control, and it would be nice to be > able to use that. > > Using a localized section name works, but seems problematic as it depends > on the translation for that section not changing, and while certainly not > fatal, it's a bit annoying. :) > > Thanks, > Guillem
Bug#960892: po4a: --srcdir ignored by [po_directory]
On Mon, May 18, 2020 at 11:04:27AM +0200, Martin Quinson wrote: > In the meanwhile, I also > added some more verbose error messages around this feature. I'd be > great if you could give a try to the master version of po4a. Providing > the --verbose option may also help. I meant: git clone --depth=1 https://salsa.debian.org/mquinson/po4a.git PERLLIB=./po4a/lib ./po4a/po4a Thanks, Mt. -- It is easier to port a shell than a shell script. -- Larry Wall signature.asc Description: PGP signature
Bug#960892: po4a: --srcdir ignored by [po_directory]
Hello, I tried to reproduce your bug with the integrated tests, but I failed to do so: https://travis-ci.org/github/mquinson/po4a/jobs/688267439#L2702 In the test, I have a line "[po_directory] po" in the config file, and it works with --srcdir and --destdir, all combinaisons: Test44: Change directory to cfg/single-podirectory perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --destdir t/tmp/cfg/single-podirectory Test45: Change directory to tmp/cfg/single-podirectory-src perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --srcdir t/cfg/single-podirectory Test46: perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf --srcdir cfg/single-podirectory --destdir tmp/cfg/single-podirectory-srcdst Test47: Change directory to tmp/cfg/single-podirectory-cur perl po4a -f BUILDPATH/t/cfg/single-podirectory/po4a.conf Maybe it's because I use the full path to the conf file, but it seems from your logs that this file is found, so I'm not sure. I'll try to debug po4a using the aptitude package directly, but not right away, I must do something IRL before... In the meanwhile, I also added some more verbose error messages around this feature. I'd be great if you could give a try to the master version of po4a. Providing the --verbose option may also help. Thanks, Mt. On Mon, May 18, 2020 at 12:56:15AM +0200, Axel Beckert wrote: > Package: po4a > Version: 0.58.1-1 > Severity: important > Control: affects -1 src:aptitude > Control: block 960865 by -1 > > Dear Martin, > > previously when building aptitude's documentation, it sufficed to > declare > > [po_directory] po4a/po > > in doc/po4a/po4a.cfg and then calling from the out-of-tree build > directory in e.g. "build/doc/de/" > > /usr/bin/po4a --translate-only=de/manpage.xml --srcdir=../../../doc > --destdir=../../doc ../../../doc/po4a/po4a.cfg > > but since recently, this fails with the IMHO not very helpful error > message: > > ../../../doc/po4a/po4a.cfg:1: no PO files found in po4a/po > > See https://bugs.debian.org/960865. > > The following change to doc/po4a/po4a.cfg fixes this: > > -[po_directory] po4a/po > +[po_directory] ../../../doc/po4a/po > > But this hardcoding of the relative path to the directory given with > --srcdir IMHO contradicts what is written in the man page: > >--srcdir SRCDIR >Set the base directory for all input documents specified in >the po4a configuration file. > >If both destdir and srcdir are specified, input files are >searched in the following directories, in order: destdir, >srcdir and the current directory. Output files are written to >destdir if specified, or to the current directory. > > Is there a chance that it has been forgotten to also check for the > po_directory under the directory given by --srcdir? > > -- System Information: > Debian Release: bullseye/sid > APT prefers unstable > APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), > (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), > (1, 'buildd-experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 > (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > LSM: AppArmor: enabled > > Versions of packages po4a depends on: > ii gettext0.19.8.1-10 > ii libsgmls-perl 1.03ii-36 > ii libyaml-tiny-perl 1.73-1 > ii opensp 1.5.2-13+b1 > ii perl 5.30.0-10 > > Versions of packages po4a recommends: > ii liblocale-gettext-perl 1.07-4 > ii libterm-readkey-perl 2.38-1+b1 > ii libtext-wrapi18n-perl 0.06-9 > ii libunicode-linebreak-perl 0.0.20190101-1+b2 > > po4a suggests no packages. > > -- no debconf information > -- You know you have a distributed system when the crash of a computer you never heard of stops you from getting any work done. -- L. Lamport signature.asc Description: PGP signature
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Hello, On Mon, May 18, 2020 at 12:59:26AM +0200, Gilles Filippini wrote: > > Here is a patch to apply on top of your current git repo. It fixes > plm.users read / write and sessions- welcome.summary read. It works like a charm, thanks a lot. I'm currently uploading the updated package. Bye, Mt. -- The difference between theory and reality is that in theory, there is no difference. signature.asc Description: PGP signature
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Hello again, when I try to launch the program with your patch applied, I get the following backtrace: Exception in thread "main" java.lang.ClassCastException: class org.json.simple.JsonArray cannot be cast to class org.json.simple.JsonObject (org.json.simple.JsonArray and org.json.simple.JsonObject are in unnamed module of loader 'app') at plm.core.model.Users.loadUsersFromFile(Unknown Source) at plm.core.model.Users.(Unknown Source) at plm.core.model.Game.(Unknown Source) at plm.core.model.Game.getInstance(Unknown Source) at plm.core.ui.ProgrammersLearningMachine.main(Unknown Source) I will try to fix it in the near future, but your help would of course be welcome. Don't modify your patch as it is applied and burried under other changes already. Instead, please propose another patch on top of the current state in the package in https://salsa.debian.org/java-team/plm/ Btw, I fixed a bug in the package that made it unusable on new installation since maybe 4 years. It was only working with openjdk7 :( Now, you should be able to start the program with the plm helper script. Thanks for your help, Mt. On Sun, May 17, 2020 at 08:23:36AM +0200, Martin Quinson wrote: > Hello Gilles, > > many thanks for your help, this package is in a rather sorry state, > and I promise myself to do something about it since a long time. > Hopefully this will be the nodge I needed :) > > I happen to be the upstream maintainer of this software, and I'd like > to make things simpler if possible. Is it possible to update the code > so that the patch does not depend on the used version? > > I will try to apply this patch, and then patch upstream to use json-simple-3 > only. > > Thanks, Mt. > > On Thu, May 14, 2020 at 11:28:01PM +0200, Gilles Filippini wrote: > > Package: src:plm > > Version: 2.6+repack-3 > > Severity: normal > > Tags: patch > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA512 > > > > Hi, > > > > I'd like to transition json-simple 3.1.1 to unstable, but plm is a blocker > > since it builds against libjson-simple-java << 3 only. > > > > The json-simple classes used by plm were deprecated in version 2.0.0 [1]. > > There were removed in versions 3.x [2]. > > > > [1] > > https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt > > [2] > > https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG > > > > Please find attached a patch proposal to use the current json-simple > > classes. I've tested that the package builds correctly against > > libjson-simple-java version 2.3.0-1 from unstable and version 3.1.1-1~exp2 > > currently in experimental. But I don't known how to test the package > > afterward. > > > > Thanks in advance for considering. > > > > _g. > > > > -- System Information: > > Debian Release: buster/sid > > Architecture: amd64 (x86_64) > > Foreign Architectures: i386 > > > > Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores) > > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) > > Shell: /bin/sh linked to /bin/dash > > Init: systemd (via /run/systemd/system) > > LSM: AppArmor: enabled > > > > > > > diff -Nru plm-2.6+repack/debian/changelog plm-2.6+repack/debian/changelog > > --- plm-2.6+repack/debian/changelog 2016-09-18 16:39:19.0 +0200 > > +++ plm-2.6+repack/debian/changelog 2020-05-14 18:05:12.0 +0200 > > @@ -1,3 +1,10 @@ > > +plm (2.6+repack-3.1) UNRELEASED; urgency=medium > > + > > + * Non-maintainer upload. > > + * Tentative patch to build against json-simple 3 > > + > > + -- Gilles Filippini Thu, 14 May 2020 18:05:12 +0200 > > + > > plm (2.6+repack-3) unstable; urgency=medium > > > >* Add run-time dependencies on default-jdk, jython and jruby. > > diff -Nru plm-2.6+repack/debian/patches/json-simple-3.patch > > plm-2.6+repack/debian/patches/json-simple-3.patch > > --- plm-2.6+repack/debian/patches/json-simple-3.patch 1970-01-01 > > 01:00:00.0 +0100 > > +++ plm-2.6+repack/debian/patches/json-simple-3.patch 2020-05-14 > > 18:05:12.0 +0200 > > @@ -0,0 +1,595 @@ > > +Description: Migrate away from deprecated json-simple 1.x classes > > + See json-simple 2.0.0 changelog: > > + > * Deprecated JSONParse and JSONValue in favor of Jsoner. > > + > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable. > > + > * Deprecated JSONObject in favor of JsonObject. > > + > * Deprec
Bug#960632: src:plm: Please add support to build against libjson-simple-java >= 3
Hello Gilles,
many thanks for your help, this package is in a rather sorry state,
and I promise myself to do something about it since a long time.
Hopefully this will be the nodge I needed :)
I happen to be the upstream maintainer of this software, and I'd like
to make things simpler if possible. Is it possible to update the code
so that the patch does not depend on the used version?
I will try to apply this patch, and then patch upstream to use json-simple-3
only.
Thanks, Mt.
On Thu, May 14, 2020 at 11:28:01PM +0200, Gilles Filippini wrote:
> Package: src:plm
> Version: 2.6+repack-3
> Severity: normal
> Tags: patch
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Hi,
>
> I'd like to transition json-simple 3.1.1 to unstable, but plm is a blocker
> since it builds against libjson-simple-java << 3 only.
>
> The json-simple classes used by plm were deprecated in version 2.0.0 [1].
> There were removed in versions 3.x [2].
>
> [1]
> https://github.com/cliftonlabs/json-simple/blob/json-simple-2.0.0/README.txt
> [2]
> https://github.com/cliftonlabs/json-simple/blob/json-simple-3.0.1/CHANGELOG
>
> Please find attached a patch proposal to use the current json-simple classes.
> I've tested that the package builds correctly against libjson-simple-java
> version 2.3.0-1 from unstable and version 3.1.1-1~exp2 currently in
> experimental. But I don't known how to test the package afterward.
>
> Thanks in advance for considering.
>
> _g.
>
> -- System Information:
> Debian Release: buster/sid
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8),
> LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>
> diff -Nru plm-2.6+repack/debian/changelog plm-2.6+repack/debian/changelog
> --- plm-2.6+repack/debian/changelog 2016-09-18 16:39:19.0 +0200
> +++ plm-2.6+repack/debian/changelog 2020-05-14 18:05:12.0 +0200
> @@ -1,3 +1,10 @@
> +plm (2.6+repack-3.1) UNRELEASED; urgency=medium
> +
> + * Non-maintainer upload.
> + * Tentative patch to build against json-simple 3
> +
> + -- Gilles Filippini Thu, 14 May 2020 18:05:12 +0200
> +
> plm (2.6+repack-3) unstable; urgency=medium
>
>* Add run-time dependencies on default-jdk, jython and jruby.
> diff -Nru plm-2.6+repack/debian/patches/json-simple-3.patch
> plm-2.6+repack/debian/patches/json-simple-3.patch
> --- plm-2.6+repack/debian/patches/json-simple-3.patch 1970-01-01
> 01:00:00.0 +0100
> +++ plm-2.6+repack/debian/patches/json-simple-3.patch 2020-05-14
> 18:05:12.0 +0200
> @@ -0,0 +1,595 @@
> +Description: Migrate away from deprecated json-simple 1.x classes
> + See json-simple 2.0.0 changelog:
> + > * Deprecated JSONParse and JSONValue in favor of Jsoner.
> + > * Deprecated JSONStreamAware and JSONAware in favor of Jsonable.
> + > * Deprecated JSONObject in favor of JsonObject.
> + > * Deprecated JSONArray in favor of JsonArray.
> + .
> + This patch uses the new json-simple Json* classes. It is compatible with
> + both 2.x and 3.x json-simple releases, with a few ajustments regarding
> + backward incompatible changes in json-simple 3.x:
> + - The package name, changed to com.github.cliftonlabs.json_simple
> + - The exception DeserializationExcetpion renamed as JsonException
> + These two changes are handled using place-holders @JSON_SIMPLE_PACKAGE@
> + and @JSON_EXCETPION@ which are substituted at build time by debian/rules.
> + .
> + With these tricks the package is compatible with json-simple 2.x and 3.x.
> +Author: Gilles Filippini
> +Index: plm-2.6+repack/src/plm/core/model/Course.java
> +===
> +--- plm-2.6+repack.orig/src/plm/core/model/Course.java
> plm-2.6+repack/src/plm/core/model/Course.java
> +@@ -4,9 +4,9 @@ import java.io.IOException;
> + import java.util.ArrayList;
> + import java.util.Map;
> +
> +-import org.json.simple.JSONArray;
> +-import org.json.simple.JSONObject;
> +-import org.json.simple.JSONValue;
> ++import @JSON_SIMPLE_PACKAGE@.JsonArray;
> ++import @JSON_SIMPLE_PACKAGE@.JsonObject;
> ++import @JSON_SIMPLE_PACKAGE@.Jsoner;
> +
> + /**
> + * Class to manage course data online
> +@@ -50,7 +50,7 @@ public abstract class Course {
> + * A user password is set to push data, a teacher password to
> administrate course
> + */
> + public ServerAnswer create() {
> +-JSONObject jsonObject = new JSONObject();
> ++JsonObject jsonObject = new JsonObject();
> + jsonObject.put("action", "new");
> + jsonObject.put("course", courseId);
> + jsonObject.put("password", password);
> +@@ -72,7 +72,7 @@ public abstract class Course {
> + * and by exercise
> + */
> + public String refresh() {
> +-JSONObject jsonObject = new
Bug#882584: Found the salsa package
On Sat, Mar 14, 2020 at 09:02:49PM +, Mike Gabriel wrote: > On Sa 14 Mär 2020 00:36:21 CET, Martin Quinson wrote: > > > https://salsa.debian.org/debian-edu-pkg-team/openboard/ > > > > could we however modify this git repository to use git-buildpackage? > > It makes things so much easier to maintain... > > > > Thanks for your work, > > Mt > > Sorry, no. I see myself in a constant process of removing more and more > files from the upstream Git tag/tarball, because files are non-DFSG for this > or that reason. I am not willing to pollute the salsa repo with these > changes. Ok, you know that better than I do. > To get openboard on salsa built, these steps should work: > > $ git clone https://salsa.debian.org/debian-edu-pkg-team/openboard.git > $ cd openboard > $ debian/rules get-orig-source > $ debuild -uc -us -S -Zxz -d > $ dpkg-source -x openboard_.dsc > $ cd openboard- > $ debuild -uc -us I just tried, and it fails on the last step because of missing dependencies. Maybe we could add a .gitlab-ci attempting these steps so that we see where we currently stand? > IIRC, the current version on the repo's master branch only works / builds > well on Debian testing/unstable. Do you have a list of tasks to be completed? I'm willing to help if I can (given my scarce spare time), but I feel a bit helpless here. You are clearly in the middle of something, and I'd really appreciate if you could save some time to explain what remains to be done and how one could help with this packaging. Anyway, thanks for this work. Mt -- So the question is not whether we will be extremists, but what kind of extremists we will be. [..] Perhaps the world [is] in dire need of creative extremists.--- Martin Luther King, Jr signature.asc Description: PGP signature
Bug#882584: Found the salsa package
https://salsa.debian.org/debian-edu-pkg-team/openboard/ could we however modify this git repository to use git-buildpackage? It makes things so much easier to maintain... Thanks for your work, Mt signature.asc Description: PGP signature
Bug#882584: Any progress on packaging openboard?
Hello, is there any progress in this packaging? Is the current package somewhere on salsa where we could help? I will need such a software with my students (due to the covid outbreak), so I'm highly interested. Thanks, Mt. signature.asc Description: PGP signature
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
Hello, On Mon, Mar 09, 2020 at 08:55:00AM +0100, John Paul Adrian Glaubitz wrote: > On 3/9/20 3:31 AM, Martin Quinson wrote: > > I'm currently building the next version of the package to include > > this. Thanks all for the patches. > > You should be able to enable Java on any architecture but not ns3 > (not sure if that's related to the Java stuff). There is no link between the java and the ns-3 stuff in SimGrid, so we're safe. > > On Mon, Mar 09, 2020 at 12:09:14AM +0100, Aurelien Jarno wrote: > >> [1] Note that #950527 provides a patch to build a 64-bit binutils version > >> on > >> some 32-bit architectures that should make ns3 buildable again on > >> mipsel. > > > > Cool! thanks for the pointer. I subscribed to the PR on salsa to > > follow this. > > I think the sensible choice is then to change the libns3-dev dependency > to "libns3-dev [!mipsel]". I think it should be OK now: https://salsa.debian.org/debian/simgrid/-/commit/fd9c3ef7f78a48718dc008e16649b49d7e424bf1 Thanks for your interest, Mt -- The whole history of computer science is one of ever rising levels of abstraction. -- Grady Booch signature.asc Description: PGP signature
Bug#953394: simgrid: FTBFS on riscv64 due to disabled java support
Hello, I'm currently building the next version of the package to include this. Thanks all for the patches. On Mon, Mar 09, 2020 at 12:09:14AM +0100, Aurelien Jarno wrote: > [1] Note that #950527 provides a patch to build a 64-bit binutils version on > some 32-bit architectures that should make ns3 buildable again on > mipsel. Cool! thanks for the pointer. I subscribed to the PR on salsa to follow this. Bye, Mt. -- For every complex problem there is a solution which is simple, neat and wrong. signature.asc Description: PGP signature
Bug#951115: Bug opened
I just opened #951292: RM: ns3 [mipsel] -- RoM, ANAIS; The package FTBFS on this architecture, because of the toolchain Hopefully the package will be allowed to transition to testing before 18/2, the testing removal date. Or soon after. signature.asc Description: PGP signature
Bug#951292: RM: ns3 [mipsel] -- RoM, ANAIS; The package FTBFS on this architecture, because of the toolchain (see #951115)
Package: ftp.debian.org Severity: normal Hello all, the linker dies with an OOM when trying to build ns3 on mipsel. As discussed in #951115 with a mipsel porter (who happens to be a former maintainer of this package), this architecture should be removed for that package for the time being. I uploaded a new version of the package, without mipsel, and I now need to get that version transitionning to testing, please. Please be patient if I'm not following the right procedure here. I'm not asking for package removal every day... Thanks for your work, Mt. Note: this was a request for a partial removal from testing, converted in one for unstable -- Simplicity does not precede complexity, but follows it. -- "Epigrams in Programming", by Alan J. Perlis of Yale University. signature.asc Description: PGP signature
Bug#951115: New version uploaded
severity 951115 normal thanks Hello, so I uploaded a version of this package without mipsel, and it built nicely on all architectures where its dependencies are to be found (all official architectures plus some others). Thus downgrading this bug. Thanks, Mt. signature.asc Description: PGP signature
Bug#951115: ns3: FTBFS on mipsel (OOM of the linker)
Source: src:ns3 Version: 3.30+dfsg-3.1 Severity: serious Tag: ftbfs Tag: help Hello, I'm the maintainer of this package. I'm opening this bug to discuss the issue with whom may be interested, and keep track of the discussion. The package is currently trying to enter testing to fix 2 (easy) RC bugs, but fails to do so because builds fail on mipsel with the following message: -- as: out of memory allocating 17107680 bytes after a total of 567459840 bytes /tmp/cc23jwIU.s: Assembler messages: /tmp/cc23jwIU.s: Fatal error: can't close /<>/ns-3.30/build- shared/src/lte/bindings/ns3module.cc.7.o: memory exhausted -- I tried to reduce the memory consumption with the following chunks in debian/rules: -- ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Drop the debug symbols all together on mipsel to avoid OOM causing FTBFS export DEB_CFLAGS_MAINT_STRIP=-g export DEB_CXXFLAGS_MAINT_STRIP=-g endif LDFLAGS+=-Wl,--as-needed # Define CFLAGS and friends to harden the build -- must come any addition to these variables DPKG_EXPORT_BUILDFLAGS = 1 include /usr/share/dpkg/buildflags.mk ifeq ($(DEB_HOST_GNU_CPU),mipsel) # Further reduce the memory consumption on mipsel LDFLAGS += -Wl,--reduce-memory-overheads -Wl,--no-keep-memory endif --- The version that failed on the buildd servers does not have these changes, but I tested it on the porterbox. I manually inspected the command-line parameters passed to the parser, and it seem to be all right. Compiling without -g and linking with the reduce-memory-overheads (unless I'm wrong). But this is not sufficient: I get exactly the same error message. In addition, I don't think that this is a real bug of as. ns-3 is a very large library, and upstream is not paying a lot of effort on reducing its size or optimizing the linking phase. I don't have any idea of how to fix it myself. I guess that I should ask for the removal of the mipsel version of this package, but I'm not entirely sure. I'd love to have ns-3 building on every platform, even if I'm certain that nobody will ever try to use it on this platform. This is a rather inefficient simulator used in science. Users will more probably deploy it to a fast compute server. But still, if possible, being compilable on mipsel too would be healthy for the software, if I could. Any help or advice is really really welcomed. Everything is in the salsa repository. Thanks, Mt -- Vae Soli. signature.asc Description: PGP signature
