Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin
Control: owner -1 ! Hi Joshua, Joshua Peisach writes: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "kotlin-mode": > > * Package name: kotlin-mode >Version : 20210917git0-1 >Upstream Author : Emacs Kotlin Mode Maintainers > * URL : > https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode > * License : GPL-3+ > * Vcs : https://salsa.debian.org/emacsen-team/kotlin-mode >Section : lisp > I'd be happy to sponsor this one! Thank you for your work, and yes, I agree that this should be part of Debian. Here are a couple of points that need to be worked on, one nitpick, and one enhancement. Copyright either isn't accurate or is missing a citation (or copy of email as proof of the asserted copyright). Using a tool like silversearch-ag (or similar) and searching for "copyright", "©", or '\(c\)' will reveal the inconsistency. Please list documented copyright holders with documented copyright years, or provide proof for what is currently asserted. Short description needs to mention Emacs. Nitpick: first letter should not be capitalised. Long description: this was copy and pasted and needs to be rewritten for a Debian context. Nitpick: Section: lisp is acceptable, but lintian is making an overclaim when it complains about this. Noninteractive libraries are definitely section: lisp, but this package is used to interactively edit Kotlin files so should be Section: editors. Rules: We use dh-elpa and not Cask, and Cask doesn't integrate with Debhelper, so the comment is misleading. Overridden targets can empty, and there is no need for those colons. If you'd like to make build log output nicer, here's a neat trick for the body of override_dh_auto_build: @echo Ignoring upstream Makefile and building/installing with dh-elpa. I'll take a more in-depth look tomorrow (eg: I didn't check to see if it FTBFS or if autopkgtests function). Cheers, Nicholas signature.asc Description: PGP signature
Bug#1003860: RFS: makemkv-oss/1.16.5-1 [ITP] -- Convert video that you own into free format that can be played everywhere
Hi Ben! On Sun, 2022-01-16 at 20:51 -0500, Ben Westover wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my packages "makemkv-oss" and > "makemkv-bin" (they depend on each other): It's great that you're working on the packaging of MakeMKV. A couple quick comments: It looks like you're basing your packaging work off of the packages I've created and made available; that's wonderful, and I'm glad they were a good starting point. However, I think it would be appropriate (at a minimum) to provide credit in d/copyright. The d/rules file I created for the makemkv-bin package is quite hacky, and work should probably be done to get that into nicer shape if the package is going to be included in the archive. The makemkv-oss package has a lot of vendored libraries. I've tried in the past to remove them, and found that some (like libmatroska) are sufficiently different from the versions in bullseye that they cannot be easily replaced with system libraries. (For instance, see this thread where the libmatroska issue was found: https://forum.makemkv.com/forum/viewtopic.php?p=111826) I foresee this as the largest hurdle to actually getting packages accepted into Debian. Is there a particular reason why you're using debhelper-compat version 12, rather than 13? Mathias signature.asc Description: This is a digitally signed message part
Bug#1003860: RFS: makemkv-oss/1.16.5-1 [ITP] -- Convert video that you own into free format that can be played everywhere
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my packages "makemkv-oss" and "makemkv-bin" (they depend on each other): * Package name: makemkv-oss Version : 1.16.5-1 * URL : https://makemkv.com/ * License : GPL-2, GPL-3, LGPL-2.1, OpenSSL, X, custom * Vcs : https://salsa.debian.org/benthetechguy/makemkv/tree/master/makemkv-oss Section : non-free/video makemkv-oss builds those binary packages: makemkv - Convert video that you own into free format that can be played everywhere libdriveio0 - MMC drive interrogation library libmakemkv1 - MKV multiplexer library libmmbd0 - MakeMKV BD decryption API library * Package name: makemkv-bin Version : 1.16.5-1 * URL : https://makemkv.com/ * License : GPL-2, GPL-3, custom * Vcs : https://salsa.debian.org/benthetechguy/makemkv/tree/master/makemkv-bin Section : non-free/video makemkv-bin builds those binary packages: makemkvcon - Proprietary components of makemkv To access further information about these packages, please visit the following URLs: https://mentors.debian.net/package/makemkv-oss/ https://mentors.debian.net/package/makemkv-bin/ Alternatively, one can download the packages with dget using these commands: dget -x https://mentors.debian.net/debian/pool/non-free/m/makemkv-oss/makemkv-oss_1.16.5-1.dsc dget -x https://mentors.debian.net/debian/pool/non-free/m/makemkv-bin/makemkv-bin_1.16.5-1.dsc Changes for the initial release: makemkv-oss (1.16.5-1) unstable; urgency=medium . * Initial Package. * Closes: #1003815 Regards, -- Ben Westover OpenPGP_0xC311C5F54E89B698.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#1003855: RFS: kotlin-mode/20210917git0-1 [RFP] -- Major mode for kotlin
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "kotlin-mode": * Package name: kotlin-mode Version : 20210917git0-1 Upstream Author : Emacs Kotlin Mode Maintainers * URL : https://github.com/Emacs-Kotlin-Mode-Maintainers/kotlin-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/kotlin-mode Section : lisp It builds those binary packages: elpa-kotlin-mode - Major mode for kotlin To access further information about this package, please visit the following URL: https://mentors.debian.net/package/kotlin-mode/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/k/kotlin-mode/kotlin-mode_20210917git0-1.dsc Changes for the initial release: kotlin-mode (20210917git0-1) unstable; urgency=medium . * Initial release. (Closes: #922934) Regards, -- Joshua Peisach
Bug#1003853: RFS: sofia-sip/1.12.11+20110422.1-2.2 [NMU] [RC] -- Sofia SIP library
Hi, I forgot: If I understand the [Policy] correctly, this should be a DELAYED/0, right? [Policy] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu On Sun, 2022-01-16 at 23:43 +0100, Evangelos Ribeiro Tzaras wrote: > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "sofia-sip": > > * Package name : sofia-sip > Version : 1.12.11+20110422.1-2.2 > Upstream Author : Pekka Pessi, Martti Mela, Kai Vehmanen > * URL : http://sofia-sip.sourceforge.net/ > * License : LGPL-2.1 > * Vcs : > http://git.debian.org/?p=users/ron/sofia-sip.git;a=summary > Section : net > > It builds those binary packages: > > sofia-sip-bin - Sofia-SIP library utilities > libsofia-sip-ua0 - Sofia-SIP library runtime > libsofia-sip-ua-dev - Sofia-SIP library development files > libsofia-sip-ua-glib3 - Sofia-SIP library glib/gobject interfaces > runtime > libsofia-sip-ua-glib-dev - Sofia-SIP library glib/gobject interface > development files > sofia-sip-doc - Sofia-SIP library documentation > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/sofia-sip/ > > Alternatively, one can download the package with dget using this > command: > > dget -x > https://mentors.debian.net/debian/pool/main/s/sofia-sip/sofia-sip_1.12.11+20110422.1-2.2.dsc > > I have uploaded the package on salsa under > https://salsa.debian.org/devrtz/sofia-sip/-/tree/minimal-nmu > Judging by debdiff (as mentioned in #965829) there is basically only > some > changes in the -doc package which I believe are due to a newer > doxygen being used. > > I've also tested with one rdep (gnome-calls of which I'm the > maintainer) that > it still builds and runs fine. > > Changes since the last upload: > > sofia-sip (1.12.11+20110422.1-2.2) unstable; urgency=medium > . > * Non-maintainer upload. > * Bump dh-compat to 13 (Closes: #965829) > > Regards,
Bug#1003854: RFS: qtractor/0.9.25-1 -- MIDI/Audio multi-track sequencer application
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "qtractor": * Package name : qtractor Version : 0.9.25-1 Upstream Author : Rui Nuno Capela * URL : https://qtractor.sourceforge.io/ * License : GPL-2+, FSFAP, other * Vcs : https://salsa.debian.org/multimedia-team/qtractor Section : sound It builds those binary packages: qtractor - MIDI/Audio multi-track sequencer application To access further information about this package, please visit the following URL: https://mentors.debian.net/package/qtractor/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/q/qtractor/qtractor_0.9.25-1.dsc Changes since the last upload: qtractor (0.9.25-1) unstable; urgency=medium . * New upstream version 0.9.25 * d/control: Update and sort B-Ds * Update d/copyright years * d/copyright: Appdata file has been renamed * d/docs: Remove nonexisting TODO * Remove obsolete hardening patch * Clean d/rules Regards, Dennis OpenPGP_signature Description: OpenPGP digital signature
Bug#1003853: RFS: sofia-sip/1.12.11+20110422.1-2.2 [NMU] [RC] -- Sofia SIP library
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "sofia-sip": * Package name: sofia-sip Version : 1.12.11+20110422.1-2.2 Upstream Author : Pekka Pessi, Martti Mela, Kai Vehmanen * URL : http://sofia-sip.sourceforge.net/ * License : LGPL-2.1 * Vcs : http://git.debian.org/?p=users/ron/sofia-sip.git;a=summary Section : net It builds those binary packages: sofia-sip-bin - Sofia-SIP library utilities libsofia-sip-ua0 - Sofia-SIP library runtime libsofia-sip-ua-dev - Sofia-SIP library development files libsofia-sip-ua-glib3 - Sofia-SIP library glib/gobject interfaces runtime libsofia-sip-ua-glib-dev - Sofia-SIP library glib/gobject interface development files sofia-sip-doc - Sofia-SIP library documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sofia-sip/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sofia-sip/sofia-sip_1.12.11+20110422.1-2.2.dsc I have uploaded the package on salsa under https://salsa.debian.org/devrtz/sofia-sip/-/tree/minimal-nmu Judging by debdiff (as mentioned in #965829) there is basically only some changes in the -doc package which I believe are due to a newer doxygen being used. I've also tested with one rdep (gnome-calls of which I'm the maintainer) that it still builds and runs fine. Changes since the last upload: sofia-sip (1.12.11+20110422.1-2.2) unstable; urgency=medium . * Non-maintainer upload. * Bump dh-compat to 13 (Closes: #965829) Regards, -- Evangelos Ribeiro Tzaras
Bug#1003843: marked as done (RFS: scummvm/2.5.1-0.1 [NMU] -- engine for several graphical adventure games)
Your message dated Sun, 16 Jan 2022 23:20:12 +0100 with message-id <20220116232012.2c6c3...@heffalump.sk2.org> and subject line Re: Bug#1003843: RFS: scummvm/2.5.1-0.1 [NMU] -- engine for several graphical adventure games has caused the Debian Bug report #1003843, regarding RFS: scummvm/2.5.1-0.1 [NMU] -- engine for several graphical adventure games to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1003843: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003843 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scummvm": * Package name: scummvm Version : 2.5.1-0.1 * URL : http://www.scummvm.org * License : GPL-2+ and BSD-3-clause-UCB, GPL-3+, GPL-1+, LGPL-2.1+, MIT-Adobe-DEC, Expat, any-purpose-note, Boost-1.0, public-domain, GPL-2+ and Expat, MIT-like, public-domain-crc, GPL-2+, GPL-2, unlimited, zlib/libpng and GPL-2+, BSD-3-clause-Hildenborg * Vcs : https://salsa.debian.org/games-team/scummvm Section : games It builds those binary packages: scummvm - engine for several graphical adventure games scummvm-data - engine for several graphical adventure games (data files) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scummvm/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scummvm/scummvm_2.5.1-0.1.dsc Changes since the last upload: scummvm (2.5.1-0.1) unstable; urgency=low . * Non-maintainer upload. * New upstream release. Regards, -- Matteo Bini --- End Message --- --- Begin Message --- Hi Matteo, On Sun, 16 Jan 2022 19:37:38 +, Matteo Bini wrote: > I am looking for a sponsor for my package "scummvm": Thanks for taking care of this, uploaded! I’ll push the change to the repository tomorrow. Regards, Stephen pgpz1mhXr13qT.pgp Description: OpenPGP digital signature --- End Message ---
Bug#1003850: RFS: budgie-control-center/0.2-1 [ITP] -- utilities to configure the Budgie desktop
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "budgie-control-center": * Package name: budgie-control-center Version : 0.2-1 Upstream Author : Budgie Desktop Developers * URL : https://github.com/buddiesofbudgie/budgie-control-center * License : GPL-2+ and LGPL-2.1+ and LGPL-2+ and Expat * Vcs : https://github.com/ubuntubudgie/budgie-control-center Section : misc It builds those binary packages: budgie-control-center - utilities to configure the Budgie desktop budgie-control-center-dev - Development package for Budgie Settings budgie-control-center-data - configuration applets for Budgie - data files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-control-center/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-control-center/budgie-control-center_0.2-1.dsc Background: I am the DM for the budgie desktop and related packages in Debian and part of the upstream development team. As part of the next version of budgie-desktop we have replaced our dependency of gnome-control-center with our own budgie-control-center. This package is focused on budgie whereas the current gnome-control-center is focussed on gnome-shell. This package is a fork of gnome-control-center at v41. The Debian package itself is derived from Debian's gnome-control-center. The copyright file & its authors is the same as the current gnome-control-center package with the addition of our own authorship. I have taken the opportunity to resolve some of the information and pedantic issues founds in the current gnome-control-center package. In terms of testing we have ensured that budgie-control-center can coexist with gnome-control-center i.e. this allows users to use both gnome-shell and budgie-desktop on the same installed machine. I would like to continue providing the best experience of budgie-desktop for Debian and this package is part of this continued commitment. Please can you consider sponsoring this package - obviously in the future I would like to ensure that I can continue providing timely uploads through supplementing my current DM package rights with this new package. Changes for the initial release: budgie-control-center (0.2-1) unstable; urgency=medium . * Initial Release (Closes: #1003845) Regards, -- David Mohammed
Re: The purpose of marking a package Multi-Arch: foreign
On 2022-01-16 12:56 -0500, Tong Sun wrote:
> On Fri, Jan 14, 2022 at 4:42 PM Tong Sun wrote:
>
> I have a question regarding marking
> golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign
> what's the purpose of it?
>
> I did find an explanation from https://wiki.debian.org/Multiarch/HOWTO:
>
> > If a package is marked 'Multi-Arch: foreign', then it can satisfy
> > dependencies of a package of a different architecture (e.g
> > 'debhelper:amd64' will satisfy a dependency on debhelper for
> > any-architecture package).
>
> Yet, I'm unable to digest that -- e.g., why an arm64 architecture
> needs dependencies of a package from amd64?
I find it helpful to think of packages as 'tools' or
'libraries'. Tools are those packages marked MA:foreign, and their use
is architecture-independent. e.g. 'doxygen' or 'ps2pdf' does the same
thing whatever arch you run them on - they spit out some
documentation. If when cross-building for arm64 (on amd64) the build
asks for 'ps2pdf' to process a file, it's fine if that dependency is
fulfilled by the amd64 ('foreign arch') version. For things like
libraries the build-dependency can only be satisfied by a
matching-arch (arm64 in this case) package, because library linking
only works between libraries of the same architecture.
The point being than when cross-building on amd64 you cannot run most
other architecture tools. Only amd64 (and i386) will actually work, so
it is usless to satisfy a build-dependency for something that will
actually get run ('tools') with an arm64 arch package.
Does that help?
>
> I guess I don't understand the concept and implication of Debian's
> cross built, as I see that easygen is being cross built without
> 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev
> is not, despite having the 'Multi-Arch: foreign' .
>
> https://buildd.debian.org/status/package.php?p=easygen vs.
> https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser
This is not cross-building. This is native building. Cross-building is
building one package on a machine of another architecture.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Re: The purpose of marking a package Multi-Arch: foreign
On Sun, Jan 16, 2022 at 12:56:38PM -0500, Tong Sun wrote: > I guess I don't understand the concept and implication of Debian's > cross built, as I see that easygen is being cross built without > 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev > is not, despite having the 'Multi-Arch: foreign' . Reading your words, I think your first step should be to look up the concept of "cross builds" and what that means and implies (as opposed to what you normally use and know, that are "native builds"), as I don't think you understand what that is. I don't think trying to understand the concept of cross-satisfable dependencies and the limitation imposed by the model used by dpkg (and as such why the Multi-Arch field is needed at all) is useful before that. > https://buildd.debian.org/status/package.php?p=easygen vs. > https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser These are not cross builds: buildd.d.o only does native builds. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. More about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#1003090: RFS: ffcvt/1.7.5-1
Hi Tong, On 1/16/22 10:41 PM, Tong Sun wrote: I'll remove the build dependency of easygen as planned, as I know for sure it can fix the issue I am not sure if that's the problem here. Why would it fix the issue? [...] config.go:1:1: expected 'package', found 'EOF' which is in turn caused by https://salsa.debian.org/go-team/packages/ffcvt/-/blob/master/debian/rules#L20 that rm -f ... config.go statement. I know removing the build dependency of easygen will work because I don't need to do `rm -f ... config.go` after that. Apparently not. I tried doing these changes on a different branch[1], but as you might see, the CI is still failing[2], unless I did that wrong. So it is likely unrelated. I think the the config.go that you see there is _probably_ this one[3] instead of the one in package, because this thing is being 'run'. I took this even further I triggered salsa CI on a branched-off commit from _last uploaded version_ of ffcvt see here[4] and that still fails, while that has nothing to do with easygen at all. The CI is trying to build all golang packages, install your current package and trying to test if something failed after installing current package. Since ffcvt has no reverse-deps and no deps either, it looks highly unlikely for it to break anything at all. It seems a problem with the CI instead here. I do think we can ignore CI failures here. (I'll remove these useless branches before uploading the new release.) [1]: https://salsa.debian.org/go-team/packages/ffcvt/-/commits/salsa-ci [2]: https://salsa.debian.org/go-team/packages/ffcvt/-/jobs/2372473 [3]: https://salsa.debian.org/go-team/infra/pkg-go-tools/-/blob/master/config/config.go [4]: https://salsa.debian.org/go-team/packages/ffcvt/-/commits/salsa-ci-test Everything builds fine locally, even with sbuild -- https://paste.debian.net/1227301/ That's why I don't understand why it fails in salsa CI, even after I've done a brand new push to salsa -- https://salsa.debian.org/go-team/packages/ffcvt/-/jobs/2372315 Yep. I faced a failure on another package of mine today that does nothing intrusive at all[5] and it goes fine on buildd[6] so IMO we ignore this for now. CI doesn't work perfect for all packages (which is fine too) [5]: https://salsa.debian.org/go-team/packages/golang-github-biogo-graph/-/jobs/2371800 [6]: https://buildd.debian.org/status/fetch.php?pkg=golang-github-biogo-graph=all=0.0%7Egit20150317.057c198-3=1642331568=0 @Alois, could you shed some light on the CI thingy? From the logs, it is hard to figure out what went wrong. The packages that are shown failing there do not have anything to do with ffcvt package, are the failing logs stored somewhere? > Yes please @Alois. CC'ed Faust as well. @Faustin, would you have some idea? Hope that helps. Let me know if you need sponsoring. Please do when all dust settles. I want to do this now, but I'll wait for a couple of days for replies/opinions. Yes, indeed Nilesh, as I'm not allowed to do dput myself yet. Have you sorted out your gpg key stuff? If yes, you should be able to upload after this month's keyring changes (hopefully next week) Regards, Nilesh OpenPGP_signature Description: OpenPGP digital signature
Re: The purpose of marking a package Multi-Arch: foreign
On Sun, Jan 16, 2022 at 12:56 PM Tong Sun wrote: > > On Fri, Jan 14, 2022 at 4:42 PM Tong Sun wrote: > > > > On Thu, Jan 13, 2022 at 4:09 PM Debian Bug Tracking System > > wrote: > > > > > > Your message dated Thu, 13 Jan 2022 21:07:44 + > > > with message-id > > > and subject line Bug#980990: fixed in > > > golang-github-danverbraganza-varcaser 0.0~git20190207.e3fb03e-2 > > > has caused the Debian Bug report #980990, > > > regarding mark golang-github-danverbraganza-varcaser-dev Multi-Arch: > > > foreign > > > to be marked as done. > > > > > > This means that you claim that the problem has been dealt with. > > > If this is not the case it is now your responsibility to reopen the > > > Bug report if necessary, and/or fix the problem forthwith. > > > > Hi Helmut, > > > > Sorry for replying late, but it finally got fixed now. > > > > One thing I don't understand about marking a package Multi-Arch: > > foreign -- what would the impact be, e.g., would I be seeing anything > > different in its build, > > https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser, > > etc? > > > > Can you explain a bit please? thx! > > Hi, > > I have a question regarding marking > golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign > what's the purpose of it? > > I did find an explanation from https://wiki.debian.org/Multiarch/HOWTO: > > > If a package is marked 'Multi-Arch: foreign', then it can satisfy > > dependencies of a package of a different architecture (e.g > > 'debhelper:amd64' will satisfy a dependency on debhelper for > > any-architecture package). > > Yet, I'm unable to digest that -- e.g., why an amd64 architecture > needs dependencies of a package from amd64? Sorry I meant, e.g., why an amd64 architecture needs dependencies of a package from arm64? > Helmut's explanation was: > > > easygen cannot be cross built from source, because its dependency on > golang-github-danverbraganza-varcaser-dev is not satisfiable. > In general, Architecture: all packages can never satisfy cross > Build-Depends unless marked Multi-Arch: foreign or annotated :native. > > I guess I don't understand the concept and implication of Debian's > cross built, as I see that easygen is being cross built without > 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev > is not, despite having the 'Multi-Arch: foreign' . > > https://buildd.debian.org/status/package.php?p=easygen vs. > https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser > > Please help.
The purpose of marking a package Multi-Arch: foreign
On Fri, Jan 14, 2022 at 4:42 PM Tong Sun wrote: > > On Thu, Jan 13, 2022 at 4:09 PM Debian Bug Tracking System > wrote: > > > > Your message dated Thu, 13 Jan 2022 21:07:44 + > > with message-id > > and subject line Bug#980990: fixed in golang-github-danverbraganza-varcaser > > 0.0~git20190207.e3fb03e-2 > > has caused the Debian Bug report #980990, > > regarding mark golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign > > to be marked as done. > > > > This means that you claim that the problem has been dealt with. > > If this is not the case it is now your responsibility to reopen the > > Bug report if necessary, and/or fix the problem forthwith. > > Hi Helmut, > > Sorry for replying late, but it finally got fixed now. > > One thing I don't understand about marking a package Multi-Arch: > foreign -- what would the impact be, e.g., would I be seeing anything > different in its build, > https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser, > etc? > > Can you explain a bit please? thx! Hi, I have a question regarding marking golang-github-danverbraganza-varcaser-dev Multi-Arch: foreign what's the purpose of it? I did find an explanation from https://wiki.debian.org/Multiarch/HOWTO: > If a package is marked 'Multi-Arch: foreign', then it can satisfy > dependencies of a package of a different architecture (e.g 'debhelper:amd64' > will satisfy a dependency on debhelper for any-architecture package). Yet, I'm unable to digest that -- e.g., why an amd64 architecture needs dependencies of a package from amd64? Helmut's explanation was: > easygen cannot be cross built from source, because its dependency on golang-github-danverbraganza-varcaser-dev is not satisfiable. In general, Architecture: all packages can never satisfy cross Build-Depends unless marked Multi-Arch: foreign or annotated :native. I guess I don't understand the concept and implication of Debian's cross built, as I see that easygen is being cross built without 'Multi-Arch: foreign', yet golang-github-danverbraganza-varcaser-dev is not, despite having the 'Multi-Arch: foreign' . https://buildd.debian.org/status/package.php?p=easygen vs. https://buildd.debian.org/status/package.php?p=golang-github-danverbraganza-varcaser Please help.
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-16 Thomas Dickey wrote: [...] > I reviewed the test-data differences, didn't see a problem, and verified > with cproto (which uses lex/yacc) that there are no differences. > So I updated the debian files to combine the two (just packaging one > "byacc" with backtracking). Great. [...] > For now, I'm just working on the Debian package of the current release :-) I will probably followup with further wishes/comments later, not today but hopefully in next week. cu Andreas
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 05:34:42PM +0100, Andreas Metzler wrote: > On 2022-01-16 Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > [...] > > > > I would like to question the introduction of another binary package: > > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > > "byacc2" only finds links related to this RFS. > > > Ultimately that's because Debian's the only place where the older "btyacc" > > is packaged. > > [...] > > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > > compatible extension of /usr/bin/byacc the only difference being > > > that it additionally supports > > > | -B create a backtracking parser > > > I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > [...] > > ...with these caveats: > > > a) because of the backtracking support, the skeletons differ. > > > b) backtracking can be slow > > > However, Mageia and OpenSUSE provide packages for byacc with backtracking > > enabled. > [...] > > Hello Thomas, > > afaict from > https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec > Fedora also builds without backtracking: > | # Revert default stack size back to 1 > | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 > | find . -type f -name \*.c -print0 | > | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g' > | > | %build > | %configure --disable-dependency-tracking my configure script doesn't use that option. I see it in the initial 2007 commit on Fedora, but it's not been part of any version that I've provided. (it looks like old copy/paste from somewhere). Since the Fedora package is reasonably up-to-date (last August), I didn't get involved with that (yet). > | %make_build > > I would think that is something you need to solve upstream. It cannot be > a good thing(TM) if the same version of byacc is incompatible between > different major distributions. Don't you agree? yes... but the reminder was useful > With "solve" meaning, that you decide whether you intend to provide a > limited-feature-set binary forever, and starting from there decide on > the naming of old (if it shall exist) and new byacc. I reviewed the test-data differences, didn't see a problem, and verified with cproto (which uses lex/yacc) that there are no differences. So I updated the debian files to combine the two (just packaging one "byacc" with backtracking). I'll probably change the default in the upstream configure script to turn on backtracking, so that the packagers who didn't sign onto backtracking will get it by default. Fedora, for instance. But that's another byacc-update away. I see in my to-do list that I have some documentation issues, as well as improving leak-checking (and the usual wishlist...), but nothing that requires a new release. For now, I'm just working on the Debian package of the current release :-) -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003090: RFS: ffcvt/1.7.5-1
On Sat, Jan 15, 2022 at 3:21 AM Nilesh Patra wrote:
>
> Hi Tong,
>
> On 1/15/22 2:55 AM, Tong Sun wrote:
> >> Hi,
> >>
> >> The situation should have been fixed with the new upload of easygen.
> >>
> >> However, the CI build is still failing in salsa. This is something
> >> that I don't understand as it builds OK on github.
> >>
> >> Sorry I've run out of ideas why it is happening like this, and am now
> >> thinking to remove the build dependency of easygen, to fix this and to
> >> make things easier...
> >
> > I still don't have a clue why
>
> I intended to reply earlier, but I was occupied and simply forgot later,
> sorry about that!
Oh, that's perfectly fine.
> > I'll wait for one or two weeks more, and if still nobody can help,
>
> It is usually a good idea to ask on #debian-mentors if there is more delay in
> a reply.
> Also, feel free to ping me if you think I can be of any help.
Oh, I only wrote that because I got total silence from my first
request. Now I know, that you'll still willing to help, just were busy
with something else. That promise alone, I'm forever grateful.
I'll keep it in mind but I won't ping anyone unless it's super urgent.
I normally give people a week, only after that I'll do a short follow
up, even at work, unless it's more urgent. Thanks again for helping.
> > it builds OK on github but fails in
> > salsa CI build, and I still hope that somebody can help.
>
> Okay, so there are two parts to it.
>
> 1) Why does github CI pass?
> Ok, so there are two reasons about this as well
> + test-all.sh does not seem to run anywhere in your github actions/CI and
> that error stems from this script (in the deb package)
> + `go test -v` in your CI essentially does nothing since there are no
> _test.go files and it is visible
> on the CI too
>
> | go test -v ./...
> | shell: /usr/bin/bash -e {0}
> | env:
> |GOROOT: /opt/hostedtoolcache/go/1.15.15/x64
> | github.com/suntong/ffcvt
> | ? github.com/suntong/ffcvt[no test files]
>
> So you probably should update it accordingly there as well.
Ah, good catch. fixed upstream. See
https://github.com/suntong/ffcvt/runs/4830553950?check_suite_focus=true
> 2) For salsa CI, I thought that it is because of the failing build.
> You will find the build failure logs pasted at the end of this email.
> The reason for test to be failing is that you have not updated
> "test/ffcvt_test.txt" file in accordance with the
> latest manpage/latest ffcvt options upstream.
>
> However, even after I have pushed a patch to fix the build, salsa CI chokes.
>
>
> > I'll remove the build dependency of easygen as planned, as I know for
> > sure it can fix the issue
> I am not sure if that's the problem here. Why would it fix the issue?
Ok, that does need a bit of explanation.
- ffcvt has the build dependency of easygen.
- the older version of easygen cause the initial v1.7.5 build failure
- which should be fixed by the updated easygen (from 4.1.0-1 to 5.1.9-2)
- that's why I triggered a rebuild (e673085)
- yet that rebuild still failed.
This is why I'm asking for help, as I don't understand why it still fails.
>From https://salsa.debian.org/go-team/packages/ffcvt/-/jobs/2342864#L719
the failure is caused by
config.go:1:1: expected 'package', found 'EOF'
which is in turn caused by
https://salsa.debian.org/go-team/packages/ffcvt/-/blob/master/debian/rules#L20
that
rm -f ... config.go
statement.
Everything builds fine locally, even with sbuild --
https://paste.debian.net/1227301/
That's why I don't understand why it fails in salsa CI, even after
I've done a brand new push to salsa --
https://salsa.debian.org/go-team/packages/ffcvt/-/jobs/2372315
I know removing the build dependency of easygen will work because I
don't need to do `rm -f ... config.go` after that.
> @Alois, could you shed some light on the CI thingy?
> From the logs, it is hard to figure out what went wrong.
> The packages that are shown failing there do not have anything to do with
> ffcvt package, are the failing logs stored somewhere?
Yes please @Alois.
> >> Somebody help please.
>
> Hope that helps. Let me know if you need sponsoring.
Yes, indeed Nilesh, as I'm not allowed to do dput myself yet. Please
do when all dust settles.
Thanks!
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On 2022-01-16 Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: [...] > > I would like to question the introduction of another binary package: > > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > > "byacc2" only finds links related to this RFS. > Ultimately that's because Debian's the only place where the older "btyacc" > is packaged. [...] > > Is /usr/bin/byacc2 incompatible with /usr/bin/byacc2? A quick glance > > at the yacc.1 seems to suggests that /usr/bin/byacc2 is a backward > > compatible extension of /usr/bin/byacc the only difference being > > that it additionally supports > > | -B create a backtracking parser > I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. [...] > ...with these caveats: > a) because of the backtracking support, the skeletons differ. > b) backtracking can be slow > However, Mageia and OpenSUSE provide packages for byacc with backtracking > enabled. [...] Hello Thomas, afaict from https://src.fedoraproject.org/rpms/byacc/blob/rawhide/f/byacc.spec Fedora also builds without backtracking: | # Revert default stack size back to 1 | # https://bugzilla.redhat.com/show_bug.cgi?id=743343 | find . -type f -name \*.c -print0 | | xargs -0 sed -i 's/YYSTACKSIZE 500/YYSTACKSIZE 1/g' | | %build | %configure --disable-dependency-tracking | %make_build I would think that is something you need to solve upstream. It cannot be a good thing(TM) if the same version of byacc is incompatible between different major distributions. Don't you agree? With "solve" meaning, that you decide whether you intend to provide a limited-feature-set binary forever, and starting from there decide on the naming of old (if it shall exist) and new byacc. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 08:07:42AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > ... > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > I thought it would be the safest approach. I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > > fwiw, the reference files in test/*yacc show that backtracking doesn't > simply _add_ definitions: > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > (presumably reviewing those deletions would tell me whether two binaries > are still needed). reviewing one of those (e.g., a "calc" test-case which doesn't rely upon the backtracking features, and looking at the ".c" file), it seems to be properly ifdef'd so that the extra text is activated when the -B option is supported/used. There are a few spots where the code is reorganized to integrate the two flavors. There's one functional difference: The debugging output in the btyacc flavor goes to stderr, while the byacc flavor goes to stdout. (The manual page doesn't mention this - nor does it mention that -h goes to stderr) -- added a to-do... -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 02:39:04PM +0100, ابو الغيث عليّ wrote: > Hello Thomas, > > What is the difference between Yacc and Lex GNU tools. > And Byacc or Bison?! bison has a lot of non-yacc extensions. I don't believe any third-party has made a list of differences. Consider this like the difference between pmake and "gmake". > Berkeley still a source of truthful tools and clean mainstream. "Berkeley" is long out of the picture. The various BSDs package both byacc and bison. I see byacc here: MacOS base has this, which isn't the original byacc 1.9, but rather a copy of what was in NetBSD: https://opensource.apple.com/tarballs/yacc/ but ports have this byacc: https://github.com/macports/macports-ports/blob/master/devel/byacc/Portfile https://formulae.brew.sh/formula/byacc (fwiw, Apple rarely updates tools such as this except as required for POSIX certification). FreeBSD has this byacc both in base and ports: https://svnweb.freebsd.org/base/head/usr.bin/yacc/ https://svnweb.freebsd.org/ports/head/devel/byacc/ NetBSD has retired their copy of byacc 1.9 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/yacc/?only_with_tag=MAIN in favor of this byacc: https://pkgsrc.se/devel/byacc OpenBSD has only byacc 1.9 copied from NetBSD, with minor changes: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/yacc/ (fwiw, OpenBSD's ports are a subset of pkgsrc, e.g., 9453 vs 18329). There's also DragonFly (also using this byacc): https://gitweb.dragonflybsd.org/dragonfly.git/blob/HEAD:/usr.bin/yacc/Makefile https://gitweb.dragonflybsd.org/dragonfly.git/tree/HEAD:/contrib/byacc > Do it keep byacc and blex. there's a similar story for lex, but I think that's off-topic. > Kind regards, > > > > > > > > > On Sun, 16 Jan 2022 at 14:09 Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > > ... > > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > > > I thought it would be the safest approach. I've made some effort to keep > > > the two compatible, but sooner or later will get some bug report related > > > to their differences. Debian's the usual place for that sort of thing. > > > > fwiw, the reference files in test/*yacc show that backtracking doesn't > > simply _add_ definitions: > > > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > > > (presumably reviewing those deletions would tell me whether two binaries > > are still needed). > > > > -- > > Thomas E. Dickey > > https://invisible-island.net > > ftp://ftp.invisible-island.net > > -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
Hello Thomas, What is the difference between Yacc and Lex GNU tools. And Byacc or Bison?! Berkeley still a source of truthful tools and clean mainstream. Do it keep byacc and blex. Kind regards, On Sun, 16 Jan 2022 at 14:09 Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > ... > > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > > > I thought it would be the safest approach. I've made some effort to keep > > the two compatible, but sooner or later will get some bug report related > > to their differences. Debian's the usual place for that sort of thing. > > fwiw, the reference files in test/*yacc show that backtracking doesn't > simply _add_ definitions: > > 155 files changed, 53852 insertions(+), 1785 deletions(-) > > (presumably reviewing those deletions would tell me whether two binaries > are still needed). > > -- > Thomas E. Dickey > https://invisible-island.net > ftp://ftp.invisible-island.net >
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 07:58:07AM -0500, Thomas Dickey wrote: > On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: ... > > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 > > I thought it would be the safest approach. I've made some effort to keep > the two compatible, but sooner or later will get some bug report related > to their differences. Debian's the usual place for that sort of thing. fwiw, the reference files in test/*yacc show that backtracking doesn't simply _add_ definitions: 155 files changed, 53852 insertions(+), 1785 deletions(-) (presumably reviewing those deletions would tell me whether two binaries are still needed). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Bug#1003769: RFS: byacc/1.0-2 [ITA] -- public domain Berkeley LALR Yacc parser generator
On Sun, Jan 16, 2022 at 08:03:14AM +0100, Andreas Metzler wrote: > On 2022-01-15 Thomas Dickey wrote: > [...] > > I am looking for a sponsor for my package "byacc": > > > * Package name: byacc > >Version : 1:2.0.20220114-1 > >Upstream Author : (Thomas E. Dickey) > > * URL : https://invisible-island.net/byacc/ > > * License : GPL-3, public-domain, other-BSD > > * Vcs : https://salsa.debian.org/debian/byacc > >Section : devel > > > It builds those binary packages: > > > byacc - public domain Berkeley LALR Yacc parser generator > > byacc2 - public domain Berkeley LALR Yacc parser generator, with > > back-tracking > [...] > > Hello Thomas, > > I would like to question the introduction of another binary package: > * "byacc2" seems to be a (newly introduced) Debiansm. Googling for > "byacc2" only finds links related to this RFS. Ultimately that's because Debian's the only place where the older "btyacc" is packaged. > * The packages are tiny (about 100k) and have no conflicting files. > /usr/bin/byacc2 and /usr/bin/byacc could be shipped in on binary > package. yes, I could do that. I don't believe that would interfere with using the alternatives mechanism for selecting "yacc". I made them separate because I thought that would be the expected way. > * Is the double compilation/binary necessary? - Is /usr/bin/byacc2 I thought it would be the safest approach. I've made some effort to keep the two compatible, but sooner or later will get some bug report related to their differences. Debian's the usual place for that sort of thing. > incompatible with /usr/bin/byacc2? A quick glance at the yacc.1 seems > to suggests that /usr/bin/byacc2 is a backward compatible extension of > /usr/bin/byacc the only difference being that it additionally supports > | -B create a backtracking parser ...with these caveats: a) because of the backtracking support, the skeletons differ. b) backtracking can be slow However, Mageia and OpenSUSE provide packages for byacc with backtracking enabled. (I should make a list of the other packages, but the rpm's are easy to check at the moment). -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
