Re: Help required: riseup-vpn
On Sat, May 04, 2024 at 04:01:12PM +0100, Jeremy Sowden wrote: > > I am also puzzled with different paths for the same binaries across qt > > versions for instance qmlcachegen is: > > > > qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen > > qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen > > > > Why is that? > > Presumably so one can co-install the dev tools for multiple releases > of QT. Why not use /usr/lib/qt6/bin/qmlcachegen and /usr/lib/qt5/bin/qmlcachegen then? The names of binary packages are also inconsistent and I am not sure if there;s a good reason for that? > > In any case, I am not sure how to proceed from here (the error with > > lrelease). Can anyone help out, please? My changes are available in > > salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn > > > > I'd appreciate any pointers. > > You can tell the GUI build script to use the qt6 lrelease and qmake > binaries: Yep, I came up with a similar patch eventually :) Best, Nilesh signature.asc Description: PGP signature
Re: Help required: riseup-vpn
On Sat, May 04, 2024 at 05:56:18PM +0530, Nilesh Patra wrote: > Hi all, > > I am trying to update riseup-vpn to its latest version. I am seeing some > confused mix of qt5 and qt6 - not really sure how qt updates for applications > work. I tried to replace qt5 packages (builddeps) with its qt6 equivalents > but I > end up with: > > | ==BUILD GUI=== > | TARGET: bitmask-vpn > | VENDOR_PATH: providers > | [build.sh] VENDOR_PATH = providers > | [+] Building BitmaskVPN > | lrelease: could not find a Qt installation of '' > | make[2]: *** [Makefile:151: build_gui] Error 1 > | make[2]: Leaving directory > '/<>/_build/src/0xacab.org/leap/bitmask-vpn' > > I was getting a different error with qt5: > > | /usr/lib/qt5/bin/qmlcachegen > --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc > -o release/gui_main_qml.cpp ../../gui/main.qml > | Error compiling qml file: ../../gui/main.qml:0: error: Library import > requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > | ../../gui/main.qml:0: error: Library import requires a version > > But given that the readme says to use qt6, I should not be using qt5 here. The > versions from the qml file have been omitted in this release. > > I am also puzzled with different paths for the same binaries across qt > versions > for instance qmlcachegen is: > > qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen > qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen > > Why is that? > > In any case, I am not sure how to proceed from here (the error with > lrelease). Can anyone help out, please? > My changes are available in salsa at: > https://salsa.debian.org/go-team/packages/riseup-vpn I could get it working with: cd $(BUILDDIR) && $(MAKE) build VERSION=$(VERSION) LRELEASE=/usr/lib/qt6/bin/lrelease QMAKE=/usr/bin/qmake6 PROVIDER=riseup TARGET=riseup-vpn in d/rules. Seems lrelease from qtchooser does not work properly for qt6? Best, Nilesh signature.asc Description: PGP signature
Help required: riseup-vpn
Hi all, I am trying to update riseup-vpn to its latest version. I am seeing some confused mix of qt5 and qt6 - not really sure how qt updates for applications work. I tried to replace qt5 packages (builddeps) with its qt6 equivalents but I end up with: | ==BUILD GUI=== | TARGET: bitmask-vpn | VENDOR_PATH: providers | [build.sh] VENDOR_PATH = providers | [+] Building BitmaskVPN | lrelease: could not find a Qt installation of '' | make[2]: *** [Makefile:151: build_gui] Error 1 | make[2]: Leaving directory '/<>/_build/src/0xacab.org/leap/bitmask-vpn' I was getting a different error with qt5: | /usr/lib/qt5/bin/qmlcachegen --resource=/tmp/riseup-vpn_/_build/src/0xacab.org/leap/bitmask-vpn/gui/gui.qrc -o release/gui_main_qml.cpp ../../gui/main.qml | Error compiling qml file: ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version | ../../gui/main.qml:0: error: Library import requires a version But given that the readme says to use qt6, I should not be using qt5 here. The versions from the qml file have been omitted in this release. I am also puzzled with different paths for the same binaries across qt versions for instance qmlcachegen is: qt6-declarative-dev-tools: /usr/lib/qt6/libexec/qmlcachegen qtdeclarative5-dev-tools: /usr/lib/qt5/bin/qmlcachegen Why is that? In any case, I am not sure how to proceed from here (the error with lrelease). Can anyone help out, please? My changes are available in salsa at: https://salsa.debian.org/go-team/packages/riseup-vpn I'd appreciate any pointers. Best, Nilesh signature.asc Description: PGP signature
Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)
On Fri, Nov 17, 2023 at 06:18:04PM +0800, Maytham Alsudany wrote: > golang-github-go-logfmt-logfmt doesn't have this Handler type that's being > used, > and humanlog already uses go-logfmt as much as it can > > I've made an issue upstream at [3] regarding this and I've patched out the > Handler type completely from humanlog for now. > > Would you like me to close this RFS bug and the ITP? If this is needed for some actual functionality in humanlog, I will upload kr-logfmt which would otherwise block your work. From your mail, it is not clear to me whether or not it is needed. Please let me know. > [1]: https://bugs.debian.org/1055740 > [2]: > https://salsa.debian.org/go-team/packages/golang-github-humanlogio-humanlog/ > [3]: https://github.com/humanlogio/humanlog/issues/71 Best, Nilesh signature.asc Description: PGP signature
Bug#1055977: RFS: golang-github-kr-logfmt/0.0~git20210122.19f9bcb-1 [ITP] -- Parse logfmt messages (library)
On Wed, Nov 15, 2023 at 04:26:47PM +0800, Maytham Alsudany wrote: > Package: sponsorship-requests > Severity: wishlist > X-Debbugs-CC: debian...@lists.debian.org > > Dear mentors, > > I am looking for a sponsor for my package "golang-github-kr-logfmt": > > * Package name : golang-github-kr-logfmt >Version : 0.0~git20210122.19f9bcb-1 >Upstream contact : https://github.com/kr/logfmt/issues > * URL : https://github.com/kr/logfmt > * License : Expat > * Vcs : > https://salsa.debian.org/go-team/packages/golang-github-kr-logfmt >Section : golang This looks like _really_ old code, and there's golang-github-go-logfmt-logfmt in debian already. Can the code in the target package be patched to use go-logfmt or is it using specific features from kr-logfmt? Best, Nilesh signature.asc Description: PGP signature
Bug#1055975: RFS: golang-connectrpc-connect/1.12.0-1 [ITP] -- Go implementation of Connect
On Wed, Nov 15, 2023 at 03:57:11PM +0800, Maytham Alsudany wrote: > I am looking for a sponsor for my package "golang-connectrpc-connect": > > * Package name : golang-connectrpc-connect >Version : 1.12.0-1 >Upstream contact : https://github.com/connectrpc/connect-go/issues > * URL : https://github.com/connectrpc/connect-go > * License : Apache-2.0 > * Vcs : > https://salsa.debian.org/go-team/packages/golang-connectrpc-connect >Section : golang Uploaded to NEW with minor nitpicks. BTW, there is no real need to create a RFS bug if you want it to be under go team. Just sending a mail should suffice. PS: Are you subscribed to the debian-go team mailing list? Can I stop CC'ing you? Best, Nilesh signature.asc Description: PGP signature
Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
On Fri, Aug 25, 2023 at 06:29:34PM +0200, Niels Thykier wrote: > Nilesh Patra: > > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote: > > > [...] > > > > I had figured out this already, but conffile.lex.c does not exist in the > > project, it is generated as a part of the lexer output. In particular: > > > > Ok, apologies it was not clear to me from your opening email, where you were > stuck. I incorrectly assumed it was an an earlier stage than you are, so my > input was not useful to you. > > I checked the source of `conffile.l` and it need already has to runes to > include config.h where I would have assumed you needed to > (https://salsa.debian.org/med-team/eegdev/-/blob/master/src/core/conffile.l#L24). > > A bit of searching found the following flex upstream bug: > > * https://github.com/westes/flex/issues/564 > > Which seems related. Hopefully, it can help you. So, it was a lexer issue after all :) That did help, and I could fix the package. Thanks a lot! Best, Nilesh signature.asc Description: PGP signature
Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote: > Nilesh Patra: > > > > > > On 25 August 2023 1:47:26 pm IST, Nilesh Patra wrote: > > > On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum > > > wrote: > > > > Source: eegdev > > > > Version: 0.2-6 > > > > Severity: serious > > > > > In file included from conffile.lex.c:242: > > > > > ../../lib/stdio.h:64:3: error: #error "Please include config.h first." > > > > > 64 | #error "Please include config.h first." > > > > >| ^ > > > > > > The lexed file conffile.lex.c seems to include some stuff before > > > config.h is included which is causing it to choke. > > > > > > I'm not acquainted with lexers and not sure what causes this. I'd > > > appreciate any help. > > > > Adding mentors list as well. If someone can help with this, that'd be great. > I do not think the lexer has anything to do with this. > > A quick look at the log suggests that the package is "rolling" its own > "stdio.h" (note the "../../lib/stdio.h" in the error message). Indeed, the > full log has "mv stdio.h-t3 stdio.h" as well. > > I believe that this is stdio.h is generated by the embedded gnulib copy and > that is as far as I am willing to debug that rabbit hole. Based on the > error, I assume gnulib's generated stdio.h requires the project specific > "config.h" to be loaded first. > > As for solving it, I would have a look at the "conffile.lex.c" file, see > where it has its "#include" for stdio.h and then add an `include "config.h"` > before that to see if it works (via a patch). I had figured out this already, but conffile.lex.c does not exist in the project, it is generated as a part of the lexer output. In particular: $ ls conffile.lex.c ls: cannot access 'conffile.lex.c': No such file or directory $ flex conffile.l $ ls conffile.lex.c conffile.lex.c And this indeed has config.h include after a few C-specific includes. Since this is not a part of the source, there's nothing I can patch in this file. conffile.l has the config.h include present before everything else, and hence I'm not sure where this should be fixed. Did I misunderstand your solution somehow? If not, can you recommend something else? Best, Nilesh signature.asc Description: PGP signature
Re: Flex help needed for eegdev (Was: Re: eegdev: FTBFS: ../../lib/stdio.h:64:3: error: #error "Please include config.h first.")
On 25 August 2023 1:47:26 pm IST, Nilesh Patra wrote: >On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum wrote: >> Source: eegdev >> Version: 0.2-6 >> Severity: serious >> > In file included from conffile.lex.c:242: >> > ../../lib/stdio.h:64:3: error: #error "Please include config.h first." >> >64 | #error "Please include config.h first." >> > | ^ > >The lexed file conffile.lex.c seems to include some stuff before >config.h is included which is causing it to choke. > >I'm not acquainted with lexers and not sure what causes this. I'd >appreciate any help. Adding mentors list as well. If someone can help with this, that'd be great. Best, Nilesh
Bug#1042876: RFS: git-credential-azure/0.2.1-1 [ITP] -- Git credential helper for Azure Repos (program)
I've uploaded your package to new. Please provide a manpage in the next release. Best, Nilesh
Bug#1042876: RFS: git-credential-azure/0.2.1-1 [ITP] -- Git credential helper for Azure Repos (program)
On 11 August 2023 1:32:07 am IST, Nilesh Patra wrote: > > >On 4 August 2023 8:21:50 pm IST, M Hickford wrote: >>X-Debbugs-CC: debian...@lists.debian.org >> >>Dear mentors, >> >>I am looking for a sponsor for my package "git-credential-azure": >> >> * Package name : git-credential-azure >> Version : 0.2.1-1 >> Upstream contact : M Hickford >> * URL : https://github.com/hickford/git-credential-azure > >The upstream readme says that this software is in alpha. Do you consider it >ready to go to testing or is it better suited for experimental? > >I think it's the latter, but you probably know best. And since git-credential-manager is a mature alternative, what advantage does credential-azure have over it? Why not package credential-manager itself? Why not get the enhancements merged into the alternative instead? Thanks, Nilesh
Bug#1042876: RFS: git-credential-azure/0.2.1-1 [ITP] -- Git credential helper for Azure Repos (program)
On 4 August 2023 8:21:50 pm IST, M Hickford wrote: >X-Debbugs-CC: debian...@lists.debian.org > >Dear mentors, > >I am looking for a sponsor for my package "git-credential-azure": > > * Package name : git-credential-azure > Version : 0.2.1-1 > Upstream contact : M Hickford > * URL : https://github.com/hickford/git-credential-azure The upstream readme says that this software is in alpha. Do you consider it ready to go to testing or is it better suited for experimental? I think it's the latter, but you probably know best. Thanks, Nilesh
Re: Source package origin file differs from the official archive
On Tue, Dec 27, 2022 at 09:56:57AM +, M Hickford wrote: > Hi. Any ideas how to fix the error below? I built my package with `gbp > build-package` and uploaded with `dput -f mentors ../*.changes` Try to build/upload with this orig tarball http://deb.debian.org/debian/pool/main/g/git-credential-oauth/git-credential-oauth_0.1.5.orig.tar.gz It spits the error in the output, that is the checksums of the orig tarball and yours do not match. (I can't say _why_ that's the case, now for you) But since this is a go team package, you could simply ask for sponsorship on the mailing list, I am not very sure as to why you are pushing it to mentors.d.n, but HTH. > [1] Package source > https://salsa.debian.org/go-team/packages/git-credential-oauth/-/merge_requests/3 > Origin file : git-credential-oauth_0.1.5.orig.tar.gz > > sha256sum in upload : > defc68ce1a25423423e17dea77e3b3627aa0f99a98f4758aef3e708327c2664c > sha256sum in archive: > 5c36b29368a13af6cf394cd689a5616d5eec3fca7dc862e50ea070eb4f6d154c > > Please try to fix it and re-upload. -- Best, Nilesh signature.asc Description: PGP signature
Bug#1023987: RFS: golang-github-vektah-gqlparser/2.5.1-1 [ITP] -- Port of the parser from graphql-js into golang (library)
Control: close -1 Hi Taavi, On Sun, Nov 13, 2022 at 04:40:12PM +0200, Taavi Väänänen wrote: > I am looking for a sponsor for my package "golang-github-vektah-gqlparser": > > * Package name : golang-github-vektah-gqlparser >Version : 2.5.1-1 >Upstream contact : Adam Scarr > * URL : https://github.com/vektah/gqlparser > * License : Expat, BSD-3-clause > * Vcs : > https://salsa.debian.org/go-team/packages/golang-github-vektah-gqlparser >Section : golang I have uploaded this package to NEW with a copyright change. BTW, no need to create RFS bugs/uploads to mentors.d.n while asking for sponsorship in go-team. Sending an RFS mail to the list (like you did earlier) should be enough. Thank you. -- Best, Nilesh signature.asc Description: PGP signature
Re: Watch file github mode pointing to certain branch issue (Was: cmake help for minimac4 needed)
On Thu, Oct 27, 2022 at 11:37:39AM +0200, Andreas Tille wrote: > Hi Andrius, > > Am Thu, Oct 27, 2022 at 12:00:59PM +0300 schrieb Andrius Merkys: > > I have just pushed a fix. Please check if that works for you as well. > > Hmmm, this results in I pushed something via which I get: | uscan info: Launch mk-origtargz with options: | --package libomp-jonathonl --version 0.0+git20211216.5228495 --compression default --directory .. --copyright-file debian/copyright ../libomp-jonathonl-0.0+git20211216.5228495.tar.xz | Successfully symlinked ../libomp-jonathonl-0.0+git20211216.5228495.tar.xz to ../libomp-jonathonl_0.0+git20211216.5228495.orig.tar.xz. Maybe this shall do. Can you check? -- Best, Nilesh 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
Bug#1003090: RFS: ffcvt/1.7.5-1
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!
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.
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.
@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?
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.
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?
Somebody help please.
Hope that helps. Let me know if you need sponsoring.
Regards,
Nilesh
| cd obj-x86_64-linux-gnu/src/github.com/suntong/ffcvt/test && ./test-all.sh
| ffcvt
| Version 1.7.5 built on 2022-01-02
| - Test (config.go) cli help output
| - Test transcoding single file
| - Test -sym control
| - Compare test results
| --- ffcvt_test.txt2022-01-15 07:35:05.137033394 +
| +++ /tmp/ffcvt_test.txt 2022-01-15 07:35:08.193097895 +
| @@ -6,3 +6,3 @@
|
| - -t target type: webm/x265-opus/x264-mp3/youtube (FFCVT_T)
| + -t target type: webm/x265-opus/x264-mp3/wx/youtube/copy (FFCVT_T)
| -vesvideo encoding method set (FFCVT_VES)
| @@ -32,3 +32,8 @@
| -vssvideo: same size (FFCVT_VSS)
| + -C,Cut Cut segment(s) out to keep. Specify in the form of start-[end],
| + strictly in the format of hh:mm:ss, and may repeat (FFCVT_C,CUT)
| + -S,Seg Split video into multiple segments (strictly in format:
hh:mm:ss) (FFCVT_S,SEG)
| + -Speed Speed up/down video playback speed (e.g. 1.28) (FFCVT_SPEED)
| -lang language selection for audio stream extraction (FFCVT_LANG)
| + -sel subtitle encoding language (language picked for reencoded
video) (FFCVT_SEL)
| -o more options that will pass to ffmpeg program (FFCVT_O)
| @@ -49,2 +54,14 @@
|
| + -C value
| + Cut segment(s) out to keep. Specify in the form of start-[end],
| + strictly in the format of hh:mm:ss, and may repeat
| + -Cut value
| + Cut segment(s) out to keep. Specify in the form of start-[end],
| + strictly in the format of hh:mm:ss, and may repeat
| + -S string
| + Split video into multiple segments (strictly in format: hh:mm:ss)
| + -Seg string
| + Split video into multiple segments (strictly in format: hh:mm:ss)
| + -Speed string
| + Speed up/down video playback speed (e.g. 1.28)
| -abr string
| @@ -90,2 +107,4 @@
| -p par2create, create par2 files (in work directory)
| + -sel value
| + subtitle encoding language (language picked for reencoded video)
| -sep string
| @@ -99,3 +118,3 @@
| -t string
| - target type: webm/x265-opus/x264-mp3/youtube (default "webm")
| + target type: webm/x265-opus/x264-mp3/wx/youtube/copy (default "webm")
| -vc
| 1
OpenPGP_signature
Description: OpenPGP digital signature
Re: How to troubleshoot conffile files problems
Hi Tong, Replying since I am CC'ed, look below :- On 12/11/21 10:20 PM, Tong Sun wrote: Thanks, one more thing, The dbab can upgrade from oldstable (Buster) just fine, but I'm trying to remove the conffile files no longer exist since then (dbab_1.3.2-2), | If the conffile has not been shipped for several versions, and you are now modifying the maintainer scripts to clean up the obsolete file, prior-version should be based on the version of the package that you are now preparing, not the first version of the package that lacked the conffile. So I did this: $ cat debian/dbab.maintscript rm_conffile /etc/dnsmasq.d/dbab.adblock.conf 1.5.7-2~ rm_conffile /etc/dnsmasq.d/dbab.trashsites.conf 1.5.7-2~ rm_conffile /etc/dbab/dbab.proxy 1.5.7-2~ However, when I installed my 1.5.7-2 built such a way, I found the above files are still there. For me, the /etc/dbab/dbab.proxy *did* get removed, and the rest two are still present. Logs pasted at the end of this email. This is kinda expected I think. The reason is because "/etc/dbab/dbab.proxy" is present with the package installation in buster, and the rest two files are created during the postinst script. As far as I read the code, please see here[1] rm_conffile will work only when the config file belongs to the package, which is not "established" in this case. In buster version, $ dpkg -S /etc/dnsmasq.d/dbab.* dpkg-query: no path found matching pattern /etc/dnsmasq.d/dbab.adblock.conf dpkg-query: no path found matching pattern /etc/dnsmasq.d/dbab.trashsites.conf $ dpkg -S /etc/dbab/dbab.proxy dbab: /etc/dbab/dbab.proxy So I think you will have to manually take care of these two in postinst, I am not sure if there is a better way. [1]: https://sources.debian.org/src/dpkg/1.21.1/scripts/dpkg-maintscript-helper.sh/?hl=29#L98 Regards, Nilesh $ apt policy dbab dbab: Installed: 1.3.2-2 Candidate: 1.5.7-1 Version table: 1.5.7-1 500 500 http://deb.debian.org/debian sid/main amd64 Packages *** 1.3.2-2 100 100 /var/lib/dpkg/status $ sudo dpkg -i ./dbab_1.5.7-2_all.deb (Reading database ... 254432 files and directories currently installed.) Preparing to unpack ./dbab_1.5.7-2_all.deb ... Unpacking dbab (1.5.7-2) over (1.3.2-2) ... Setting up dbab (1.5.7-2) ... Installing new version of config file /etc/dbab/dbab.list+ ... curl 'https://pgl.yoyo.org/adservers/serverlist.php?hostformat=dnsmasq=0=plaintext' -o /tmp/dbab-map.adblock.conf % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 100 127k0 127k0 0 150k 0 --:--:-- --:--:-- --:--:-- 150k File /etc/dnsmasq.d/dbab-map.adblock.conf updated. File /etc/dnsmasq.d/dbab-map.trashsites.conf updated. Removing obsolete conffile /etc/dbab/dbab.proxy ... Processing triggers for man-db (2.9.4-2) ... $ ls -la /etc/dnsmasq.d/dbab.trashsites.conf /etc/dnsmasq.d/dbab.adblock.conf /etc/dbab/dbab.proxy ls: cannot access '/etc/dbab/dbab.proxy': No such file or directory -rw-r--r-- 1 root root 365 Dec 11 18:04 /etc/dnsmasq.d/dbab.adblock.conf -rw-r--r-- 1 root root 124 Dec 11 18:04 /etc/dnsmasq.d/dbab.trashsites.conf OpenPGP_signature Description: OpenPGP digital signature
Re: r-cran-ncdf4: ftbfs with autoconf 2.70
Hi Jeremy, On 9/8/21 8:24 PM, Jeremy Sowden wrote: >> [1] https://bugs.debian.org/978891 > > Try this patch. Thank you very much, works perfectly! I just uploaded with your patch applied. Nilesh OpenPGP_signature Description: OpenPGP digital signature
Bug#968615: RFS: golang-github-emersion-go-smtp-dev/0.13.0-1 -- SMTP library for Go
On Tue, 24 Aug 2021 01:10:19 +0530 Nilesh Patra wrote: > $ cat go.mod | grep go-smtp > github.com/emersion/go-smtp v0.12.1 > > go.mod points at 0.12.1, maybe 0.13.0 would be pretty harmless as well. > But for now, I uploaded 0.12.1 and uploaded > > Closing this for now, feel free to open this bug report if need be https://tracker.debian.org/news/1250899/accepted-golang-github-emersion-go-smtp-0121-1-source-into-unstable/ signature.asc Description: PGP signature
Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0
On Tue, 01 Jun 2021 08:02:43 +0200 Tobias Frost wrote: > On Fri, 9 Apr 2021 00:41:35 +0530 Nilesh Patra wrote: > > Hi Ben, > (...) > > It has been a while, but do you still need sponsoring for this? If yes, > > I'm willing to do so. > > > > PS: aerc is out of testing for this release unfortunately :/ > > Nevertheless, lets target the next one > > Pinging Ben explictly… Maybe he missed that mail. > (Otherwise I'll mark the bugs moreinfo in a few weeks, as they are not > actionable without Ben's feedback; this includes the other golang RFS-bugs as > well…) Few weeks earlier, I saw a message from the other manitainer of aerc (Karthik in CC) in a common channel saying that both him and Ben do not have the time and enrgy to maintain this. Maybe someone really will have to take over the maintainance. I'll try reaching out meanwhile to ben but Ben does not seem active either. @Karthik, can you confirm that this is right? And if yes, can you please send in an email to the list if someone wants to take over the maintainance, if not, could you please file in a RFA bug? It still has RC bugs open, version lags behind, and folks are interested in the package as well, so this is kinda important. Hope that's fine Nilesh signature.asc Description: PGP signature
Bug#989486: RFS: python-click-log/0.3.2-1 -- Logging integration for Click - Python 3.x
On 6/5/21 8:04 PM, Emmanuel Arias wrote: > Hi, > > I'm not DD, but I send you some review, to gain time: > > * d/changelog says: `Bump debhelper from old 10 to 12.` but actuall> > debhelper-compat version is 13. > * Please use UNRELEASED instead of unstable, that can be confused. Fixed > * What about enable salsa-ci? Enabled > * What about adding an autopkgtest? The test is running during build time.[1] I don't think running the same thing as autopkgtest does a very significant improvement. @Fabrice, more review: * The pristine tar contained .tar.gz.*, it should instead contain .orig.tar.gz for origtargz both for the sake of consistency and for origtargz to run fine * We are in freeze time, and a new version upload unless absolutely necessary isn't appropriate[2]. This package does not seem to have any (RC) bug or affecting any package that a version bump would be desired. Hence, this should be uploaded after bullseye release. Feel free to ping me then, and I'll happily sponsor. Also, please take a look at my commits in salsa. Thanks a lot for your work! [1]: https://salsa.debian.org/python-team/packages/python-click-log/-/blob/master/debian/rules#L13 [2]: https://release.debian.org/testing/freeze_policy.html Nilesh signature.asc Description: OpenPGP digital signature
Bug#988474: [Fwd: Bug#988474: RFS: freefem++/3.61.1+dfsg1-5.2 [NMU] [RC] -- Provides the binaries of the FreeFem++ FE suite]
Hi, On Mon, 17 May 2021 at 00:10, François Mazen wrote: > Hello Anton, > > > When the package is successfully built on all relevant platforms, > > you can ask the release team to unblock it. But it will unlikely > > happen > > due to release policy. > > I've requested the unblock, see [1]. Let me know if I've missed > something. > As you might see freefem++ is not in testing, and as per the release policy[1] the packages not in testing cannot re-enter testing at this stage
Bug#968576: RFS: golang-github-emersion-go-message-dev/0.12.0-1 -- dependency of aerc 0.4.0
Hi Ben, On Mon, 17 Aug 2020 23:19:44 +0200 Ben Fiedler wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package > "golang-github-emersion-go-message-dev", > found on salsa [1]. I've submitted a merge request [2], and would like > to request > Maintainer access to the salsa repo as well (for future updates). > > This package is a required dependency of aerc 0.4.0 [3]. > > Changelog: > > golang-github-emersion-go-message (0.12.0-1) unstable; urgency=medium > >* New upstream version > > -- Ben Fiedler Sat, 15 Aug 2020 21:32:15 > +0200 It has been a while, but do you still need sponsoring for this? If yes, I'm willing to do so. PS: aerc is out of testing for this release unfortunately :/ Nevertheless, lets target the next one Nilesh signature.asc Description: PGP signature
Bug#934515: RFS: golang-github-arduino-go-paths-helper [ITP]
Hi Rock, On Sun, 11 Aug 2019 21:20:45 +0100 Rock Storm wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for the package > "golang-github-arduino-go-timeutils" (See the ITP [1]). It is simply a > compilation of functions for getting: > > * Timezone offset without the DST component. > * The DST offset. > * Unix timestamp with the local timezone offset and DST added. > > This is one of the several small dependencies the package > 'arduino-builder' [2] has been split into. I need this library to be > uploaded to be able to prepare a new version of 'arduino-builder'. > > [1]: https://bugs.debian.org/922528 > [2]: https://salsa.debian.org/electronics-team/arduino/arduino-builder > > I've asked the go team for sponsorship but received no response [3] which > is why I'm asking here now. > > The package builds fine with gbp in a clean chroot and passes > autopkgtest and lintian. It is maintained in salsa [4]. Please consider > reviewing and/or uploading it. It is a very simple library which should > be a very easy sponsorship. Any comments or suggestions will be much > appreciated. > > [3]: https://lists.debian.org/debian-go/2019/07/msg7.html > [4]: > https://salsa.debian.org/go-team/packages/golang-github-arduino-go-timeutils > > (Please CC me when responding to this bug) I know it has been long, but do you still need sponsoring for this package? If yes, I am willing to do so Nilesh signature.asc Description: PGP signature
Re: [RFC] python-cobra, python3-sbml5
On Sun, 5 Apr 2020, 15:50 Andreas Tille, wrote: > On Sun, Apr 05, 2020 at 03:40:56PM +0530, Nilesh Patra wrote: > > > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > > > > provide) package. When I dug into looking at libsbml, I noticed that > the > > > > relevant file (libsbml.py) which throws error > > > > is generated with swig-3.0 by the upstream [3] > > > > > > I admit I'm absolutely naive about swig - but if libsbml.py is really > > > autogenerated what about re-generating it with swig-4? > > > > I think there's a miscommunication here. The file in the archive(on doing > > $apt source python3-sbml5) is generated with swig-4 already, while it's > > generated with swig-3 upstream. > > Hence the issue. > > Ahhh, so it is regenerated in the Debian package build process but it > conflicts with other parts of the upstream code? Did I now understood > correctly? > Yep. That's my _suspicion_ though, that the rest of the upstream code isn't compatible with the new version, and there are API changes needed. Hence I sent the mail to confirm if I'm thinking in the right direction. > I wonder if we should exclude this kind of autogenerated code inside > the source tarball since we are repackaging the source anyway to exclude > some files for policy reasons. I'm doing so in other source tarballs > for instance with cython files to be absolutely sure that this code > is regenerated. This would probably not solve the build issue but might > be a good idea in general. What do you think? > It seems like libsbml.py would be needed by the rest of the code. So we can maybe keep the upstream's generated code and not generate it on our own - this however does not seem DFSG compliant. Not really sure what to do here. > Kind regards > > Andreas. > > > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > > > > > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > > > > > > > [3]: > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple > > -- > http://fam-tille.de >
Re: [RFC] python-cobra, python3-sbml5
Hi On Sun, 5 Apr 2020, 11:43 Andreas Tille, wrote: > Hi Nilesh, > > On Sat, Apr 04, 2020 at 06:53:55PM +0530, Nilesh Patra wrote: > > > > >From the logs, in the last message[2] it looks like an import-error for > > '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a > > provide) package. When I dug into looking at libsbml, I noticed that the > > relevant file (libsbml.py) which throws error > > is generated with swig-3.0 by the upstream [3] > > I admit I'm absolutely naive about swig - but if libsbml.py is really > autogenerated what about re-generating it with swig-4? > I think there's a miscommunication here. The file in the archive(on doing $apt source python3-sbml5) is generated with swig-4 already, while it's generated with swig-3 upstream. Hence the issue. > > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 > > > > [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 > > > > [3]: > > > https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple > > > > Thanks and regards > > Nilesh > > -- > http://fam-tille.de >
[RFC] python-cobra, python3-sbml5
Hi, Currently python-cobra FTBFS reported here [1]. >From the logs, in the last message[2] it looks like an import-error for '_libsbml' file which corresponds to libsbml (with python3-sbml5 as a provide) package. When I dug into looking at libsbml, I noticed that the relevant file (libsbml.py) which throws error is generated with swig-3.0 by the upstream [3] While the same file in the apt archive (observed after $apt source python3-sbml5) seems to be generated with swig-4.0, and that's the current swig version in Debian now. When I compared, the one generated with swig 4.0 looks pretty different from the one generated by swig 3.0. I "suspect" that the error is due to the swig version change to 4.0, and corresponding API changes. I would really appreciate if I could have more folks "confirm" that this is the case, and I'm not missing out on anything else. I'll then file a report upstream then, asking for corresponding code changes needed for swig 4.0. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955656#10 [3]: https://salsa.debian.org/med-team/libsbml/-/blob/master/src/bindings/python/libsbml.py?expanded=true=simple Thanks and regards Nilesh
