Q16 compile for the general CPU, and Illegal instruction
Hi, The ImageMagick has stayed in V6 for too long and I tried to compile its V7 myself to see what the problem might be, and indeed I found a big problem -- I got "Illegal instruction" when I tried to install the built package elsewhere. At first it is almost like *"the built packages cannot be used in other machines, but only to the built machine itself"*, and it took me quite a while to get to the bottom of it. In summary, - I tried to build with two cloud providers, and none of the built packages can be used in my VPS. - I then build in my VPS and the built packages can be used in my VPS (ubuntu:22.04). - however, it cannot be used in my Debian. I now believe the "Illegal instruction" is because of not the distro but the CPU instruction set the compiler decided to use, based on the CPU of the machine. It turns out that my Debian has the oldest CPU and least CPU flags, and the package built there can be used anywhere else. So here comes my question, With current cloud-compiling approaches, how should we make sure that the built package works for the older x86_64 CPUs possible, and especially about this Q16 compilation for ImageMagick? PS, the compilation is done via https://github.com/SoftCreatR/imei/. thanks
Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager
Retry for Paul. The NMU is not from me but Mateusz. Hope you'll be a DM soon @Mateusz, but meanwhile, I concur with Paul, don't do NMU, be the package owner and do a normal maintainer upload @Mateusz, as you cans see from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927477 that the package owner stop responding to people more than 5 years ago. @Paul, no hurry, take your time, as we've been waiting for more than 8 years, cheers On Wed, Aug 2, 2023 at 6:25 PM Paul Tagliamonte - paul...@debian.org wrote: > > Happy to review - why a NMU? Let's make it a team upload or you're welcome to > join as an uploader! > > I don't see the bug on CC, but please feel free to re add it on your reply > > I'll see about reviewing this later today, but I'd prefer to have this be a > normal maintainer upload :) > > Paul > > On Wed, Aug 2, 2023, 6:20 PM Tong Sun wrote: >> >> Thanks Mateusz. >> >> Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just >> trying to stir up some noise to get you more traction. >> >> CCing Paul who offered me help last time when I attempted it. >> >> Thanks everyone! >> >> On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl wrote: >>> >>> Package: sponsorship-requests >>> Severity: important >>> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "fluxbox": >>> >>> * Package name : fluxbox >>>Version : 1.3.7-1+nmu1 >>>Upstream contact : fluxbox maintainers >>> * URL : https://fluxbox.org >>> * License : CC-BY-SA-3, Expat >>> * Vcs : [fill in URL of packaging vcs] >>>Section : x11 >>> >>> The source builds the following binary packages: >>> >>> fluxbox - Highly configurable and low resource X11 Window manager >>> >>> To access further information about this package, please visit the >>> following URL: >>> >>> https://mentors.debian.net/package/fluxbox/ >>> >>> Alternatively, you can download the package with 'dget' using this command: >>> >>> dget -x >>> https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc >>> >>> Changes since the last upload: >>> >>> fluxbox (1.3.7-1+nmu1) unstable; urgency=medium >>> . >>>* Non-maintainer upload. (See #927477) >>>* Upload to unstable, latest upstream version stuck in experimental for >>> 8 years. (Closes: #969440 #987223) >>>* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578) >>>* Drop depends on deprecated GTK 2. No longer used. (Closes: #967345) >>>* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS with >>> build-system: fix "make check". >>>* Bump dh version to 13. >>>* Bump Standards-Version to 4.6.2. >>>* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch for >>> replace FbRootWindow::depth with maxDepth. (Closes: #1003798) >>> >>> Regards, >>> -- >>> Mateusz Łukasik >>> >>>
Bug#1042778: RFS: fluxbox/1.3.7-1+nmu1 [NMU] [RC] -- Highly configurable and low resource X11 Window manager
Thanks Mateusz. Seeing that your previous NMU 1.3.5-2.1 upload got unnoticed, I'm just trying to stir up some noise to get you more traction. CCing Paul who offered me help last time when I attempted it. Thanks everyone! On Mon, Jul 31, 2023 at 4:46 PM Mateusz Łukasik - mat...@linuxmint.pl wrote: > Package: sponsorship-requests > Severity: important > > Dear mentors, > > I am looking for a sponsor for my package "fluxbox": > > * Package name : fluxbox >Version : 1.3.7-1+nmu1 >Upstream contact : fluxbox maintainers > * URL : https://fluxbox.org > * License : CC-BY-SA-3, Expat > * Vcs : [fill in URL of packaging vcs] >Section : x11 > > The source builds the following binary packages: > > fluxbox - Highly configurable and low resource X11 Window manager > > To access further information about this package, please visit the following > URL: > > https://mentors.debian.net/package/fluxbox/ > > Alternatively, you can download the package with 'dget' using this command: > > dget -x > https://mentors.debian.net/debian/pool/main/f/fluxbox/fluxbox_1.3.7-1+nmu1.dsc > > Changes since the last upload: > > fluxbox (1.3.7-1+nmu1) unstable; urgency=medium > . >* Non-maintainer upload. (See #927477) >* Upload to unstable, latest upstream version stuck in experimental for > 8 years. (Closes: #969440 #987223) >* Merge my changes for NMU 1.3.5-2.1. (Closes: #943578) >* Drop depends on deprecated GTK 2. No longer used. (Closes: #967345) >* Add debian/patches/fix_ld_ftbfs.patch from upstream for fix FTBFS with > build-system: fix "make check". >* Bump dh version to 13. >* Bump Standards-Version to 4.6.2. >* Add debian/patches/replace_FbRootWindow_depth_with_maxDepth.patch for > replace FbRootWindow::depth with maxDepth. (Closes: #1003798) > > Regards, > -- > Mateusz Łukasik > > >
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#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#1003090: RFS: ffcvt/1.7.5-1
Trying again. On Thu, Jan 6, 2022 at 1:16 PM Tong Sun wrote: > > On Mon, Jan 3, 2022 at 3:45 PM Tong Sun wrote: > > > > On Mon, Jan 3, 2022 at 3:20 PM Tong Sun > > wrote: > > > > > > Package: sponsorship-requests > > > Severity: normal > > > > > > Dear mentors, > > > > > > I updated my ffcvt to a newer version, and am now looking for a sponsor. > > > > > > Here is from the d/changelog > > > > > > ffcvt (1.7.5-1) unstable; urgency=medium > > > > > > * New upstream version 1.7.5 > > > - add --Speed for speeding up playback (v1.7.5) > > > - add a copy target type that can speed up operations (v1.7.4) > > > - add option -S,Seg -- split video into multiple segments (v1.7.3) > > > - add option -sel, subtitle encoding language (v1.7.2) > > > - add option -C which allows cutting multiple segments (v1.7.1) > > > - add wx type for weixin (v1.7.0) > > > - x264-mp3 type set ext to .mp4 (v1.6.2) > > > * fix "source: out-of-date-standards-version" problem > > > * fix "source: update-debian-copyright" problem > > > * fix "source: prefer-uscan-symlink filenamemangle" problem > > > > > > Note > > > > > > 1) My GPG key expired a few days ago, and I've already submit the > > > update to keyring.debian.org, yet I understand it might take a while > > > to really get updated, so please > > > > > > go directly to > > > https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master > > > > > > 2) Please disregard the .gitlab-ci.yml build failure as I'm not > > > supposed to touch it. > > > > Ops, please hold off reviewing it, as I've found out where the problem > > is -- ffcvt depends on the latest easygen to build yet I haven't > > upgraded easygen in Debian yet. and my expired GPG key is preventing > > me from fixing it promptly. > > > > Will update when the situation is fixed. > > > > Sorry & thanks > > > > > The build is fine, check out here -- > > > https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true > > 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 it builds OK on github but fails in salsa CI build, and I still hope that somebody can help. I'll wait for one or two weeks more, and if still nobody can help, I'll remove the build dependency of easygen as planned, as I know for sure it can fix the issue. > Somebody help please. thanks
Bug#1003090: RFS: ffcvt/1.7.5-1
On Mon, Jan 3, 2022 at 3:45 PM Tong Sun wrote: > > On Mon, Jan 3, 2022 at 3:20 PM Tong Sun > wrote: > > > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I updated my ffcvt to a newer version, and am now looking for a sponsor. > > > > Here is from the d/changelog > > > > ffcvt (1.7.5-1) unstable; urgency=medium > > > > * New upstream version 1.7.5 > > - add --Speed for speeding up playback (v1.7.5) > > - add a copy target type that can speed up operations (v1.7.4) > > - add option -S,Seg -- split video into multiple segments (v1.7.3) > > - add option -sel, subtitle encoding language (v1.7.2) > > - add option -C which allows cutting multiple segments (v1.7.1) > > - add wx type for weixin (v1.7.0) > > - x264-mp3 type set ext to .mp4 (v1.6.2) > > * fix "source: out-of-date-standards-version" problem > > * fix "source: update-debian-copyright" problem > > * fix "source: prefer-uscan-symlink filenamemangle" problem > > > > Note > > > > 1) My GPG key expired a few days ago, and I've already submit the > > update to keyring.debian.org, yet I understand it might take a while > > to really get updated, so please > > > > go directly to > > https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master > > > > 2) Please disregard the .gitlab-ci.yml build failure as I'm not > > supposed to touch it. > > Ops, please hold off reviewing it, as I've found out where the problem > is -- ffcvt depends on the latest easygen to build yet I haven't > upgraded easygen in Debian yet. and my expired GPG key is preventing > me from fixing it promptly. > > Will update when the situation is fixed. > > Sorry & thanks > > > The build is fine, check out here -- > > https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true 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... Somebody help please.
Bug#1003090: RFS: ffcvt/1.7.5-1
On Mon, Jan 3, 2022 at 3:20 PM Tong Sun wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I updated my ffcvt to a newer version, and am now looking for a sponsor. > > Here is from the d/changelog > > ffcvt (1.7.5-1) unstable; urgency=medium > > * New upstream version 1.7.5 > - add --Speed for speeding up playback (v1.7.5) > - add a copy target type that can speed up operations (v1.7.4) > - add option -S,Seg -- split video into multiple segments (v1.7.3) > - add option -sel, subtitle encoding language (v1.7.2) > - add option -C which allows cutting multiple segments (v1.7.1) > - add wx type for weixin (v1.7.0) > - x264-mp3 type set ext to .mp4 (v1.6.2) > * fix "source: out-of-date-standards-version" problem > * fix "source: update-debian-copyright" problem > * fix "source: prefer-uscan-symlink filenamemangle" problem > > Note > > 1) My GPG key expired a few days ago, and I've already submit the > update to keyring.debian.org, yet I understand it might take a while > to really get updated, so please > > go directly to > https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master > > 2) Please disregard the .gitlab-ci.yml build failure as I'm not > supposed to touch it. Ops, please hold off reviewing it, as I've found out where the problem is -- ffcvt depends on the latest easygen to build yet I haven't upgraded easygen in Debian yet. and my expired GPG key is preventing me from fixing it promptly. Will update when the situation is fixed. Sorry & thanks > The build is fine, check out here -- > https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true > > Thanks > > > On Sat, Jan 9, 2021 at 11:23 PM Dmitry Smirnov wrote: > > > > Please help. > > > > I'm at the limit of my capacity so I don't have much time to spare... > > I had a quick look and I'd like to ask you to make few trivial changes > > if you could, before I upload. > > > > Please ... > > > > It might take few more _flawless_ uploads before I'll become confident > > enough in your work to give you upload rights.
Bug#1003090: RFS: ffcvt/1.7.5-1
Package: sponsorship-requests Severity: normal Dear mentors, I updated my ffcvt to a newer version, and am now looking for a sponsor. Here is from the d/changelog ffcvt (1.7.5-1) unstable; urgency=medium * New upstream version 1.7.5 - add --Speed for speeding up playback (v1.7.5) - add a copy target type that can speed up operations (v1.7.4) - add option -S,Seg -- split video into multiple segments (v1.7.3) - add option -sel, subtitle encoding language (v1.7.2) - add option -C which allows cutting multiple segments (v1.7.1) - add wx type for weixin (v1.7.0) - x264-mp3 type set ext to .mp4 (v1.6.2) * fix "source: out-of-date-standards-version" problem * fix "source: update-debian-copyright" problem * fix "source: prefer-uscan-symlink filenamemangle" problem Note 1) My GPG key expired a few days ago, and I've already submit the update to keyring.debian.org, yet I understand it might take a while to really get updated, so please go directly to https://salsa.debian.org/go-team/packages/ffcvt/-/commits/master 2) Please disregard the .gitlab-ci.yml build failure as I'm not supposed to touch it. The build is fine, check out here -- https://github.com/suntong/ffcvt/runs/4687405723?check_suite_focus=true Thanks On Sat, Jan 9, 2021 at 11:23 PM Dmitry Smirnov wrote: > > Please help. > > I'm at the limit of my capacity so I don't have much time to spare... > I had a quick look and I'd like to ask you to make few trivial changes > if you could, before I upload. > > Please ... > > It might take few more _flawless_ uploads before I'll become confident > enough in your work to give you upload rights.
Re: How to troubleshoot conffile files problems
On Sat, Dec 11, 2021 at 11:50 AM Tong Sun wrote: > > On Tue, Dec 7, 2021 at 4:07 PM Andrey Rahmatullin wrote: > > > > On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote: > > > > right? > > Right. > > > > ... > > > right? > > Right. > > 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. I meant, upgrading from dbab_1.3.2-2 to dbab_1.5.7-2 built in such way. > What's the problem and how can I fix it? thx
Re: How to troubleshoot conffile files problems
On Tue, Dec 7, 2021 at 4:07 PM Andrey Rahmatullin wrote: > > On Tue, Dec 07, 2021 at 01:56:26PM -0500, Tong Sun wrote: > > right? > Right. > > ... > > right? > Right. 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. What's the problem and how can I fix it? thx
Re: How to troubleshoot conffile files problems
On Tue, Dec 7, 2021 at 1:06 PM Andrey Rahmatullin wrote: > > On Tue, Dec 07, 2021 at 12:57:37PM -0500, wrote: > > > > > > How to do that please? > > > > > The correct way, it seems, would be to follow the suggestion in the > > > > > original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > > > > > the 1.3.3-1 postrm. > > > > > > > > I still don't quite understand what you actually mean, > > > I just mean the original bug report already had a suggestion that seems > > > correct to me. > > > > Can you give me a simple example package showing how it should be done > > please? > > > > It is not that I didn't try my best but the case is I've already tried > > my best to guess what the above means but it seems I guessed wrong > > each time. Thus I need detailed help, those few words only get me > > going around the circles. > Sorry, I'm not going to make an upload a package for this. > Here are the instructions I meant and I don't know what can be clearer > than that short of an actual debdiff: > > """ > I see the postrm has > > /etc/dnsmasq.d/dbab.* > > which I take it would have to be dbab-map.* > """ That the 1.3.3-1 postrm, and now the package is at 1.5.7, many versions after that. I.e., it was fixed a long time ago, and I presume that I don't need to do anything for that. > > OK, let's start from the beginning: > > > > > > How to properly handle conffile files in such a case? > > > > > You should remove them manually in postrm, but only on > > > purge. > > > > That's actually what I've been doing, removing them manually in postrm > > and on purge -- > > > > https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328 > But #958900 was about files that were not affected by that. No, you're right, #958900 is fixes afterward, not in that specific commit. > > But I was told to "using rm_conffile directive from .maintscript file" > This is wrong. rm_conffile is only for cases when a conffile is no longer > shipped. This is explained in dpkg-maintscript-helper(1). But > /etc/dnsmasq.d/dbab.*, or /etc/dnsmasq.d/dbab, or > /etc/dnsmasq.d/dbab-map.*, are not even conffiles, as far as I can see (as > they are not shipped in the package, as far as I can see). So you are saying that the correct way to do it is this -- https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.postrm right? > > So I did, see -- > > https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8 > Yup, this is wrong. And /etc/dbab is a dir, so that line is doubly wrong. what's the correct way for the fix then? remove the dbab.maintscript file, i.e., https://salsa.debian.org/debian/dbab/-/blob/master/debian/dbab.maintscript, right? > > and that's what I did, instead removing them manually in postrm with > > `rm`, I used > > `dpkg-maintscript-helper rm_conffile` instead. > > > > And now I'm at > > > > W: maintainer-script-should-not-use-dpkg-maintscript-helper > > > > I.e., I've gone through a full circle. > That's not even a circle, these are multiple separate problems, some of > them unrelated. Thanks for your help. Sorry for being dense.
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 7, 2021 at 1:07 PM Andrey Rahmatullin wrote: > > On Tue, Dec 07, 2021 at 01:03:10PM -0500, wrote: > > On Tue, Dec 7, 2021 at 12:53 PM Andrey Rahmatullin wrote: > > > > > > On Tue, Dec 07, 2021 at 12:40:06PM -0500, wrote: > > > > > > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a > > > > > > warning? > > > > > Have you read its description? > > > > > > > > Please don't overestimate my ability to decrypt the description. > > > > If I understand what it is saying, I won't be asking such a question. > > > Do you know that lintian tags have descriptions and not just names? > > > > I've read > > > > https://lintian.debian.org/tags/maintainer-script-should-not-use-dpkg-maintscript-helper?version=2.112.18 > > > > and still unable to decrypt the description. > Which parts of "The maintainer script seems to make manual calls to the > dpkg-maintscript-helper(1) utility. Please use package.maintscript files > instead" are you unable to decipher? As I said, I'll follow the situation in another email thread on this. Let's continue there.
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 7, 2021 at 12:53 PM Andrey Rahmatullin wrote: > > On Tue, Dec 07, 2021 at 12:40:06PM -0500, wrote: > > > > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a > > > > warning? > > > Have you read its description? > > > > Please don't overestimate my ability to decrypt the description. > > If I understand what it is saying, I won't be asking such a question. > Do you know that lintian tags have descriptions and not just names? I've read https://lintian.debian.org/tags/maintainer-script-should-not-use-dpkg-maintscript-helper?version=2.112.18 and still unable to decrypt the description.
Re: How to troubleshoot conffile files problems
On Tue, Dec 7, 2021 at 10:41 AM Andrey Rahmatullin wrote: > > On Sun, Dec 05, 2021 at 10:19:44AM -0500, wrote: > > > > How to do that please? > > > The correct way, it seems, would be to follow the suggestion in the > > > original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > > > the 1.3.3-1 postrm. > > > > I still don't quite understand what you actually mean, > I just mean the original bug report already had a suggestion that seems > correct to me. Can you give me a simple example package showing how it should be done please? It is not that I didn't try my best but the case is I've already tried my best to guess what the above means but it seems I guessed wrong each time. Thus I need detailed help, those few words only get me going around the circles. OK, let's start from the beginning: > > How to properly handle conffile files in such a case? > You should remove them manually in postrm, but only on > purge. That's actually what I've been doing, removing them manually in postrm and on purge -- https://salsa.debian.org/debian/dbab/-/commit/0acfe617f064c5907f999707e37be12c7b9f8328 But I was told to "using rm_conffile directive from .maintscript file" So I did, see -- https://salsa.debian.org/debian/dbab/-/commit/eca5bf35dc20843907b3eb0078a7926117bdf0e8 But it is causing the above problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 I.e., grep: /etc/dbab/dbab.list-: No such file or directory cat: /etc/dbab/dbab.addr: No such file or directory They should be there but they are not during upgrade. And the fix I got was: > fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > > > the 1.3.3-1 postrm. and that's what I did, instead removing them manually in postrm with `rm`, I used `dpkg-maintscript-helper rm_conffile` instead. And now I'm at W: maintainer-script-should-not-use-dpkg-maintscript-helper I.e., I've gone through a full circle. Someone give detailed help please. thx
Re: maintainer-script-should-not-use-dpkg-maintscript-helper
On Tue, Dec 7, 2021 at 11:52 AM Andrey Rahmatullin wrote: > > On Tue, Dec 07, 2021 at 11:49:32AM -0500, Tong Sun wrote: > > Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a warning? > Have you read its description? Please don't overestimate my ability to decrypt the description. If I understand what it is saying, I won't be asking such a question. But I'll follow the situation in another email thread on this.
maintainer-script-should-not-use-dpkg-maintscript-helper
Hi, Why `maintainer-script-should-not-use-dpkg-maintscript-helper` is a warning? Aren't we supposed to use dpkg-maintscript-helper in maintainer scripts? At least I was told to do so. I tried to add `dpkg-maintscript-helper rm_conffile` in my .postrm file for my dbab package, and now I'm getting the above warning message. How can I fix the situation? thx
Re: How to troubleshoot conffile files problems
On Sun, Dec 5, 2021 at 1:05 AM Andrey Rahmatullin wrote: > > On Sat, Dec 04, 2021 at 11:29:58PM -0500, Tong Sun wrote: > > > You should remove them manually in postrm, but only on > > > purge. > > > But now you will need to also recover from a bad state > left by upgrades to 1.5.7-1. Ah... it is getting more and more complicated. Nobody would be able to upgrade to 1.5.7-1 normally, so it is OK to use next good version as the fix please? Else, all the upgrade related problems can be easily fixed by purging the old version, and installing a brand new version. Would that be OK as the fix please? This is really a simple script, and I really hope that the debian side won't be complicated by any one-off end cases. > > How to do that please? > The correct way, it seems, would be to follow the suggestion in the > original bug report and fix the "rm -f /etc/dnsmasq.d/dbab.*" line in > the 1.3.3-1 postrm. I still don't quite understand what you actually mean, but let me make a guess (and commit) and you can tell me if it is what you mean or not... thx Andrey
Re: How to troubleshoot conffile files problems
On Sat, Dec 4, 2021 at 11:09 PM Tong Sun wrote: > > On Thu, Dec 2, 2021 at 10:46 AM Tong Sun wrote: > > > > Hi, > > > > I'm having problem with my conffile files, see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > > > I.e., > > > > > > grep: /etc/dbab/dbab.list-: No such file or directory > > cat: /etc/dbab/dbab.addr: No such file or directory > > Oh, sorry Andrey, I didn't notice your following reply. sorry > Well those errors are clearly caused by dbab.maintscript saying > "rm_conffile /etc/dbab", while /etc/dbab is indeed a directory and not a > file. So it would be helpful if you told us what were you trying to do by > this. If this is about #958900 then rm_conffile is *not* about removing > files on purge. The following is what I were trying to do, and yes, I hoped that it can be used to fix #958900, as well as doing the following: > OK, I want to remove all conffile files and reinstall the new ones > when doing package upgrade, as there isn't much user intervention to > those conffile files. All are provided by the package. > > So I do `rm_conffile` to the old conffile files when doing package > upgrade, but the new conffile files provided by the new upgrading > package did not get installed afterwards, before they were used. > > > They should be there but I have no idea why they are not. > > That's why they are there if doing fresh package installation but they > are not there if doing package upgrade. > > How to properly handle conffile files in such a case? > > You should remove them manually in postrm, but only on > purge. How to do that please? I see some scripts under https://wiki.debian.org/DpkgConffileHandling that can handle such / specific cases, but there is also a claim of "since dpkg 1.15.7.2 this can be done using dpkg-maintscript-helper". So, I have 4 ~ 6 conffile files, how to remove them manually in postrm but only on purge pls? > Unrelated, but is the package doesn't function without files downloaded > from Internet, and even downloads them in postinst, then it should go to > contrib. Should I file a bug about this? Please don't yet, as I totally don't understand what you want me to do, now. Unless you can send me a patch, please let me get this thing over first. > Please, please help. > > Again, the package source is at: > https://salsa.debian.org/debian/dbab/ > > Thanks > > > > Is there any way to have more insights into what's going on during the > > package upgrade or conffile files handling? > > > > thx > > > > On Thu, Nov 25, 2021 at 3:45 PM Tong Sun > > wrote: > > > > > > Hi Mentors, > > > > > > I need help. > > > > > > My package cannot be upgraded from current version to latest version > > > -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > > > > > It might have something to do with obsoleted conffile files or it > > > might even not. The problem is, I've been trying to understand how the > > > conffile files work, and I think I'm doing the right thing, yet my > > > package cannot be properly upgraded. > > > > > > - I don't understand what breaks and why, from the output of the > > > package upgrade log (see > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). > > > - Thus, I have no idea how to fix it, and all my previous attempts > > > failed. So, > > > > > > Please help. The package source is at: > > > > > > https://salsa.debian.org/debian/dbab/ > > > > > > > > > Also, I've been trying to solve it on my own for so long that now the > > > good version in testing is marked for autoremoval, for the reason > > > that: > > > > > > > If a package is out of sync between unstable and testing for a longer > > > period, this usually means that bugs in the package in testing cannot be > > > fixed via unstable. > > > > > > However, this is not true in my case. So if I still cannot fix the > > > problem by myself by the deadline, would I be able to at least stop my > > > package being autoremed from testing? > > > > > > Thanks for helping > > > > > > -- Forwarded message - > > > From: Debian testing autoremoval watch > > > Date: Sat, Nov 20, 2021 at 11:40 PM > > > Subject: dbab is marked for autoremoval from testing > > > To: > > > > > > > > > dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11 > > > > > > It is affected by these RC bugs: > > > 999581: dbab: fails to migrate to testing for too long: unresolved RC bug > > > https://bugs.debian.org/999581 > > > > > > > > > > > > This mail is generated by: > > > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > > > > > Autoremoval data is generated by: > > > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Re: How to troubleshoot conffile files problems
On Thu, Dec 2, 2021 at 10:46 AM Tong Sun wrote: > > Hi, > > I'm having problem with my conffile files, see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > I.e., > > > grep: /etc/dbab/dbab.list-: No such file or directory > cat: /etc/dbab/dbab.addr: No such file or directory > OK, I want to remove all conffile files and reinstall the new ones when doing package upgrade, as there isn't much user intervention to those conffile files. All are provided by the package. So I do `rm_conffile` to the old conffile files when doing package upgrade, but the new conffile files provided by the new upgrading package did not get installed afterwards, before they were used. > They should be there but I have no idea why they are not. That's why they are there if doing fresh package installation but they are not there if doing package upgrade. How to properly handle conffile files in such a case? Please, please help. Again, the package source is at: https://salsa.debian.org/debian/dbab/ Thanks > Is there any way to have more insights into what's going on during the > package upgrade or conffile files handling? > > thx > > On Thu, Nov 25, 2021 at 3:45 PM Tong Sun > wrote: > > > > Hi Mentors, > > > > I need help. > > > > My package cannot be upgraded from current version to latest version > > -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > > > It might have something to do with obsoleted conffile files or it > > might even not. The problem is, I've been trying to understand how the > > conffile files work, and I think I'm doing the right thing, yet my > > package cannot be properly upgraded. > > > > - I don't understand what breaks and why, from the output of the > > package upgrade log (see > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). > > - Thus, I have no idea how to fix it, and all my previous attempts failed. > > So, > > > > Please help. The package source is at: > > > > https://salsa.debian.org/debian/dbab/ > > > > > > Also, I've been trying to solve it on my own for so long that now the > > good version in testing is marked for autoremoval, for the reason > > that: > > > > > If a package is out of sync between unstable and testing for a longer > > period, this usually means that bugs in the package in testing cannot be > > fixed via unstable. > > > > However, this is not true in my case. So if I still cannot fix the > > problem by myself by the deadline, would I be able to at least stop my > > package being autoremed from testing? > > > > Thanks for helping > > > > -- Forwarded message - > > From: Debian testing autoremoval watch > > Date: Sat, Nov 20, 2021 at 11:40 PM > > Subject: dbab is marked for autoremoval from testing > > To: > > > > > > dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11 > > > > It is affected by these RC bugs: > > 999581: dbab: fails to migrate to testing for too long: unresolved RC bug > > https://bugs.debian.org/999581 > > > > > > > > This mail is generated by: > > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > > > Autoremoval data is generated by: > > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
How to troubleshoot conffile files problems
Hi, I'm having problem with my conffile files, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 I.e., grep: /etc/dbab/dbab.list-: No such file or directory cat: /etc/dbab/dbab.addr: No such file or directory They should be there but I have no idea why they are not. Is there any way to have more insights into what's going on during the package upgrade or conffile files handling? thx On Thu, Nov 25, 2021 at 3:45 PM Tong Sun wrote: > > Hi Mentors, > > I need help. > > My package cannot be upgraded from current version to latest version > -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 > > It might have something to do with obsoleted conffile files or it > might even not. The problem is, I've been trying to understand how the > conffile files work, and I think I'm doing the right thing, yet my > package cannot be properly upgraded. > > - I don't understand what breaks and why, from the output of the > package upgrade log (see > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). > - Thus, I have no idea how to fix it, and all my previous attempts failed. So, > > Please help. The package source is at: > > https://salsa.debian.org/debian/dbab/ > > > Also, I've been trying to solve it on my own for so long that now the > good version in testing is marked for autoremoval, for the reason > that: > > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. > > However, this is not true in my case. So if I still cannot fix the > problem by myself by the deadline, would I be able to at least stop my > package being autoremed from testing? > > Thanks for helping > > -- Forwarded message - > From: Debian testing autoremoval watch > Date: Sat, Nov 20, 2021 at 11:40 PM > Subject: dbab is marked for autoremoval from testing > To: > > > dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11 > > It is affected by these RC bugs: > 999581: dbab: fails to migrate to testing for too long: unresolved RC bug > https://bugs.debian.org/999581 > > > > This mail is generated by: > https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl > > Autoremoval data is generated by: > https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
My package is marked for autoremoval from testing
Hi Mentors, I need help. My package cannot be upgraded from current version to latest version -- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769 It might have something to do with obsoleted conffile files or it might even not. The problem is, I've been trying to understand how the conffile files work, and I think I'm doing the right thing, yet my package cannot be properly upgraded. - I don't understand what breaks and why, from the output of the package upgrade log (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=995769). - Thus, I have no idea how to fix it, and all my previous attempts failed. So, Please help. The package source is at: https://salsa.debian.org/debian/dbab/ Also, I've been trying to solve it on my own for so long that now the good version in testing is marked for autoremoval, for the reason that: > If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. However, this is not true in my case. So if I still cannot fix the problem by myself by the deadline, would I be able to at least stop my package being autoremed from testing? Thanks for helping -- Forwarded message - From: Debian testing autoremoval watch Date: Sat, Nov 20, 2021 at 11:40 PM Subject: dbab is marked for autoremoval from testing To: dbab 1.5.01-1 is marked for autoremoval from testing on 2021-12-11 It is affected by these RC bugs: 999581: dbab: fails to migrate to testing for too long: unresolved RC bug https://bugs.debian.org/999581 This mail is generated by: https://salsa.debian.org/release-team/release-tools/-/blob/master/mailer/mail_autoremovals.pl Autoremoval data is generated by: https://salsa.debian.org/qa/udd/-/blob/master/udd/testing_autoremovals_gatherer.pl
Only got half of the conversation from salsa.debian.org in mail
Hi, I can only get half of the conversations from salsa.debian.org in mail, whereas from github, I can get both other peoples' comments as well as my replies in mail. Is that possible with salsa.debian.org? thx
origtargz unable to detect upstream new release
Hi, I found that origtargz unable to detect upstream new release for me. -- $ origtargz Using existing ../dbab_1.5.6.orig.tar.gz $ origtargz -d Using existing ../dbab_1.5.6.orig.tar.gz rm ../dbab_1.5.6.orig.tar.gz $ origtargz pristine-tar: successfully generated ../dbab_1.5.6.orig.tar.gz origtargz -h -- I do have a new upstream new release, and I didn't see any other switches that might help. In the end, I have to use gbp import-orig --uscan and it works just as expected. However, I'm still wondering if there is any way to make origtargz works as well. thx
Re: rm_conffile and left behind files
On Sat, Mar 6, 2021 at 11:54 PM Paul Wise wrote: > > On Sun, Mar 7, 2021 at 4:45 AM Tong Sun wrote: > > > Ah, indeed. the two files are modified after the package was > > installed. Actually they are generated, not from within the package. > > Configuration files should either be conffiles installed in the .deb > or files created by the package at postinst/run time, but not both of > these at the same time. Those were created by the package at postinst time, and can be updated later, as per user's request. > So the .deb should not contain the files and they should get removed > from disk by the prerm. Also you will need to transition them from > conffiles to regular files, I don't know how to do that though. OK. I'll try to look that up. Meanwhile, Is it OK that I simply `rm` them, like `rm /etc/dnsmasq.d/dbab-*`? since they are all auto-generated, i.e., they don't contain customizations made by the administrator that they don’t want to wipe out.
Re: rm_conffile and left behind files
On Sat, Mar 6, 2021 at 10:47 PM Paul Wise - p...@debian.org wrote: > > On Sun, Mar 7, 2021 at 3:31 AM Tong Sun wrote: > > > after I remove the package > > Did you remove the package or purge it? Removing it will not run the > postrm, but purging it will. I use purge. > > the last two files ... still remains and are left behind, while the first > > one was indeed gone. > > Were the two files modified after the package was installed? Ah, indeed. the two files are modified after the package was installed. Actually they are generated, not from within the package. So what should I do?
rm_conffile and left behind files
Hi, $ head /var/lib/dpkg/info/dbab.postrm #!/bin/sh set -e # Automatically added by dh_installdeb/13.3.1 dpkg-maintscript-helper rm_conffile /etc/dbab -- "$@" dpkg-maintscript-helper rm_conffile /etc/dnsmasq.d/dbab-map.adblock.conf -- "$@" dpkg-maintscript-helper rm_conffile /etc/dnsmasq.d/dbab-map.trashsites.conf -- "$@" # End automatically added section However, after I remove the package, the last two files, /etc/dnsmasq.d/dbab-map.adblock.conf & /etc/dnsmasq.d/dbab-map.trashsites.conf, still remains and are left behind, while the first one was indeed gone. What was the problem? How can I fix it? thx!
Re: Question on rm_conffile
> On Mon, Feb 22, 2021 at 12:33 AM Tong Sun wrote: > > > Can I use rm_conffile to remove a (conffile) directory? > > > > I checked the man page but am still not too sure about that. I am still not too sure about the above yet.
Re: Question on rm_conffile
On Mon, Feb 22, 2021 at 8:45 AM Sebastiaan Couwenberg - sebas...@xs4all.nl wrote: > > On 2/22/21 2:23 PM, Tong Sun wrote: > > However, when I did some research, I found that most packages put > > rm_conffile in the .maintscript file. Where does that come from? It > > is even not in the man page. OK that I put rm_conffile in the > > .maintscript file as well, instead of in all 3 scripts (preinst, > > postinst, postrm)? > > dpkg-maintscript-helper(1) refers to dh_installdeb(1) which documents > the .maintscript files, see: > > https://manpages.debian.org/buster/dpkg/dpkg-maintscript-helper.1.en.html > https://manpages.debian.org/buster/debhelper/dh_installdeb.1.en.html Got it. Thanks A follow up question, dpkg-maintscript-helper(1) suggests to use Pre-Depends: dpkg (>= 1.17.14) But of the several packages that use rm_conffile that I checked, none of them is using `Pre-Depends: dpkg (>= 1.17.14)` in their control file. Was I not looking at the correct place or there is something else (e.g., it's pretty safe not to do that nowadays)?
Question on rm_conffile
On Mon, Feb 22, 2021 at 12:33 AM Tong Sun wrote: > Can I use rm_conffile to remove a (conffile) directory? > > I checked the man page but am still not too sure about that. Moreover, in The right way to remove an obsolete conffile in a Debian package https://raphaelhertzog.com/2010/10/07/the-right-way-to-remove-an-obsolete-conffile-in-a-debian-package/ it says to put rm_conffile in the 3 relevant scripts (preinst, postinst, postrm) However, when I did some research, I found that most packages put rm_conffile in the .maintscript file. Where does that come from? It is even not in the man page. OK that I put rm_conffile in the .maintscript file as well, instead of in all 3 scripts (preinst, postinst, postrm)?
rm_conffile and conffile directory
Hi, Can I use rm_conffile to remove a (conffile) directory? I checked the man page but am still not too sure about that. thx
Controlling the init system for my package
Hi, How to enable the daemon from my package to be started when machine boot? I used to use SysV & update-rc.d, however, As per https://wiki.debian.org/systemd | systemd is a system and service manager for Linux. It is the default init system for Debian since Debian Jessie. Systemd is compatible with SysV and LSB init scripts. It can work as a drop-in replacement for sysvinit. And as per https://www.digitalocean.com/community/tutorials/how-to-use-systemctl-to-manage-systemd-services-and-units | systemctl command, ... is the central management tool for controlling the init system. and also as I've got warnings like postrm-contains-additional-updaterc.d-calls So I changed my post install/rm from using update-rc.d to use systemctl instead. Now I've just learned that systemctl should not be inside the post install/rm scripts. Thus, What's the correct way to install/enable/remove the daemon from my package inside the post install/rm scripts? Thanks!
Re: Howto re-upload to debian-mentors
IIRC, you can upload with the same version # over and over to debian-mentors, without bumping version #. The overwriting is done automatically.
package-supports-alternative-init-but-no-init.d-script, how to fix
Hi, For I: package-supports-alternative-init-but-no-init.d-script N: N: The package provides daemon, but contains no init.d script Packages N: that provide services (daemons), like cron daemon or web servers, must N: provide init.d script for starting that services with sysvinit. N: Optionally, packages can also provide integration with alternative N: init systems. N: N: Package in question provides integration with some alternative init N: system, but corresponding init.d script is absent. I have already provided it as per init-d-script(5), see https://github.com/suntong/dbab/blob/35a6193d7ae0cc785a9c6cf9135476dca21c102d/bin/dbab and my Makefile is installing it: https://github.com/suntong/dbab/blob/master/Makefile#L38 https://github.com/suntong/dbab/blob/35a6193d7ae0cc785a9c6cf9135476dca21c102d/Makefile#L38 What I'm missing? (I checked the built binary.deb and the /etc/init.d file is not there) Thanks
Re: init.d-script-does-not-source-init-functions, is it really necessary
Thanks for helping Paul.
On Sat, Feb 6, 2021 at 10:30 PM Paul Wise wrote:
>
> On Sat, Feb 6, 2021 at 9:31 PM Tong Sun wrote:
>
> > However, sourcing /lib/init/init-d-script will break in some cases,
> > because of which, I had a bug opened against my package.
>
> Please link to the bug report.
The bug report is at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958899
Basically I was trying to start/stop a Perl based http server.
> I suggest deleting your existing init script and instead using the
> example from the init-d-script(5) manual page.
I do have one that almost like that,
https://github.com/suntong/dbab/blob/master/bin/dbab
but somehow codes were added when I found cases when things didn't work.
So you are saying something as simple as
#!/usr/bin/env /lib/init/init-d-script
### BEGIN INIT INFO
# Provides: dbab
# Required-Start:$syslog $time $remote_fs
# Required-Stop: $syslog $time $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: run at jobs
# Description: Debian init script to start the daemon
#running at jobs.
### END INIT INFO
DAEMON=/usr/sbin/dbab-svr
without anything else would be good enough?
> > > Letting dh_installinit put code into postinst etc has done the right
> > > thing for me in a package of my own
> >
> > But I'm having a hard time making some senses out of that short sentence.
>
> I think that is referring to the situation where you already have an
> init script and dh_installinit from debhelper takes care of running
> the init script from the postinst when you install the package.
I guess this part can also be taken care of by it, right?
I need to try it out, using this one-line simplest perl http server:
perl -MIO::All -e 'io(":8080")->fork->accept->(sub { $_[0] < io(-x $1
? "./$1 |" : $1) if /^GET \/(.*) / })'
and also, I want to know,
- I need to find a way to debug without doing the package
packaging/installation. I.e., I need to find a way that works, then do
the packaging, instead of the other way around.
- what's the best way to try it out? would `/usr/bin/install -c
my-init-d-script /etc/init.d` under docker works? Testing such
system-bootup cases/scripts had always been a headache for me as I
don't know what is the easiest way.
- where do I find other names for the "Required-Start"/"Required-Stop"
section? I guess that I also need to put more in for my case, network
needs to be started beforehand for example...
thanks again
init.d-script-does-not-source-init-functions, is it really necessary
Hi, I have a dilemma, I have to source /lib/init/init-d-script in my init.d script, **just** to let the lint warning goes a way, for -- init.d-script-does-not-source-init-functions However, sourcing /lib/init/init-d-script will break in some cases, because of which, I had a bug opened against my package. Would it be a good idea not to source /lib/init/init-d-script, and overriding the init.d-script-does-not-source-init-functions lint warning instead? Thx
My package version is incorrect
Hi, My package version is incorrect. It is currently "1.5.01-1", which I later learned that it should be "1.5.1-1" instead. Is it so? and what should I do about it before the freeze? (there haven't been any upstream functional improvements since then) Thx
daemon start/stop for sysvinit
Hi, (Trying to squash a few bugs before the freeze) As it says in https://wiki.debian.org/Init -- > Debian packages are not required to provide sysvinit start scripts But I have a bug opened on my packages, which is packaged for systemd, that on his sysvinit based Debian, the daemon start/stop is not working. Is there a way to make both systemd and sysvinit Debian happy, for my Perl based daemon? He briefly mentioned: > Letting dh_installinit put code into postinst etc has done the right > thing for me in a package of my own But I'm having a hard time making some senses out of that short sentence. Please advise. Thanks
Upload upgraded package to ftp-master
Hi, Is there anything else I need to do after uploading my upgraded package to ftp-master? My following upgraded package has been uploaded to ftp-master a while ago, Checking signature on .dsc: ../ffcvt_1.6.0-1.dsc: Valid signature from 885FDAB331FED834 Uploading to ftp-master (via ftp to ftp.upload.debian.org):-netnsid 0 Uploading ffcvt_1.6.0-1.dsc: done. Uploading ffcvt_1.6.0.orig.tar.gz: done. Uploading ffcvt_1.6.0-1.debian.tar.xz: done.. Uploading ffcvt_1.6.0-1_source.buildinfo: done. Uploading ffcvt_1.6.0-1_source.changes: done. Successfully uploaded packages. But I haven't heard anything about it for a week now. Nor does the following tracker show any updates: https://tracker.debian.org/pkg/ffcvt please help. thx
Bug#973928: RFS: shc/4.0.3-1 - Shell script compiler
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "shc": * Package name: shc Version : 4.0.3-1 Upstream Author : https://github.com/neurobin/shc/issues * URL : https://neurobin.org/projects/softwares/unix/shc/ * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/shc Section : devel It builds those binary packages: shc - Shell script compiler To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shc/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shc/shc_4.0.3-1.dsc Changes since the last upload: shc (4.0.3-1) unstable; urgency=medium . * Merge the NMU from the NMU-master branch * detailed log ignored here. see https://mentors.debian.net/sponsors/rfs-howto/shc/ * fix package-uses-old-debhelper-compat-version 12 * fix "source: out-of-date-standards-version" problem * update copyright year for packager * remove broken tests that failed since day one * fix nmu-in-changelog * fix trailing-whitespace in debian/changelog Regards,
Re: hardening=+all caused CPPFLAGS missing (-D_FORTIFY_SOURCE=2)
On Thu, Nov 5, 2020 at 10:52 AM Carlos Henrique Lima Melara wrote: > > Hi, > > On Thu, Nov 05, 2020 at 08:49:33AM -0500, Tong Sun wrote: > > On Thu, Nov 5, 2020 at 8:21 AM Andrey Rahmatullin wrote: > > > > > > On Thu, Nov 05, 2020 at 08:08:17AM -0500, Tong Sun wrote: > > > > > > I used > > > > > > > > > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > > > > > > > > > to fix the hardening issue, but it yields the following error from > > > > > > blhc: > > > > > > > > > > > > CPPFLAGS missing (-D_FORTIFY_SOURCE=2) > > > > > > > > > > > > See https://salsa.debian.org/debian/shc/-/jobs/1126952 > > > > > > > > > > > > I've tried some "solutions" that I found from the internet but > > > > > > nothing worked. > > > > > > > > > > > > Anyone know how to fix this please? > > > > > Remove "export CPPFLAGS = " from debian/rules. > > > > > > > > That was actually my "fix" -- There wasn't such a line and I got > > > > `CPPFLAGS missing (-D_FORTIFY_SOURCE=2)` in the first place. > > > And this "fix" removed -D_FORTIFY_SOURCE=2 from the main compilation > > > command as you can see if you compare the build logs, so removing it fixes > > > the actual problem. > > > > removing it yields > > https://salsa.debian.org/debian/shc/-/jobs/1138279 > > the same as where it all begins -- > > https://salsa.debian.org/debian/shc/-/jobs/1126858 > > So, looking at the build log after you removed the export from d/rules [1] > seens to build with -D_FORTIFY_SOURCE=2 (look at line 1223). > > [1] https://salsa.debian.org/debian/shc/-/jobs/1138271 > > > > > Anything else I can do? > > > If blhc complains even without this line, I suspect it captures the > > > comnpilation lines from the tests, in which case you can either ignore > > > that or change the test commands. Always read the build log manually > > > before trying to fix blhc output. > > This may be what's happening. So I just ignore it, without trying to fix blhc?
Re: hardening=+all caused CPPFLAGS missing (-D_FORTIFY_SOURCE=2)
On Thu, Nov 5, 2020 at 8:21 AM Andrey Rahmatullin wrote: > > On Thu, Nov 05, 2020 at 08:08:17AM -0500, Tong Sun wrote: > > > > I used > > > > > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > > > > > to fix the hardening issue, but it yields the following error from blhc: > > > > > > > > CPPFLAGS missing (-D_FORTIFY_SOURCE=2) > > > > > > > > See https://salsa.debian.org/debian/shc/-/jobs/1126952 > > > > > > > > I've tried some "solutions" that I found from the internet but nothing > > > > worked. > > > > > > > > Anyone know how to fix this please? > > > Remove "export CPPFLAGS = " from debian/rules. > > > > That was actually my "fix" -- There wasn't such a line and I got > > `CPPFLAGS missing (-D_FORTIFY_SOURCE=2)` in the first place. > And this "fix" removed -D_FORTIFY_SOURCE=2 from the main compilation > command as you can see if you compare the build logs, so removing it fixes > the actual problem. removing it yields https://salsa.debian.org/debian/shc/-/jobs/1138279 the same as where it all begins -- https://salsa.debian.org/debian/shc/-/jobs/1126858 > > Anything else I can do? > If blhc complains even without this line, I suspect it captures the > comnpilation lines from the tests, in which case you can either ignore > that or change the test commands. Always read the build log manually > before trying to fix blhc output. Yeah for sure, I tried, but the blhc output is just beyond me. My "fix" was my guess out of blhc output how to fix it.
Re: hardening=+all caused CPPFLAGS missing (-D_FORTIFY_SOURCE=2)
On Thu, Nov 5, 2020 at 4:38 AM Andrey Rahmatullin - w...@debian.org wrote: > > On Wed, Nov 04, 2020 at 10:28:04PM -0500, Tong Sun wrote: > > Hi, > > > > I used > > > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > > > > to fix the hardening issue, but it yields the following error from blhc: > > > > CPPFLAGS missing (-D_FORTIFY_SOURCE=2) > > > > See https://salsa.debian.org/debian/shc/-/jobs/1126952 > > > > I've tried some "solutions" that I found from the internet but nothing > > worked. > > > > Anyone know how to fix this please? > Remove "export CPPFLAGS = " from debian/rules. That was actually my "fix" -- There wasn't such a line and I got `CPPFLAGS missing (-D_FORTIFY_SOURCE=2)` in the first place. Anything else I can do?
hardening=+all caused CPPFLAGS missing (-D_FORTIFY_SOURCE=2)
Hi, I used export DEB_BUILD_MAINT_OPTIONS = hardening=+all to fix the hardening issue, but it yields the following error from blhc: CPPFLAGS missing (-D_FORTIFY_SOURCE=2) See https://salsa.debian.org/debian/shc/-/jobs/1126952 I've tried some "solutions" that I found from the internet but nothing worked. Anyone know how to fix this please?
Re: Verify the library transition
On Wed, Oct 28, 2020 at 3:47 AM Andrey Rahmatullin wrote: > On Sat, Oct 17, 2020 at 3:27 PM Tong Sun > wrote: > > ... looking further into all those libgit2 related > > packages that I've already built, I saw mixed results: > > > > - > > $ dpkg-deb -f gir1.2-ggit-1.0_0.28.0.1-2_amd64.deb Depends > > gir1.2-glib-2.0, libgit2-glib-1.0-0 (>= 0.28.0.1) > > > > $ dpkg-deb -f golang-gopkg-libgit2-git2go.v28-dev_0.28.5-1_all.deb Depends > > pkg-config, libgit2-dev (>> 0.28~) > > > > $ dpkg-deb -f libgit2-glib-1.0-0-dbgsym_0.28.0.1-2_amd64.deb Depends > > libgit2-glib-1.0-0 (= 0.28.0.1-2) > > > > $ dpkg-deb -f libgit2-glib-1.0-0_0.28.0.1-2_amd64.deb Depends > > libc6 (>= 2.14), libgit2-28 (>= 0.28.1), libglib2.0-0 (>= 2.44.0) > > > > $ dpkg-deb -f libgit2-glib-1.0-dev_0.28.0.1-2_amd64.deb Depends > > gir1.2-ggit-1.0 (= 0.28.0.1-2), libgit2-glib-1.0-0 (= 0.28.0.1-2), > > libgit2-dev (>= 0.26.0), libglib2.0-dev (>= 2.44.0) > > > > $ dpkg-deb -f librust-libgit2-sys+https-dev_0.10.0-1_amd64.deb Depends > > librust-libgit2-sys-dev (= 0.10.0-1), librust-openssl-sys-0.9+default-dev > > > > $ dpkg-deb -f librust-libgit2-sys+libssh2-sys-dev_0.10.0-1_amd64.deb Depends > > librust-libgit2-sys-dev (= 0.10.0-1), > > librust-libssh2-sys-0.2+default-dev (>= 0.2.11-~~) > > > > $ dpkg-deb -f librust-libgit2-sys-dev_0.10.0-1_amd64.deb Depends > > librust-cc-1+default-dev (>= 1.0.42-~~), librust-cc-1+parallel-dev (>= > > 1.0.42-~~), librust-libc-0.2+default-dev, > > librust-libz-sys-1+default-dev (>= 1.0.22-~~), > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~), libgit2-dev > > - > > > > I.e., > > > > - some of them about built with libgit2-glib-1.0-0 > > - but some others are built with libgit2-28 (>= 0.28.1) > > - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) > > > > I.e., I still haven't figured out how to control the lib a package > > should links to. > (it installed the -dev package from sid because you didn't add a version > constraint to require the version from experimental) Ok, to add a version constraint, is it OK that I use the following to replace all libgit2 dependents from above, to make sure they require the version from experimental (v1.0.0)? libgit2-dev (>> 0.99) > > PS, here are all libgit2 related packages installed in my system, and > > their versions: > > > > libgit2-1.0:amd64_1.0.0+dfsg.1-1 > > libgit2-28:amd64_0.28.5+dfsg.1-1 > > libgit2-build-deps_1.0.0+dfsg.1-1 > > libgit2-dev:amd64_0.28.5+dfsg.1-1 > > libgit2-glib-1.0-0:amd64_0.28.0.1-2 > > libgit2-glib-1.0-dev:amd64_0.28.0.1-2 Moverover, give my specific case, - single lib upgrade, and - I've already installed the latest libgit2-1.0 into my sid would it matter any more if I build in my sid host? I know building with sbuild + experimental build-dep is ideal, but I can't think of any reason why I can't do build in my sid host now, if I am to update the dependent version constraints to all that package I'm building. thanks
Re: Verify the library transition
> > I'm currently helping with the library transition for libgit2-dev. > Then I would expect you to ask the maintainers for coordination and/or > help. The maintainer normally actively participates in the discussion here, and gives people help, but he is super busy at the moment, so I just want to go as furthest as possible without waiting on him. Moreover, the discussions so far are only on the library transition building general information, and has not much to do with his specific package. I.e., the discussions will be helpful to the next library transition building volunteers. > > > But I'd only been using sbuild to build sid packages previously, where > > > can I find the doc on how to add an experimental build-dep to sbuild's > > > build process? > > https://wiki.debian.org/sbuild#Enabling_experimental > > Greate. Thanks for all your helps! So I build with experimental build-dep via: sbuild -s -v -A --no-clean-source -d unstable --extra-repository='deb http://deb.debian.org/debian experimental main' --build-dep-resolver=aspcud gnuastro and when I check my results, I got: $ dpkg-deb -f libgnuastro11_0.13-1_amd64.deb Depends libc6 (>= 2.29), libcfitsio9 (>= 3.480~), libgit2-28 (>= 0.26.0), libgsl25 (>= 2.6), libjpeg62-turbo (>= 1.3.1), libtiff5 (>= 4.0.3), libwcs7 (>= 5.0) Although the build passed, I'm still not sure if it passed for the new libgit2-glib-1.0-0, or if it passed for the old libgit2-28 (>= 0.28.1). Looks to me it is the latter. So now I have to come back to the old question > > - some of them about built with libgit2-glib-1.0-0 > > - but some others are built with libgit2-28 (>= 0.28.1) > > - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) > > > > I.e., I still haven't figured out how to control the lib a package > > should links to. > You don't need to "control" it. The build process uses the files from the > -dev package and usually there is only on version of that installed. So I'm not controlling it and let the build process choose on its own. Now, with the above result, can I safely say that libgnuastro11_0.13-1_amd64.deb is safe to build with the new libgit2? PS, the whole build log is at https://pastebin.com/YM9jV7g5 thanks
sbuild chroot cleanup failed
Hi, I'm following https://wiki.debian.org/sbuild#Apt_package_caching to setup new schroot with eatmydata & ccache, but got "chroot cleanup failed" afterwards. Here is what I did: sudo rm -r /srv/chroot/unstable-amd64-sbuild/ sudo rm /etc/schroot/chroot.d/unstable-amd64-sbuild-* /etc/sbuild/chroot/unstable-amd64-sbuild sudo sbuild-createchroot --include=eatmydata,ccache,gnupg unstable /srv/chroot/unstable-amd64-sbuild http://127.0.0.1:3142/deb.debian.org/debian AOK so far, but when I tried to do sudo sbuild-shell source:unstable-$arch-sbuild then quit without doing anything, I'll get: E: 10mount: E: Failed to open mount file â/proc/mountsâ: No such file or directory E: unstable-amd64-sbuild-d8cd8187-9a0a-47b0-ba1b-e0f0f5668e75: Chroot setup failed: stage=setup-stop Chroot cleanup failed Tried twice (from a clean Debian sid environment), and twice got the exact same error. What is the problem and what should I do? Thx!
Re: Verify the library transition
On Fri, Oct 23, 2020 at 2:27 PM Andrey Rahmatullin wrote: > > On Fri, Oct 23, 2020 at 01:19:04PM -0400, Tong Sun wrote: > > I'm currently helping with the library transition for libgit2-dev. > Then I would expect you to ask the maintainers for coordination and/or > help. > > > This is the first time I'm doing the library transition so I'm > > following the library transition steps on the Debian wiki, i.e. doing > > exactly as what the wiki tells me to do, or at least what I understand > > from it, instead of inventing steps on my own. So far I've tried to > > build a few packages that depend on it, like calligra. > Do you mean https://wiki.debian.org/Teams/ReleaseTeam/Transitions ? "Test > rebuild reverse dependencies" is not verbose enough to "do exactly as what > the wiki tells me to do". "or at least what I understand from it". That's exactly the problem. It is not verbose enough so I had to make a guess, and apparently my guess was wrong. > > But I'd only been using sbuild to build sid packages previously, where > > can I find the doc on how to add an experimental build-dep to sbuild's > > build process? > https://wiki.debian.org/sbuild#Enabling_experimental Greate. Thanks for all your helps!
Re: Verify the library transition
On Fri, Oct 23, 2020 at 1:05 PM Andrey Rahmatullin wrote: > > On Fri, Oct 23, 2020 at 12:25:19PM -0400, Tong Sun wrote: > > > > > > PS, here are all libgit2 related packages installed in my system, > > > > > > and > > > > > > their versions: > > > > > > > > > > > > libgit2-1.0:amd64_1.0.0+dfsg.1-1 > > > > > > libgit2-28:amd64_0.28.5+dfsg.1-1 > > > > > > libgit2-build-deps_1.0.0+dfsg.1-1 > > > > > > libgit2-dev:amd64_0.28.5+dfsg.1-1 > > > > > > libgit2-glib-1.0-0:amd64_0.28.0.1-2 > > > > > > libgit2-glib-1.0-dev:amd64_0.28.0.1-2 > > > > > So you installed packages from sid and built against them. > > > > > > > This cannot test packages from experimental. > > > > but I have to, right? > I don't know, are you the maintainer of either of involved packages? I'm currently helping with the library transition for libgit2-dev. https://packages.debian.org/experimental/libgit2-dev as I explained first in my OP. > > > > So, overall, the problem was that I was testing packages from > > > > experimental in sid, while what I should do is test them in > > > > experimental instead, right? > > > No, you didn't test any packages from experimental. You have packages from > > > sid installed and you build on the host system, so there is no way to test > > > anything else, unless you described your workflow incorrectly. > > > > The problem is I don't have a workflow. > Well, you did something, that's what I've meant. > By the way, explaining *what* exactly did you do in the initial email > would be very helpful to people trying to answer your questions. I'm currently helping with the library transition for libgit2-dev. This is the first time I'm doing the library transition so I'm following the library transition steps on the Debian wiki, i.e. doing exactly as what the wiki tells me to do, or at least what I understand from it, instead of inventing steps on my own. So far I've tried to build a few packages that depend on it, like calligra. > > This is the first time I'm > > doing the library transition, and so far all my attempts are failing. > > So maybe instead of me describing my incorrect workflow, would be OK > > for you to lay out what exactly I should be doing? > That depends on what you want to do. > If you want to check that some package builds against some package from > experimental, you need to actually build it against it. How exactly to do > that, again, depends on the workflow used. If you prefer building in the > host system you need to install the experimental packages into it, but > it's always recommended to use sbuild or pbuilder to build packages, both > of them have means to add an experimental build-dep to the build process. > > > All in all, I must test packages from experimental, any you seems to > > suggest it is impossible -- "there is no way to test anything else", > > "This cannot test packages from experimental". > No, it' just impossible to test a package on the host system without > actually installing it there, which you were apparently trying to do. Oh, thanks for the clarification, I'll use sbuild to rebuild my packages then. But I'd only been using sbuild to build sid packages previously, where can I find the doc on how to add an experimental build-dep to sbuild's build process? Thanks
Re: Verify the library transition
On Fri, Oct 23, 2020 at 12:08 PM Andrey Rahmatullin wrote: > > On Fri, Oct 23, 2020 at 11:58:03AM -0400, Tong Sun wrote: > > On Fri, Oct 23, 2020 at 11:50 AM Andrey Rahmatullin wrote: > > > > > > On Sat, Oct 17, 2020 at 03:27:40PM -0400, Tong Sun wrote: > > > [skipped as already answered in private] > > > > Strange, I didn't get anything in private (that's why I'm bumping it), > It was on Oct 17 as an answer to the email sent to my personal address. Yep, that was the one that I didn't get. Searched again. > > Would you resend that part please? > The only relevant part there is "Which version will be picked depends on > the versions available in the repos that are enabled during the build > process, and on the resolver used." (and a suggestion to not reply > off-list). I didn't mean to, and when I realized the problem I re-sent to this list again, with a bit more information. > > > > PS, here are all libgit2 related packages installed in my system, and > > > > their versions: > > > > > > > > libgit2-1.0:amd64_1.0.0+dfsg.1-1 > > > > libgit2-28:amd64_0.28.5+dfsg.1-1 > > > > libgit2-build-deps_1.0.0+dfsg.1-1 > > > > libgit2-dev:amd64_0.28.5+dfsg.1-1 > > > > libgit2-glib-1.0-0:amd64_0.28.0.1-2 > > > > libgit2-glib-1.0-dev:amd64_0.28.0.1-2 > > > So you installed packages from sid and built against them. > > > This cannot test packages from experimental. but I have to, right? > > So, overall, the problem was that I was testing packages from > > experimental in sid, while what I should do is test them in > > experimental instead, right? > No, you didn't test any packages from experimental. You have packages from > sid installed and you build on the host system, so there is no way to test > anything else, unless you described your workflow incorrectly. The problem is I don't have a workflow. This is the first time I'm doing the library transition, and so far all my attempts are failing. So maybe instead of me describing my incorrect workflow, would be OK for you to lay out what exactly I should be doing? All in all, I must test packages from experimental, any you seems to suggest it is impossible -- "there is no way to test anything else", "This cannot test packages from experimental". What's the correct approach? Thx!
Re: Verify the library transition
On Fri, Oct 23, 2020 at 11:50 AM Andrey Rahmatullin wrote: > > On Sat, Oct 17, 2020 at 03:27:40PM -0400, Tong Sun wrote: > [skipped as already answered in private] Strange, I didn't get anything in private (that's why I'm bumping it), just searched everywhere again just now and got nothing. Would you resend that part please? > > One reason I can think of is that, my latest libgit2 is called > > libgit2-1.0 while the *old* one is called libgit2-28, which is in fact > > libgit2 v0.28.5+dfsg.1-1. Which one would debuild pick? > debuild doesn't pick anything as it doesn't install build-deps. > > > - some of them about built with libgit2-glib-1.0-0 > > - but some others are built with libgit2-28 (>= 0.28.1) > > - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) > No inconsistency here. > > > I.e., I still haven't figured out how to control the lib a package > > should links to. > You don't need to "control" it. The build process uses the files from the > -dev package and usually there is only on version of that installed. > > > PS, here are all libgit2 related packages installed in my system, and > > their versions: > > > > libgit2-1.0:amd64_1.0.0+dfsg.1-1 > > libgit2-28:amd64_0.28.5+dfsg.1-1 > > libgit2-build-deps_1.0.0+dfsg.1-1 > > libgit2-dev:amd64_0.28.5+dfsg.1-1 > > libgit2-glib-1.0-0:amd64_0.28.0.1-2 > > libgit2-glib-1.0-dev:amd64_0.28.0.1-2 > So you installed packages from sid and built against them. This cannot > test packages from experimental. So, overall, the problem was that I was testing packages from experimental in sid, while what I should do is test them in experimental instead, right? Thanks I'll give it a try tonight.
Fwd: Verify the library transition
Bump. Hoping to get a response so that I can make another attempt this week. Thanks -- Forwarded message - Date: Sat, Oct 17, 2020 at 3:27 PM Subject: Re: Verify the library transition To: Debian Mentors List On Tue, Sep 29, 2020 at 8:39 AM Andrey Rahmatullin wrote: > On Tue, Sep 29, 2020 at 08:30:33AM -0400, Tong Sun wrote: > > So `libgit2-dev` only shows up once in calligra's debian/control file. > You need to check actual dependencies of binary packages (e.g. by looking at > debs with dpkg-deb -f), not your debian/control. > And libgit2-dev is a development package, binaries will depend on the > package that contains the library itself. OK. I got: $ dpkg-deb -f calligrawords_3.2.1+dfsg-2_amd64.deb Depends | grep libgit2 || echo not found not found > > Can I safely say that all calligra packages are fine with libgit2-dev's new > > v1.0.0? > No. With the above result, can I safely say that calligrawords_3.2.1+dfsg-2_amd64.deb is not depending on libgit2 then? I"ve checked every calligra related packages and have *only* found: $ dpkg-deb -f calligra-gemini_3.2.1+dfsg-2_amd64.deb Depends calligra-libs (= 1:3.2.1+dfsg-2), calligra-gemini-data (>= 1:3.2.1+dfsg-2), calligrasheets (>= 1:3.2.1+dfsg), calligrastage (>= 1:3.2.1+dfsg), calligrawords (>= 1:3.2.1+dfsg), libc6 (>= 2.14), libgit2-28 (>= 0.26.0), libkf5configcore5 (>= 5.7.0), libkf5configwidgets5 (>= 5.7.0), libkf5coreaddons5 (>= 5.7.0), libkf5crash5 (>= 4.96.0), libkf5i18n5 (>= 5.7.0), libkf5iconthemes5 (>= 5.7.0), libkf5widgetsaddons5 (>= 5.7.0), libkf5xmlgui5 (>= 5.7.0), libqt5core5a (>= 5.14.1), libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0), libqt5network5 (>= 5.14.1), libqt5qml5 (>= 5.0.2), libqt5quick5 (>= 5.6.1) | libqt5quick5-gles (>= 5.6.1), libqt5quickwidgets5 (>= 5.3.0), libqt5widgets5 (>= 5.3.0), libstdc++6 (>= 4.1.1) Thus, can I safely say that of all packages built out of calligra-3.2.1+dfsg, only calligra-gemini_3.2.1+dfsg-2 need to verify with library transition, and if it passes, then packages calligra-3.2.1+dfsg would pass as well? Finally, the most important one, I found that calligra-gemini_3.2.1+dfsg-2_amd64.deb was built with the old libgit2 (libgit2-28), not my latest libgit2-1.0, what was the problem for that? The d/control is not specifying a fixed version: grep libgit2 calligra-3.2.1+dfsg/debian/control libgit2-dev, So it should pick the latest version, right? Why is it not happening? One reason I can think of is that, my latest libgit2 is called libgit2-1.0 while the *old* one is called libgit2-28, which is in fact libgit2 v0.28.5+dfsg.1-1. Which one would debuild pick? Hmm... no quite, looking further into all those libgit2 related packages that I've already built, I saw mixed results: - $ dpkg-deb -f gir1.2-ggit-1.0_0.28.0.1-2_amd64.deb Depends gir1.2-glib-2.0, libgit2-glib-1.0-0 (>= 0.28.0.1) $ dpkg-deb -f golang-gopkg-libgit2-git2go.v28-dev_0.28.5-1_all.deb Depends pkg-config, libgit2-dev (>> 0.28~) $ dpkg-deb -f libgit2-glib-1.0-0-dbgsym_0.28.0.1-2_amd64.deb Depends libgit2-glib-1.0-0 (= 0.28.0.1-2) $ dpkg-deb -f libgit2-glib-1.0-0_0.28.0.1-2_amd64.deb Depends libc6 (>= 2.14), libgit2-28 (>= 0.28.1), libglib2.0-0 (>= 2.44.0) $ dpkg-deb -f libgit2-glib-1.0-dev_0.28.0.1-2_amd64.deb Depends gir1.2-ggit-1.0 (= 0.28.0.1-2), libgit2-glib-1.0-0 (= 0.28.0.1-2), libgit2-dev (>= 0.26.0), libglib2.0-dev (>= 2.44.0) $ dpkg-deb -f librust-libgit2-sys+https-dev_0.10.0-1_amd64.deb Depends librust-libgit2-sys-dev (= 0.10.0-1), librust-openssl-sys-0.9+default-dev $ dpkg-deb -f librust-libgit2-sys+libssh2-sys-dev_0.10.0-1_amd64.deb Depends librust-libgit2-sys-dev (= 0.10.0-1), librust-libssh2-sys-0.2+default-dev (>= 0.2.11-~~) $ dpkg-deb -f librust-libgit2-sys-dev_0.10.0-1_amd64.deb Depends librust-cc-1+default-dev (>= 1.0.42-~~), librust-cc-1+parallel-dev (>= 1.0.42-~~), librust-libc-0.2+default-dev, librust-libz-sys-1+default-dev (>= 1.0.22-~~), librust-pkg-config-0.3+default-dev (>= 0.3.7-~~), libgit2-dev - I.e., - some of them about built with libgit2-glib-1.0-0 - but some others are built with libgit2-28 (>= 0.28.1) - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) I.e., I still haven't figured out how to control the lib a package should links to. PS, here are all libgit2 related packages installed in my system, and their versions: libgit2-1.0:amd64_1.0.0+dfsg.1-1 libgit2-28:amd64_0.28.5+dfsg.1-1 libgit2-build-deps_1.0.0+dfsg.1-1 libgit2-dev:amd64_0.28.5+dfsg.1-1 libgit2-glib-1.0-0:amd64_0.28.0.1-2 libgit2-glib-1.0-dev:amd64_0.28.0.1-2 Please help. thanks!
Re: Verify the library transition
On Tue, Sep 29, 2020 at 8:39 AM Andrey Rahmatullin wrote: > On Tue, Sep 29, 2020 at 08:30:33AM -0400, Tong Sun wrote: > > So `libgit2-dev` only shows up once in calligra's debian/control file. > You need to check actual dependencies of binary packages (e.g. by looking at > debs with dpkg-deb -f), not your debian/control. > And libgit2-dev is a development package, binaries will depend on the > package that contains the library itself. OK. I got: $ dpkg-deb -f calligrawords_3.2.1+dfsg-2_amd64.deb Depends | grep libgit2 || echo not found not found > > Can I safely say that all calligra packages are fine with libgit2-dev's new > > v1.0.0? > No. With the above result, can I safely say that calligrawords_3.2.1+dfsg-2_amd64.deb is not depending on libgit2 then? I"ve checked every calligra related packages and have *only* found: $ dpkg-deb -f calligra-gemini_3.2.1+dfsg-2_amd64.deb Depends calligra-libs (= 1:3.2.1+dfsg-2), calligra-gemini-data (>= 1:3.2.1+dfsg-2), calligrasheets (>= 1:3.2.1+dfsg), calligrastage (>= 1:3.2.1+dfsg), calligrawords (>= 1:3.2.1+dfsg), libc6 (>= 2.14), libgit2-28 (>= 0.26.0), libkf5configcore5 (>= 5.7.0), libkf5configwidgets5 (>= 5.7.0), libkf5coreaddons5 (>= 5.7.0), libkf5crash5 (>= 4.96.0), libkf5i18n5 (>= 5.7.0), libkf5iconthemes5 (>= 5.7.0), libkf5widgetsaddons5 (>= 5.7.0), libkf5xmlgui5 (>= 5.7.0), libqt5core5a (>= 5.14.1), libqt5gui5 (>= 5.8.0) | libqt5gui5-gles (>= 5.8.0), libqt5network5 (>= 5.14.1), libqt5qml5 (>= 5.0.2), libqt5quick5 (>= 5.6.1) | libqt5quick5-gles (>= 5.6.1), libqt5quickwidgets5 (>= 5.3.0), libqt5widgets5 (>= 5.3.0), libstdc++6 (>= 4.1.1) Thus, can I safely say that of all packages built out of calligra-3.2.1+dfsg, only calligra-gemini_3.2.1+dfsg-2 need to verify with library transition, and if it passes, then packages calligra-3.2.1+dfsg would pass as well? Finally, the most important one, I found that calligra-gemini_3.2.1+dfsg-2_amd64.deb was built with the old libgit2 (libgit2-28), not my latest libgit2-1.0, what was the problem for that? The d/control is not specifying a fixed version: grep libgit2 calligra-3.2.1+dfsg/debian/control libgit2-dev, So it should pick the latest version, right? Why is it not happening? One reason I can think of is that, my latest libgit2 is called libgit2-1.0 while the *old* one is called libgit2-28, which is in fact libgit2 v0.28.5+dfsg.1-1. Which one would debuild pick? Hmm... no quite, looking further into all those libgit2 related packages that I've already built, I saw mixed results: - $ dpkg-deb -f gir1.2-ggit-1.0_0.28.0.1-2_amd64.deb Depends gir1.2-glib-2.0, libgit2-glib-1.0-0 (>= 0.28.0.1) $ dpkg-deb -f golang-gopkg-libgit2-git2go.v28-dev_0.28.5-1_all.deb Depends pkg-config, libgit2-dev (>> 0.28~) $ dpkg-deb -f libgit2-glib-1.0-0-dbgsym_0.28.0.1-2_amd64.deb Depends libgit2-glib-1.0-0 (= 0.28.0.1-2) $ dpkg-deb -f libgit2-glib-1.0-0_0.28.0.1-2_amd64.deb Depends libc6 (>= 2.14), libgit2-28 (>= 0.28.1), libglib2.0-0 (>= 2.44.0) $ dpkg-deb -f libgit2-glib-1.0-dev_0.28.0.1-2_amd64.deb Depends gir1.2-ggit-1.0 (= 0.28.0.1-2), libgit2-glib-1.0-0 (= 0.28.0.1-2), libgit2-dev (>= 0.26.0), libglib2.0-dev (>= 2.44.0) $ dpkg-deb -f librust-libgit2-sys+https-dev_0.10.0-1_amd64.deb Depends librust-libgit2-sys-dev (= 0.10.0-1), librust-openssl-sys-0.9+default-dev $ dpkg-deb -f librust-libgit2-sys+libssh2-sys-dev_0.10.0-1_amd64.deb Depends librust-libgit2-sys-dev (= 0.10.0-1), librust-libssh2-sys-0.2+default-dev (>= 0.2.11-~~) $ dpkg-deb -f librust-libgit2-sys-dev_0.10.0-1_amd64.deb Depends librust-cc-1+default-dev (>= 1.0.42-~~), librust-cc-1+parallel-dev (>= 1.0.42-~~), librust-libc-0.2+default-dev, librust-libz-sys-1+default-dev (>= 1.0.22-~~), librust-pkg-config-0.3+default-dev (>= 0.3.7-~~), libgit2-dev - I.e., - some of them about built with libgit2-glib-1.0-0 - but some others are built with libgit2-28 (>= 0.28.1) - and some I just literally don't know, e.g., libgit2-dev (>> 0.28~) I.e., I still haven't figured out how to control the lib a package should links to. PS, here are all libgit2 related packages installed in my system, and their versions: libgit2-1.0:amd64_1.0.0+dfsg.1-1 libgit2-28:amd64_0.28.5+dfsg.1-1 libgit2-build-deps_1.0.0+dfsg.1-1 libgit2-dev:amd64_0.28.5+dfsg.1-1 libgit2-glib-1.0-0:amd64_0.28.0.1-2 libgit2-glib-1.0-dev:amd64_0.28.0.1-2 Please help. thanks!
Building a few of packages
Hi, How to select only a few packages to build, out of a single source? The Calligra Suite, calligra-3.2.1+dfsg, builds 46 packages, and it took over 8 hours to build on my machine. Now I need to rebuild it, but need to rebuild only one out of the 46 packages -- calligra-gemini_3.2.1+dfsg-2_amd64.deb. What's the best way to do that? The only way I can think of is to change d/control file, comment out all other packages. But that will cause trouble to dpkg-buildpackage or gbp buildpackage, which requires me checking in those temporary changes before starting, while checking in the temporary change then revoke it later is something that I want to avoid. Please help. Thanks
Re: New comment on package microsocks
On Wed, Oct 7, 2020 at 5:42 AM mentors.debian.net wrote: > A comment has been posted to a package you uploaded: > > From: Gürkan Myczko > Package: microsocks > Url: https://mentors.debian.net/package/microsocks/ > > --- > Nice: > https://metadata.ftp-master.debian.org/changelogs//main/m/microsocks/microsocks_1.0.1-1_changelog > > Not sure why it's still here... maybe because it went to experimental only? Yes, I took a look and indeed it went to experimental only. Hmm... I'm not sure about the procedures involved, why it is all happening etc. But, I can dput it to ftp-master directly now after RFS, Is there anything I can do to rectify the situation, like dput the same version to ftp-master again? Thanks,
Re: Verify the library transition
On Tue, Sep 29, 2020 at 9:59 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 09:41:58AM -0400, Tong Sun wrote: > > On Tue, Sep 29, 2020 at 9:19 AM Andrey Rahmatullin wrote: > > > > > > On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and > > > > > > I see > > > > > > > > > > > > $ grep -B10 libgit2-dev debian/control > > > > > > Build-Depends: debhelper (>= 11), > > > > > > dh-cargo (>= 18), > > > > > > cargo:native , > > > > > > rustc:native , > > > > > > libstd-rust-dev , > > > > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > > > > librust-libc-0.2+default-dev , > > > > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > > > > libgit2-dev > > > > > What do you mean by this? > > > > > > > > Same train of thoughts as above. Is there anything special that you > > > > picked this particular section out? > > > I didn't? > > > I just don't know how is this related to everything else. > > > > Oh, I was just using the same command as previously, and want to be > > true to the fact and don't want to edit/remove anything, which shows > > that this time libgit2-dev showed up twice. > Where is it shown twice? In OP, which you didn't include. That is why I was wondering if there is anything special that you picked this particular section out, because this is not the part I had the question, but only remained as a reference.
Re: Verify the library transition
On Tue, Sep 29, 2020 at 9:19 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 09:15:41AM -0400, Tong Sun wrote: > > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > > > > > > > $ grep -B10 libgit2-dev debian/control > > > > Build-Depends: debhelper (>= 11), > > > > dh-cargo (>= 18), > > > > cargo:native , > > > > rustc:native , > > > > libstd-rust-dev , > > > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > > > librust-libc-0.2+default-dev , > > > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > > > libgit2-dev > > > What do you mean by this? > > > > Same train of thoughts as above. Is there anything special that you > > picked this particular section out? > I didn't? > I just don't know how is this related to everything else. Oh, I was just using the same command as previously, and want to be true to the fact and don't want to edit/remove anything, which shows that this time libgit2-dev showed up twice. Thanks for your help Andrey, I'll get back for the rest to you tonight...
Re: Verify the library transition
Thanks Andrey. On Tue, Sep 29, 2020 at 8:39 AM Andrey Rahmatullin wrote: > > On Tue, Sep 29, 2020 at 08:30:33AM -0400, Tong Sun wrote: > > So `libgit2-dev` only shows up once in calligra's debian/control file. > You need to check actual dependencies of binary packages (e.g. by looking at > debs with dpkg-deb -f), not your debian/control. > And libgit2-dev is a development package, binaries will depend on the > package that contains the library itself. > > > I.e., none of the packages actually depends on it, which is kind of > > what I found. Is it true? > Yes, packages that link against a lib shouldn't depend on a -dev. No, you > cannot see binary package deps in debian/control. > > > Can I safely say that all calligra packages are fine with libgit2-dev's new > > v1.0.0? > No. > > > Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see > > > > $ grep -B10 libgit2-dev debian/control > > Build-Depends: debhelper (>= 11), > > dh-cargo (>= 18), > > cargo:native , > > rustc:native , > > libstd-rust-dev , > > librust-cc-1+default-dev (>= 1.0.42-~~) , > > librust-cc-1+parallel-dev (>= 1.0.42-~~) , > > librust-libc-0.2+default-dev , > > librust-libz-sys-1+default-dev (>= 1.0.22-~~) , > > librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) , > > libgit2-dev > What do you mean by this? Same train of thoughts as above. Is there anything special that you picked this particular section out?
Re: Verify the library transition
On Tue, Sep 29, 2020 at 3:14 AM Andrey Rahmatullin wrote:
>
> On Mon, Sep 28, 2020 at 09:55:17PM -0400, Tong Sun wrote:
> > Of all the above 46 newly built binary-only packages, how can I tell
> > which .so from them will link to libgit2-dev, and whether the
> > libgit2-dev version linked is truly v1.0.0? Note this is more a
> > generic question and not specific for calligra.
> Check the package dependencies.
OK.
$ grep -B20 libgit2-dev debian/control
Source: calligra
Section: kde
Priority: optional
Maintainer: Debian Qt/KDE Maintainers
Uploaders: Adrien Grellier ,
Raúl Sánchez Siles ,
Maximiliano Curia
Build-Depends: cmake,
debhelper-compat (= 12),
extra-cmake-modules (>= 5.19.0),
gettext,
kross-dev (>= 5.7.0),
libboost-dev,
libboost-system-dev,
libeigen3-dev,
libetonyek-dev,
libfontconfig-dev,
libfreetype-dev,
libgit2-dev,
So `libgit2-dev` only shows up once in calligra's debian/control file.
I.e., none of the packages actually depends on it, which is kind of
what I found. Is it true? Can I safely say that all calligra packages
are fine with libgit2-dev's new v1.0.0?
Also, one dependent of libgit2-dev is librust-libgit2-sys-dev. and I see
$ grep -B10 libgit2-dev debian/control
Build-Depends: debhelper (>= 11),
dh-cargo (>= 18),
cargo:native ,
rustc:native ,
libstd-rust-dev ,
librust-cc-1+default-dev (>= 1.0.42-~~) ,
librust-cc-1+parallel-dev (>= 1.0.42-~~) ,
librust-libc-0.2+default-dev ,
librust-libz-sys-1+default-dev (>= 1.0.22-~~) ,
librust-pkg-config-0.3+default-dev (>= 0.3.7-~~) ,
libgit2-dev
--
Package: librust-libgit2-sys-dev
Architecture: any
Multi-Arch: same
Depends:
${misc:Depends},
librust-cc-1+default-dev (>= 1.0.42-~~),
librust-cc-1+parallel-dev (>= 1.0.42-~~),
librust-libc-0.2+default-dev,
librust-libz-sys-1+default-dev (>= 1.0.22-~~),
librust-pkg-config-0.3+default-dev (>= 0.3.7-~~),
libgit2-dev
I.e., the package that actually depends on libgit2-dev is
librust-libgit2-sys-dev. However, when I check the build results under
.../libgit2-dev/dep/rust-libgit2-sys-0.10.0/debian/librust-libgit2-sys-dev:
$ find usr/
usr/
usr/share
usr/share/cargo
usr/share/cargo/registry
usr/share/cargo/registry/libgit2-sys-0.10.0
usr/share/cargo/registry/libgit2-sys-0.10.0/Cargo.toml
usr/share/cargo/registry/libgit2-sys-0.10.0/LICENSE-MIT
usr/share/cargo/registry/libgit2-sys-0.10.0/lib.rs
usr/share/cargo/registry/libgit2-sys-0.10.0/build.rs
usr/share/cargo/registry/libgit2-sys-0.10.0/.cargo_vcs_info.json
usr/share/cargo/registry/libgit2-sys-0.10.0/debian
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/abi-compat-0.28.3.patch
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/series
usr/share/cargo/registry/libgit2-sys-0.10.0/debian/patches/no-special-snowflake-env.patch
usr/share/cargo/registry/libgit2-sys-0.10.0/.cargo-checksum.json
usr/share/cargo/registry/libgit2-sys-0.10.0/LICENSE-APACHE
usr/share/doc
usr/share/doc/librust-libgit2-sys-dev
usr/share/doc/librust-libgit2-sys-dev/copyright
usr/share/doc/librust-libgit2-sys-dev/changelog.Debian.gz
I don't see any library built. So can I also safely say that it is
fine with libgit2-dev's new v1.0.0 as well?
thx
Verify the library transition
I'm currently helping with the library transition for libgit2-dev. https://packages.debian.org/experimental/libgit2-dev After hours and hours building, I've just successfully built calligra. The last few lines of build log are: - [ 39%] Building CXX object plugins/dockers/CMakeFiles/calligra_docker_defaults.dir/shapeproperties/ShapePropertiesDocker.cpp.o cd /sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/plugins/dockers && /usr/bin/c++ -DBOOST_ALL_NO_LIB -DHAVE_X11 -DKCOREADDONS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DISABLE_DEPRECATED_BEFORE=0 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_SIGNALS_SLOTS_KEYWORDS -DQT_NO_URL_CAST_FROM_STRING -DQT_PRINTSUPPORT_LIB -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DSHOULD_BUILD_FONT_CONVERSION -DTRANSLATION_DOMAIN=\"calligra-dockers\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -Dcalligra_docker_defaults_EXPORTS -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/plugins/dockers -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/plugins/dockers -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/plugins/dockers/calligra_docker_defaults_autogen/include -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/interfaces -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/version -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/version -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/flake -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/odf -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/store -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/odf -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/store -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/plugin -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/pigment -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/pigment -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/pigment/compositeops -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/pigment/resources -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/kundo2 -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/kundo2 -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/widgetutils -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/flake/commands -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/flake/tools -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/flake/svg -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/flake -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/text -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/text -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/text/changetracker -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/text/styles -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/text/opendocument -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu/libs/widgetutils -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/libs/widgets -I/sysvol/bld/pkg/libgit2-dev/dep/calligra-3.2.1+dfsg/obj-x86_64-linux-gnu dpkg-genchanges --build=binary >../calligra_3.2.1+dfsg-2_amd64.changes dpkg-genchanges: info: binary-only upload (no source code included) dpkg-source -i --after-build . dpkg-buildpackage: info: binary-only upload (no source included) Now running lintian calligra_3.2.1+dfsg-2_amd64.changes ... W: calligra-data: desktop-command-not-in-package usr/share/applications/calligra.desktop khelpcenter W: calligra-gemini: no-manual-page usr/bin/calligragemini W: calligra-gemini: no-manual-page usr/bin/calligrageminithumbnailhelper W: calligra-libs: no-manual-page usr/bin/calligra W: calligra-libs: no-manual-page usr/bin/calligraconverter W: calligrasheets: no-manual-page usr/bin/calligrasheets W: calligrastage: no-manual-page usr/bin/calligrastage W: calligrawords: no-manual-page usr/bin/calligrawords W: karbon: no-manual-page usr/bin/karbon N: 76 tags overridden (35 warnings, 41 info) Finished running lintian. - Normally, when it builds with the new libgit2-dev, v1.0.0, as in https://packages.debian.org/experimental/libgit2-dev, I can say it's fine, so I can just move on to the next. However, this is the first time I'm trying to do library transition build, I.e., to build something based on lib from experimental, I want to verify it indeed builds fine. Now the problem is, - ls ../calligra*.deb | wc -l 46 - Of all the above
Re: build-rdeps: character 0-1: RFC 822 error
On Sat, Sep 26, 2020 at 7:32 AM Geert Stappers wrote: . . . > > Found a total of 26 reverse build-depend(s) for libgit2-dev. Thanks Geert. One more question, I'm currently helping with the library transition for libgit2-dev, the above 26 reverse build-depends are all only from main. Do I also need to care about Reverse Build-depends in contrib & non-free as well? > Summary: I can't reproduce the reported problem. OK. IMHO, Debian should really provide build farms to DD/DM. My machine can barely provide enough HD and CPU power for libgit2-dev library transition, and making the building environment working for such library transition is already a daunting task to me. Being able to access a powerful machine that can build fast, and be free from troubles like above, will greatly speed up the process. Anyway. Thanks again.
build-rdeps: character 0-1: RFC 822 error
Hi, I'm getting "character 0-1: RFC 822 error" from build-rdeps: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ build-rdeps libgit2-dev Reverse Build-depends in main: -- Fatal error in module common/format822.ml: character 0-1: RFC 822 error. No reverse build-depends found for libgit2-dev. Reverse Build-depends in contrib: -- Fatal error in module common/format822.ml: character 0-1: RFC 822 error. No reverse build-depends found for libgit2-dev. Reverse Build-depends in non-free: -- Fatal error in module common/format822.ml: character 0-1: RFC 822 error. No reverse build-depends found for libgit2-dev. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - How can I get it working? Thx PS: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux bullseye/sid Release:unstable Codename: sid $ apt-cache policy devscripts devscripts: Installed: 2.20.4 Candidate: 2.20.4 Version table: *** 2.20.4 500 500 http://deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status $ apt-cache policy dose-extra dose-extra: Installed: 5.0.1-15+b1 Candidate: 5.0.1-15+b1 Version table: *** 5.0.1-15+b1 500 500 http://deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status
Re: Seeking a mentoree for imagemagick
On Wed, Jul 29, 2020 at 6:04 AM Bastien ROUCARIES wrote: > > On Tue, Jul 28, 2020 at 12:00 AM Tong Sun > wrote: > > > > Ok, let me try. > > > > Let me start with 4. Backport security patch for stable and old stable > > first, as it looks an easier starter for me. > > > > We can take the further details offline, if you want. > > Ok you could take this one. see the security tracker of imagemagick > and see if patch could be applied and synchronize with security team. Ok, I've never done this before, so a little bit of help is needed now Basten, :) So, by "see the security tracker" I'm guessing you meant to check https://security-tracker.debian.org/tracker/source-package/imagemagick right? I saw bullseye has a lot of issues listed as vulnerable, while both stretch and buster are listed as fixed. Since buster & bullseye both has the same version, 8:6.9.10.23+dfsg-2.1, I'm wondering what are the steps I should take to fix say CVE-2020-13902, and CVE-2020-10251 (of which buster is listed as "vulnerable (no DSA, ignored)"). Thanks > > > > thx > > > > On Mon, Jul 27, 2020 at 9:08 AM Bastien ROUCARIES > > wrote: > > > > > > On Mon, Jul 27, 2020 at 2:29 PM Tong Sun > > > wrote: > > > > > > > > Hi Bastien, > > > > > > > > What kind of help are you looking for? > > > > > > Thanks for help. I need help from easier to harder: > > > 1. triaging bug > > > 2 CVE and security tracking, see if CVE of imagemagick apply and > > > contact security team > > > 3. See if upstream commit contains security sensitive problems and > > > contact security team > > > 4. Backport security patch for stable and old stable > > > 5. Helping me with imagemagick 6 to get latest stable update > > > 6. Helping me with getting imagemagick 7 in unstable. > > > > > > Even one item here will help, and I will help you to improve your > > > programming skills and maybe a day become a dd > > > > > > Bastien > > > > > > > > cheers > > > > > > > > On Mon, Jul 27, 2020 at 6:03 AM Bastien ROUCARIES - > > > > roucaries.bast...@gmail.com > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I am the dd in charge of imagemagick and i need help. > > > > > > > > > > If somebody is interested I can mentor it. > > > > > > > > > > Thanks > > > > > > > > > > Bastien > > > > > > > > > >
Re: Seeking a mentoree for imagemagick
Ok, let me try. Let me start with 4. Backport security patch for stable and old stable first, as it looks an easier starter for me. We can take the further details offline, if you want. thx On Mon, Jul 27, 2020 at 9:08 AM Bastien ROUCARIES wrote: > > On Mon, Jul 27, 2020 at 2:29 PM Tong Sun > wrote: > > > > Hi Bastien, > > > > What kind of help are you looking for? > > Thanks for help. I need help from easier to harder: > 1. triaging bug > 2 CVE and security tracking, see if CVE of imagemagick apply and > contact security team > 3. See if upstream commit contains security sensitive problems and > contact security team > 4. Backport security patch for stable and old stable > 5. Helping me with imagemagick 6 to get latest stable update > 6. Helping me with getting imagemagick 7 in unstable. > > Even one item here will help, and I will help you to improve your > programming skills and maybe a day become a dd > > Bastien > > > > cheers > > > > On Mon, Jul 27, 2020 at 6:03 AM Bastien ROUCARIES - > > roucaries.bast...@gmail.com > > wrote: > > > > > > Hi, > > > > > > I am the dd in charge of imagemagick and i need help. > > > > > > If somebody is interested I can mentor it. > > > > > > Thanks > > > > > > Bastien > > > > > >
RFS: microsocks/1.0.1-1 [ITP] -- multithreaded, small, efficient SOCKS5 server
Hi, Trying for the second time for the RFP->ITP->RFS package that I built a while ago. It's a sister package from https://github.com/rofl0r, whose other lightweight package has already been taken into Debian: tinyproxy - Lightweight, non-caching, optionally anonymizing HTTP proxy Besides, this package was tested on both gbp and sbuild. It's also lintian-clean. So I believe there is minimum work involved (except copying the repo from https://salsa.debian.org/suntong-guest/microsocks to the official place). Moreover, I've uploaded it to mentors this time: -- Forwarded message - From: mentors.debian.net Date: Sat, Jul 25, 2020 at 12:27 PM Subject: microsocks_1.0.1-1: ACCEPTED into unstable Hi. Your upload of the package 'microsocks' to mentors.debian.net was successful. Others can now see it. The URL of your package is: https://mentors.debian.net/package/microsocks/ The respective dsc file can be found at: https://mentors.debian.net/debian/pool/main/m/microsocks/microsocks_1.0.1-1.dsc If you do not yet have a sponsor for your package you may want to go to: https://mentors.debian.net/sponsors/rfs-howto/microsocks/ and set the "Seeking a sponsor" option to highlight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give your suggestions on how to send that mail. Good luck in finding a sponsor! Thanks, -- mentors.debian.net On Sun, Jun 28, 2020 at 12:07 AM Tong Sun wrote: > > Hi, > > I'm looking for a sponsor for the package "microsocks" (#962479). > It is at: > https://salsa.debian.org/suntong-guest/microsocks > https://salsa.debian.org/suntong-guest/microsocks/-/commits/debian/sid > > * Package name: microsocks > Version : 1.0.1-1 > Upstream Author : rofl0r > * URL : https://github.com/rofl0r/microsocks > * License : Expat > Programming Lang: C > Description : tiny, portable SOCKS5 server with very moderate > resource usage > > MicroSocks - multithreaded, small, efficient SOCKS5 server. a SOCKS5 > service that you can run on your remote boxes to tunnel connections > through them, if for some reason SSH doesn't cut it for you. > . > - It's very lightweight, and very light on resources too. > - It's also designed to be robust: it handles resource exhaustion gracefully > by simply denying new connections, instead of calling abort() as most > other programs do these days. > - Another plus is ease-of-use: no config file necessary, everything can > be done from the command line and doesn't even need any parameters for > quick setup. > > Thanks
Re: RFS: microsocks -- tiny, portable SOCKS5 server with very moderate resource usage
Ah, yeah, thanks for spotting that. The control file and ITP are correct, just this RFS message has such a problem. On Sun, Jun 28, 2020 at 8:12 AM Felix Yan - felixonm...@archlinux.org wrote: > > On Sun, 2020-06-28 at 00:07 -0400, Tong Sun wrote: > > Programming Lang: Go > > It should be C. > > -- > Regards, > Felix Yan
RFS: microsocks -- tiny, portable SOCKS5 server with very moderate resource usage
Hi, I'm looking for a sponsor for the package "microsocks" (#962479). It is at: https://salsa.debian.org/suntong-guest/microsocks https://salsa.debian.org/suntong-guest/microsocks/-/commits/debian/sid * Package name: microsocks Version : 1.0.1-1 Upstream Author : * URL : https://github.com/rofl0r/microsocks * License : Expat Programming Lang: Go Description : tiny, portable SOCKS5 server with very moderate resource usage MicroSocks - multithreaded, small, efficient SOCKS5 server. a SOCKS5 service that you can run on your remote boxes to tunnel connections through them, if for some reason SSH doesn't cut it for you. . - It's very lightweight, and very light on resources too. - It's also designed to be robust: it handles resource exhaustion gracefully by simply denying new connections, instead of calling abort() as most other programs do these days. - Another plus is ease-of-use: no config file necessary, everything can be done from the command line and doesn't even need any parameters for quick setup. Thanks
RFH: dbab_1.5.01-1 changes
Thanks to kind reviews from DDs like you, I made all the following changes, from my last upload (v1.3.3). I believe I've fixes everything, at least to those that I can understand, would you like to review again please? The only thing that I did not fix is, the dbab-svr is running as root. I did some research and found it is very hard to fix, as it is merely a simple Perl script, and it need to bind to lower port (#80). My workaround is to provide an alternative solution -- https://github.com/suntong/dbab-packer/tree/master/build-dbab I appreciate if anyone can beta-test it as well. Thanks -- Forwarded message - From: Debian FTP Masters Date: Thu, May 21, 2020 at 12:33 AM Subject: dbab_1.5.01-1_source.changes ACCEPTED into unstable To: Tong Sun Accepted: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Format: 1.8 Date: Tue, 19 May 2020 05:25:48 + Source: dbab Architecture: source Version: 1.5.01-1 Distribution: unstable Urgency: medium Maintainer: Tong Sun Changed-By: Tong Sun Closes: 58938 876815 958899 958937 Changes: dbab (1.5.01-1) unstable; urgency=medium . * [c400b97] remove debian/README.Debian * [614cdaf] fix debian/control minor issues * [*] fixes for perlcritic * Code before strictures * Subroutine "new" called using indirect syntax * use explicit lexical variable instead of $_ * mixed tabs and spaces * [+] add dbab-srv self-identification, closes: #876815 * [*] make dbab-get-list more robust, closes: #958938 * [*] update README.md, closes: #958937 * [*] update (c) year, dbab-add-list now writes a header too * [*] !!breaking changes: renamed dbab-dnsmasq.*.conf files!! * [*] update assets/dbab-dnsmasq.DHCP.conf * [*] update assets/dbab-squid.*.conf; clean up Makefile * [!] fix dbab-init-d-script: stop does not stop, closes: #958899 * [*] simplify design, remove dbab.proxy config, assume pixelserv and squid will always serve from the *same* IP * [ab04074] New upstream version 1.5.0 * [b24ada6] follow upstream/1.5.0 change to rename .conf files * [-] remove assets/dbab.proxy * [!] source /lib/init/init-d-script in etc/init.d/dbab, to fix init.d-script-does-not-implement-required-option & init.d-script-does-not-source-init-functions * [b6f61fb] New upstream version 1.5.01 Checksums-Sha1: 38c29578ebd5137dfd71b30e0f290ec454d84e91 1915 dbab_1.5.01-1.dsc d686685fd498ae181926de6d751463bef2303bb5 17048 dbab_1.5.01.orig.tar.gz 31a296cfe0cd91a61d182409eb3d249b34c27e81 5364 dbab_1.5.01-1.debian.tar.xz 686564095d72135e1f2abcd4837bb2f16a8e30e2 6246 dbab_1.5.01-1_source.buildinfo Checksums-Sha256: f98202bac73905d93467fdee88770c685902367be2f5ce84c29c78bec4b0c17d 1915 dbab_1.5.01-1.dsc 2f80e90414b92a5bc38d8a62cf8c21eea9a39e1c87d7fb113113d370a8849ca8 17048 dbab_1.5.01.orig.tar.gz 471319d698aa00e8212aafb48a85ddb0a5a81bc5911ae44524b26630c65da915 5364 dbab_1.5.01-1.debian.tar.xz 91634d670aaf51ea32a1b6fb43ed59bffc0d78ac6769a1f62e254a2d65f189e3 6246 dbab_1.5.01-1_source.buildinfo Files: b314e2c6a6a0b00be3d99e86886b7bd6 1915 net optional dbab_1.5.01-1.dsc 6c6404141ce461e4fa1e2d42cdceda23 17048 net optional dbab_1.5.01.orig.tar.gz 4a4ec4d109b1f01c0491736c50066967 5364 net optional dbab_1.5.01-1.debian.tar.xz 3c7d0c3d581e8a25dfb80f9f45d560da 6246 net optional dbab_1.5.01-1_source.buildinfo -BEGIN PGP SIGNATURE- iQJVBAEBCgA/FiEEp3mFrXK0ygjYxb95iF/aszH+2DQFAl7GAg4hHHN1bnRvbmcw MDFAdXNlcnMuc291cmNlZm9yZ2UubmV0AAoJEIhf2rMx/tg099YP/0JxWSta5laJ CmdFL4r6nQs+7+A9PHyyIzWZyOkkqndWrZCcScUTORpslFoKKA6Ed87In26ynnkm V2C5wQ6PvmDh/CC6SbLhi4Hisob8qlxW8UXzbSfWKkUjh0+ilV4be8XhIYcM4HJ5 w5taStHXgxFCtYnrA279zEyyMifnO28PSbFgSMsl8GJL4n/ahc1BJSxq2ItcTGj8 BeN3YZqLqUQp5l0fHzThK7MORIK9t2/xaVw+dSGYfqyg1B+GkB2QG/K025LL3349 shHfyV/BYR8pMFAwdqnZcSr4IFzziigMrCJml/vxU1Ljh2q5p/SFVKr2WK/JL/+K 2TuKiiI8GiY19GpVhB9OfC8UoOo8PrQI5yUxb9kpqSg5i+9pQ0gH3K5BHhxMRDSY pUVCqoUsGLrjlQQ7TdvRtCJvzWH3yl2b+7Cs2TbAfkVTdW7tF8/f4lEjkkKV3jAH epYafv5w3SGf/UqHf1BsTFv/CT7xLXykTR1WnZiq5c4vMsy1y61I6xn+7AXa8XZV nOMR76TtDqIAo/1iv9kqRvRGiC3CXR1hcPXnZWWniQWOtGL5bll3JnoeUBbMZYt+ mde3k9xWcYxvy/9YQ6v8ce42rRBiUzEAqowcNWWkGRuxH35FiL3CwmgC5nZRezs9 syh8ar7q+ZroAtbWsHYjaZVy/n7+HhNR =jmnp -END PGP SIGNATURE- Thank you for your contribution to Debian.
RFH, dbab 1.5 preparation
Hi mentors, I need to dip into the vast knowledge of this group as my question is not purely Debian packing base (it is a critical step towards it though). I'm preparing for my dbab 1.5 release, and I'm testing it in docker. Then it hits me that releasing it to be docker ready would definitely be a plus. But the problem is, if I put it in docker, my CMD will only last 8 seconds, then it stops. CONTAINER IDIMAGECOMMAND CREATED STATUS PORTS NAMES 76c9272308ebsys/dbab-docker:latest "/start.sh" 9 seconds ago Exited (1) 8 seconds ago dbab-docker The build instruction is here - https://github.com/suntong/dbab-packer/tree/master/build-alpine I did tried to build a docker image and uploaded to docker hub, but then I realized that because it needs customization, my docker image is only suitable to me, not anybody else. So you need to build for yourself. As a comparison, this will stay there just fine https://github.com/suntong/dbab-packer/tree/master/build-squid But the two CMD ends with exactly same command. If I don't do `docker run -d` but `docker run -it`, then do `/start.sh` within the interactive shell, then AOK. I've been fighting with this since last Friday, but things are so weird that I've run out of ideas now. Would you help please? PS. a bit of "pre-release-commercial" about my dbab 1.5 in docker -- A turn key solution as a central LAN server, wrapped in a small docker container. - Provides DNS, DHCP, local caching and ads filtering services for machines on the LAN - All configuration for DNS, DHCP, local caching and ads filtering services are done automatic, or semi-automatic - Only less than 55M in image size (53.5MB as we speak) - Compressed size is only less than 20MB if uploaded to docker hug (17.36 MB as we speak) Thanks
Debian package postupgrade script
Hi, I've been to https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html but am still a bit lost on how to provide postupgrade script to my package. I've made some breaking changes to my package, https://github.com/suntong/dbab/commit/3ab123e5a90f2b37021a8a1b27dc6eaf2a9b87d6#diff-087e6c3b5855f52a443f266d08a555d1R77-R78 and would like to remove the old configure files in postupgrade step. Would you be so kind as show me how it could be done please? Thanks!
Re: Not all files in my package installed
On Fri, May 1, 2020 at 4:17 AM Sven Hartge - s...@svenhartge.de wrote: > > Tong Sun wrote: > > > -- > > $ ls -l `dpkg -L dbab` > /dev/null > > ls: cannot access '/usr/share/doc/dbab/README.Debian': No such file or > > directory > > ls: cannot access '/usr/share/doc/dbab/changelog.Debian.gz': No such file > > or directory > > ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.intranet.conf': No such > > file or directory > > ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.service.conf': No such > > file or directory > > ls: cannot access '/usr/share/doc/dbab/dbab-squid.localnet.conf': No such > > file or directory > > ls: cannot access '/usr/share/doc/dbab/dbab-squid.service.conf': No such > > file or directory > > ls: cannot access '/usr/share/doc/dbab/dbab.md.gz': No such file or > > directory > > ls: cannot access '/usr/share/man/man8': No such file or directory > > ls: cannot access '/usr/share/man/man8/dbab-svr.8.gz': No such file or > > directory > > ls: cannot access '/usr/share/man/man8/dbab-add-list.8.gz': No such file or > > directory > > ls: cannot access '/usr/share/man/man8/dbab-chk-list.8.gz': No such file or > > directory > > ls: cannot access '/usr/share/man/man8/dbab-get-list.8.gz': No such file or > > directory > > ls: cannot access '/usr/share/man/man8/dhcp-add-wpad.8.gz': No such file or > > directory > > -- > > > What could possibly be wrong? > > Could be dpkg's path-include and path-exclude configuration on your > local system, for example from localepurge. > > Does > > rgrep "path-" /etc/dpkg > > return anything for you? Ah~~~, thank you, thank you Sven, and David! Indeed -- /etc/dpkg/dpkg.cfg.d/docker:path-exclude /usr/share/doc/* /etc/dpkg/dpkg.cfg.d/docker:path-exclude /usr/share/man/* . . . I've been pulling my hair worrying something is wrong with my package! phrew, THANKS!!
Not all files in my package installed
Hi, I've never experience this before and I have no clue either, but not all files in my package get installed: -- % apt-get install --reinstall -y dbab . . . Get:1 http://deb.debian.org/debian testing/main amd64 dbab all 1.3.3-1 [22.3 kB] Fetched 22.3 kB in 0s (204 kB/s) . . . Preparing to unpack .../archives/dbab_1.3.3-1_all.deb ... Unpacking dbab (1.3.3-1) over (1.3.3-1) ... Setting up dbab (1.3.3-1) ... % dpkg -L dbab /. /etc /etc/dbab /etc/dbab/dbab.addr /etc/dbab/dbab.list+ /etc/dbab/dbab.list- /etc/dbab/dbab.proxy /etc/init.d /etc/init.d/dbab /lib /lib/init /lib/init/dbab-init-d-script /lib/systemd /lib/systemd/system /lib/systemd/system/dbab.service /usr /usr/sbin /usr/sbin/dbab-add-list /usr/sbin/dbab-chk-list /usr/sbin/dbab-get-list /usr/sbin/dbab-svr /usr/sbin/dhcp-add-wpad /usr/share /usr/share/doc /usr/share/doc/dbab /usr/share/doc/dbab/README.Debian /usr/share/doc/dbab/changelog.Debian.gz /usr/share/doc/dbab/copyright /usr/share/doc/dbab/dbab-dnsmasq.intranet.conf /usr/share/doc/dbab/dbab-dnsmasq.service.conf /usr/share/doc/dbab/dbab-squid.localnet.conf /usr/share/doc/dbab/dbab-squid.service.conf /usr/share/doc/dbab/dbab.md.gz /usr/share/man /usr/share/man/man8 /usr/share/man/man8/dbab-svr.8.gz /usr/share/man/man8/dbab-add-list.8.gz /usr/share/man/man8/dbab-chk-list.8.gz /usr/share/man/man8/dbab-get-list.8.gz /usr/share/man/man8/dhcp-add-wpad.8.gz -- Everything looks good so far, but -- -- $ ls -l `dpkg -L dbab` > /dev/null ls: cannot access '/usr/share/doc/dbab/README.Debian': No such file or directory ls: cannot access '/usr/share/doc/dbab/changelog.Debian.gz': No such file or directory ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.intranet.conf': No such file or directory ls: cannot access '/usr/share/doc/dbab/dbab-dnsmasq.service.conf': No such file or directory ls: cannot access '/usr/share/doc/dbab/dbab-squid.localnet.conf': No such file or directory ls: cannot access '/usr/share/doc/dbab/dbab-squid.service.conf': No such file or directory ls: cannot access '/usr/share/doc/dbab/dbab.md.gz': No such file or directory ls: cannot access '/usr/share/man/man8': No such file or directory ls: cannot access '/usr/share/man/man8/dbab-svr.8.gz': No such file or directory ls: cannot access '/usr/share/man/man8/dbab-add-list.8.gz': No such file or directory ls: cannot access '/usr/share/man/man8/dbab-chk-list.8.gz': No such file or directory ls: cannot access '/usr/share/man/man8/dbab-get-list.8.gz': No such file or directory ls: cannot access '/usr/share/man/man8/dhcp-add-wpad.8.gz': No such file or directory -- What could possibly be wrong? The package is at: https://salsa.debian.org/debian/dbab Thanks!
Re: How to update upstream when upstream has no releases
On Sat, Apr 4, 2020 at 5:48 PM Tong Sun wrote: > > On Sat, Apr 4, 2020 at 1:53 PM Robin Gustafsson - ro...@rgson.se > wrote: > > > > Hi Tong Sun, > > > > > I was using `gbp import-orig --sign-tags --uscan` but it seems that > > > `--uscan` cannot be used with `gbp import-orig` under the case of no > > > upstream releases. > > > > I believe it'll work if the debian/watch file is set up such as to > > have uscan download the upstream's git repo. The "direct access to the > > git repository" sections in the uscan manual provides examples of what > > I'm referring to. > > Thanks to all who replied. > > This is my debian/watch file > (https://salsa.debian.org/go-team/packages/golang-github-tonistiigi-fsutil/-/blob/debian/sid/debian/watch) > > version=4 > opts="mode=git, pgpmode=none" \ > https://github.com/tonistiigi/fsutil.git \ > HEAD debian > > but when I ran it, I got the following error: > > gbp:error: Uscan failed: Filename pattern missing version delimiters > () without filenamemangle Sorry, I fix it -- I should have ran it within my docker but not outside it.
Re: How to update upstream when upstream has no releases
On Sat, Apr 4, 2020 at 1:53 PM Robin Gustafsson - ro...@rgson.se wrote: > > Hi Tong Sun, > > > I was using `gbp import-orig --sign-tags --uscan` but it seems that > > `--uscan` cannot be used with `gbp import-orig` under the case of no > > upstream releases. > > I believe it'll work if the debian/watch file is set up such as to > have uscan download the upstream's git repo. The "direct access to the > git repository" sections in the uscan manual provides examples of what > I'm referring to. Thanks to all who replied. This is my debian/watch file (https://salsa.debian.org/go-team/packages/golang-github-tonistiigi-fsutil/-/blob/debian/sid/debian/watch) version=4 opts="mode=git, pgpmode=none" \ https://github.com/tonistiigi/fsutil.git \ HEAD debian but when I ran it, I got the following error: gbp:error: Uscan failed: Filename pattern missing version delimiters () without filenamemangle I can't quite interpret what it is telling me, and I didn't find much on the Internet that fix it. Searching through https://people.debian.org/~osamu/uscan.html#direct-access-to-the-git-repository for KW "Filename", I didn't find much good explanation either.
How to update upstream when upstream has no releases
Hi, How to use `gbp import-orig` to update upstream when upstream has no releases? I was using `gbp import-orig --sign-tags --uscan` but it seems that `--uscan` cannot be used with `gbp import-orig` under the case of no upstream releases. I'm using the Dep14 Workflow so no pristine tar branch needed. Thanks
Understand Debian Keyring
On Sat, Jan 4, 2020 at 7:56 PM Paul Wise wrote: > > How to delete my package from ftp.upload.debian.org? > > Usually that means using dcut (from devscripts), but in this case the > package is no longer in the upload queue so you cannot remove it from > there. > . . . Thanks a lot for the explanation. Now, before I redo the upload (and get it stuck again), let me try to understand the situation -- The reason it was stuck might be because my key was *considered* expired. The problem is, I renewed it two or three weeks ago, and sent it to pgp & Ubuntu key servers. The mentors.debian.net accepted my (renewed) key, but ftp-master didn't. Might that my key on ftp-master.debian.org is somehow not refreshed? Anyway, I tried to fix the issue by refreshing my key to keyring.debian.org. However, on reading https://keyring.debian.org/, I stated to wonder that if it good enough *now*: > We will include your changed key in our next keyring push (which happens > approx. monthly). What does it really mean? Shall I need to wait a month before uploading again?
Re: How to delete my package from ftp.upload.debian.org
On Sat, Jan 4, 2020 at 7:56 PM Paul Wise wrote: > > > > Package has already been uploaded to ftp-master on ftp.upload.debian.org > > Nothing more to do for dbab_1.3.3-1_source.changes > > > > This error message is solely based on the files on your local system, > if you want to reupload the same .changes filename, you will need to > delete the corresponding .upload file. > > Please also file a bug/patch against the upload tool that you are > using, it should have a better error message for this situation or > have a confirmation prompt or something. Thanks a lot for the clear explanation. will do...
How to delete my package from ftp.upload.debian.org
Hi, How to delete my package from ftp.upload.debian.org? Here are the details -- My upload to ftp.upload.debian.org has been sitting there for quite some time without showing up in tracker yet. Later I found out (through kind Thorsten): 20191228024911|process-upload|dak|dbab_1.3.3-1_source.changes|Error while loading changes file dbab_1.3.3-1_source.changes: No valid signature found. (GPG exited with status code 0) I tried to fix the issue (by refreshing my key to keyring.debian.org), then tried uploading again. Of course, I got: Package has already been uploaded to ftp-master on ftp.upload.debian.org Nothing more to do for dbab_1.3.3-1_source.changes If I can't delete my package from ftp.upload.debian.org, can somebody help me please? Thanks
Re: gbp import-orig after upstream force update
On Tue, Dec 31, 2019 at 7:38 PM Mattia Rizzolo - mat...@debian.org wrote: > > On Tue, Dec 31, 2019 at 06:28:55PM -0500, Tong Sun wrote: > > How to do gbp import-orig after upstream did *force* push/update with > > the same tag? > > > > While doing packaging, there will always some trivial things I found I > > need to update the upstream source (I'm the author for both upstream > > and Debian packaging). > > > > However, if I have to give a new tag each time I do such trivial > > updates, then they'll go very fast for very trivial changes, which > > does not look good. So I always force push/update with the same tag. > > At the same time, it looks *horribly* from my side every time I see such > things. > > Don't tag things until you really want to release, and by then you ought > to have tested things well enough. If it's really trivial changes, then > it can just wait for whenever you feel like doing a new release. Totally, I would avoid such problems as much as possible. However the situation is, - From the source side, everything is ready. It is only when it comes to Debian building, I found that I need do trivial updates to the upstream. - The problem is that, `gbp import-orig` is looking for upstream tarball, which is only available when I do tagging, and this is exactly why I'm asking the question. I know I can go entirely manual, to do everything on my own without using tools like `gbp import-orig`, but that's the route I want to avoid. That being said, Thanks to your help anyway.
Re: gbp import-orig after upstream force update
On Tue, Dec 31, 2019 at 6:28 PM Tong Sun wrote: > > Hi, > > How to do gbp import-orig after upstream did *force* push/update with > the same tag? > > While doing packaging, there will always some trivial things I found I > need to update the upstream source (I'm the author for both upstream > and Debian packaging). > > However, if I have to give a new tag each time I do such trivial > updates, then they'll go very fast for very trivial changes, which > does not look good. So I always force push/update with the same tag. > > The problem is that I haven't been able to figure out how to have `gbp > import-orig` to deal with such situation NVM, found that the real problem is actually at GH side -- force push with the same tag will not trigger GH to rebuild the .tgz tarball.
gbp import-orig after upstream force update
Hi, How to do gbp import-orig after upstream did *force* push/update with the same tag? While doing packaging, there will always some trivial things I found I need to update the upstream source (I'm the author for both upstream and Debian packaging). However, if I have to give a new tag each time I do such trivial updates, then they'll go very fast for very trivial changes, which does not look good. So I always force push/update with the same tag. The problem is that I haven't been able to figure out how to have `gbp import-orig` to deal with such situation -- I always get: gbp:error: Upstream tag 'upstream/...' already exists How to fix it? Thx
Re: Bug#947550: RFH: salsa.debian.org/debian/dbab
Thanks a lot David, for your explanation and detailed commands. I was trying to find a way out reading the convoluted user manual, and finally found one way that worked (and much much more convoluted than the commands you listed and yet achieving much less). Thanks a lot, I wish I had known them earlier. I am now trying to apply to my existing repo, wish me luck... On Sat, Dec 28, 2019 at 3:52 PM David Bürgin - dbuer...@gluet.ch wrote: > > Hello Tong, > > I’m not a mentor but I recently pushed an existing package to Salsa. I > now used the same procedure on your dbab package, you can see the result > at https://salsa.debian.org/glts-guest/dbab. Here’s what I did: > > gbp import-dscs --debsnap dbab > cd dbab > git remote add origin g...@salsa.debian.org:glts-guest/dbab.git > git push --all -u origin > git push --tags > > With this procedure all the history of snapshots/pristine-tars gets > imported, see https://salsa.debian.org/glts-guest/dbab/-/network/master. > I see that you didn’t import the existing history, so maybe your goal is > different … > > I have this setting in ~/.gbp.conf to import the pristine tarballs > properly: > > [DEFAULT] > pristine-tar = True > > That’s it. Hope this is helpful. > > Cheers, > >
Re: Debian source search by file name
Oh thanks a lot for trying it out, finding the solution, and giving
comprehensive explanation!
Really appreciate it!
On Sat, Dec 28, 2019 at 5:16 PM The Wanderer - wande...@fastmail.fm wrote:
>
> On 2019-12-28 at 14:47, Tong Sun wrote:
>
> > Hi,
> >
> > Is it possible to do Debian source search by file name?
> >
> > I wanted to see examples of overriding
> > debian-watch-does-not-check-gpg-signature in
> > debian/source/lintian-overrides files, so I did:
> >
> > https://codesearch.debian.net/search?q=path%3Adebian%2Fsources%2Flintian-overrides
> > https://codesearch.debian.net/search?q=gpg+signature+path%3Adebian%2Fsources%2Flintian-overrides
> >
> > But none gave results I want. Both say:
> >
> > . . . had no results. Please read the FAQ to make sure your syntax is
> > correct.
> >
> > I think my syntax is correct, right?
>
> Try:
>
> https://codesearch.debian.net/search?q=gpg-signature+path%3Adebian%2Fsource%2Flintian-overrides
>
> which works for me right now.
>
> The only differences I see between this and your second URL above are A:
> the use of the correct path ("source" instead of "sources"), and B: the
> use of 'gpg-signature' instead of 'gpg signature'.
>
> If I drop the 'gpg-signature' part from this search term, I get the same
> error you got. I'm guessing that that's because there's no actual search
> term for *within* the file, and the search engine isn't going to report
> the entire file; if I'm right, that would be the other reason the first
> URL you gave doesn't find anything, aside from the path typo.
>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>
Debian source search by file name
Hi, Is it possible to do Debian source search by file name? I wanted to see examples of overriding debian-watch-does-not-check-gpg-signature in debian/source/lintian-overrides files, so I did: https://codesearch.debian.net/search?q=path%3Adebian%2Fsources%2Flintian-overrides https://codesearch.debian.net/search?q=gpg+signature+path%3Adebian%2Fsources%2Flintian-overrides But none gave results I want. Both say: . . . had no results. Please read the FAQ to make sure your syntax is correct. I think my syntax is correct, right?
Bug#947550: RFH: salsa.debian.org/debian/dbab
Pls help. Thanks -- Forwarded message - From: Tong Sun Date: Fri, Dec 27, 2019 at 10:06 PM Subject: RFH: salsa.debian.org/debian/dbab To: Debian Bug Tracking System Package: wnpp Severity: normal I've created/updated the salsa repo at: https://salsa.debian.org/debian/dbab For the package of https://tracker.debian.org/pkg/dbab The reason that I’m asking for reviewing is that, - this is the first time that I created a salsa project all by myself - also, this is the first time that I am doing the packaging and uploading all by myself The package was tested on both gbp and sbuild (http://paste.debian.net/1122767/). It's also lintian-clean. And I’ve done my best to fix anything I can. However, a second pair of eyes, i.e., any kind of reviews and suggestions are appreciated. Thanks Tong
Re: The pristine-tar and upstream tarball
All fixed. thx. On Fri, Dec 20, 2019 at 11:26 AM Tong Sun wrote: > Hi, > > After many readings, I'm still a bit confused about the pristine-tar > and upstream tarball. > > So I've just prepared my salsa repo > > https://salsa.debian.org/debian/dbab/ > > and hope everything is good. > > My understanding is that with gbp & pristine-tar branch, we can > produce the orig.tar.gz when building a source package from the > repository alone, right? Then How to do it? I tried: > > $ gbp import-orig --pristine-tar --uscan > gbp:info: Launching uscan... > gbp:info: package is up to date, nothing to do. > > $ uscan --download | wc > 0 0 0 > > $ uscan --verbose --download > . . . > uscan info: Filename (filenamemangled) for downloaded file: > dbab-1.3.3.tar.gz > uscan info: Newest version of dbab on remote site is 1.3.3, local > version is 1.3.3 > uscan info:=> Package is up to date for from > https://github.com/suntong/dbab/archive/1.3.3.tar.gz > uscan info: Scan finished > > but still, no upstream tarball downloaded. > > > My other question is, there does seems to be some problem with my > pristine-tar branch: > > $ gbp buildpackage > dh clean >dh_auto_clean > make -j1 clean > make[1]: Entering directory '/export/build/pkg/dbab/dbab' > rm -f assets/dbab-svr.8 > make[1]: Leaving directory '/export/build/pkg/dbab/dbab' >dh_clean > gbp:warning: Unknown compression type of - [*] give pristine-tar files > proper names, assuming gzip > gbp:info: Creating /export/build/pkg/dbab/build-area/dbab_1.3.3.orig.tar.gz > gbp:error: Error creating dbab_1.3.3.orig.tar.gz: Pristine-tar > couldn't checkout "dbab_1.3.3.orig.tar.gz": fatal: Path > 'dbab_1.3.3.orig.tar.gz.delta' does not exist in > 'refs/heads/pristine-tar' > pristine-tar: git show > refs/heads/pristine-tar:dbab_1.3.3.orig.tar.gz.delta failed > > Apparently my understanding of preparing the pristine-tar branch was > wrong (as well). So the second question is, how should I preparing the > pristine-tar branch? > I know it must be a FAQ but it appears that I just haven't found the > *correct* one. > > Finally, the third question, is there anything else that is not > correct with my repo, > https://salsa.debian.org/debian/dbab/? > > Thanks a lot for helping. >
The pristine-tar and upstream tarball
Hi, After many readings, I'm still a bit confused about the pristine-tar and upstream tarball. So I've just prepared my salsa repo https://salsa.debian.org/debian/dbab/ and hope everything is good. My understanding is that with gbp & pristine-tar branch, we can produce the orig.tar.gz when building a source package from the repository alone, right? Then How to do it? I tried: $ gbp import-orig --pristine-tar --uscan gbp:info: Launching uscan... gbp:info: package is up to date, nothing to do. $ uscan --download | wc 0 0 0 $ uscan --verbose --download . . . uscan info: Filename (filenamemangled) for downloaded file: dbab-1.3.3.tar.gz uscan info: Newest version of dbab on remote site is 1.3.3, local version is 1.3.3 uscan info:=> Package is up to date for from https://github.com/suntong/dbab/archive/1.3.3.tar.gz uscan info: Scan finished but still, no upstream tarball downloaded. My other question is, there does seems to be some problem with my pristine-tar branch: $ gbp buildpackage dh clean dh_auto_clean make -j1 clean make[1]: Entering directory '/export/build/pkg/dbab/dbab' rm -f assets/dbab-svr.8 make[1]: Leaving directory '/export/build/pkg/dbab/dbab' dh_clean gbp:warning: Unknown compression type of - [*] give pristine-tar files proper names, assuming gzip gbp:info: Creating /export/build/pkg/dbab/build-area/dbab_1.3.3.orig.tar.gz gbp:error: Error creating dbab_1.3.3.orig.tar.gz: Pristine-tar couldn't checkout "dbab_1.3.3.orig.tar.gz": fatal: Path 'dbab_1.3.3.orig.tar.gz.delta' does not exist in 'refs/heads/pristine-tar' pristine-tar: git show refs/heads/pristine-tar:dbab_1.3.3.orig.tar.gz.delta failed Apparently my understanding of preparing the pristine-tar branch was wrong (as well). So the second question is, how should I preparing the pristine-tar branch? I know it must be a FAQ but it appears that I just haven't found the *correct* one. Finally, the third question, is there anything else that is not correct with my repo, https://salsa.debian.org/debian/dbab/? Thanks a lot for helping.
Debian update package ITP necessary?
Hi, just to be sure, If I'm updating a package that I maintain. I shall just do it. I.e., there isn't any BTS (like ITP) to file and to close, right? thx
Unhide todo list entry in the Ultimate Debian Database
Hi, I accidentally hid a todo list entry in my Ultimate Debian Database. Now I regret it and want it back again. How can I do that? Thx
Salsa repository request (dbab)
Hi, I am currently preparing a new version for the 'dbab' packages [0]. I would like to create a packaging repository for it in the Debian group on Salsa this time [1], but I don't have the necessary permissions on Salsa to create it myself. So, could somebody please create it for me and give me, suntong-guest, maintenance access? Thank you! Best regards, tong [0] https://tracker.debian.org/pkg/dbab [1] https://salsa.debian.org/debian
Bug#928099: RFS: shc/4.0.1, Close
close 928099 thanks Try again...
Bug#928099: RFS: shc/4.0.1, Close
close bugnumber 928099 thanks Closing the RFS as I'm not able to get the help/sponsor to finish the job. "Who serves as a soldier at his own expense?" (1Cor 9:7 NIV) I helped Debian packaging for almost 10 years and never get paid for doing so. Instead, I put in my own time and sacrifice my own holidays to get a bigger block of time to work-on/learn-with Debian packaging. And now someone told me to refer to paid service to get this packaging done. IHMO, that's a bit too much -- Not offering help is understandable, but telling me to go to paid service is like rubbing salt into the wound. Thus, Closing the RFS. On Sat, Apr 27, 2019 at 6:51 PM Debian Bug Tracking System wrote: > > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 928099: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928099. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due course. > > Your message has been sent to the package maintainer(s): > Debian Mentors > > If you wish to submit further information on this problem, please > send it to 928...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > > -- > 928099: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928099 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems
Re: Importing a new upstream version
On Sat, Jul 6, 2019 at 9:55 PM Tong Sun wrote: > I only knew to use this previously: > > gbp import-orig --uscan > > Today I tried `gbp import-orig --uscan --pristine-tar`, after having > done the above `gbp import-orig --uscan` > > > If so, it might > > have failed after creating the 4.0.3 tag, leaving it in the way of > > future attempts. > > So how can I fix it now? I fixed it myself by git tag -d upstream/4.0.3
Re: Importing a new upstream version
On Sat, Jul 6, 2019 at 6:18 PM Rebecca N. Palmer wrote: > What git repository are you running it in? It should be run in the > packaging repository, not the upstream one. (The package's Vcs-Git > field currently points to upstream, which is itself a bug.) Please elaborate what you mean, Rebecca, Did you mean that the following 2-line pointing to the wrong place? https://salsa.debian.org/debian/shc/blob/master/debian/control#L10-11
Debian 10 "buster" released
Hi, Debian 10 "buster" was released today. Just want to confirm that, now when we upload package, we can target back sid again, right? thx
Re: Importing a new upstream version
On Sat, Jul 6, 2019 at 6:18 PM Rebecca N. Palmer wrote: > gbp import-orig --uscan --pristine-tar is the same command as I normally > use. > > Did it fail with something different the first time? I only knew to use this previously: gbp import-orig --uscan Today I tried `gbp import-orig --uscan --pristine-tar`, after having done the above `gbp import-orig --uscan` > If so, it might > have failed after creating the 4.0.3 tag, leaving it in the way of > future attempts. So how can I fix it now? > What git repository are you running it in? It should be run in the > packaging repository, not the upstream one. (The package's Vcs-Git > field currently points to upstream, which is itself a bug.) Ah, thanks for spotting that. I'll fix it. FTR, $ git remote -v origin g...@salsa.debian.org:debian/shc.git (fetch) origin g...@salsa.debian.org:debian/shc.git (push) $ git branch -a * master pristine-tar upstream remotes/origin/HEAD -> origin/master remotes/origin/master remotes/origin/pristine-tar remotes/origin/upstream
Importing a new upstream version
Hi, I had been following these two articles for importing a new upstream version http://marquiz.github.io/git-buildpackage-rpm/gbp.import.html https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.new.upstream.html by doing gbp import-orig --uscan But today, I learnt that my pristine-tar branch is not in the correct shape. So my first question is, what are all the proper steps to import a new upstream version? And secondly, how to fix the following `Upstream tag already exists` `gbp:error`: $ gbp import-orig --uscan --pristine-tar gbp:info: Launching uscan... uscan: Newest version of shc on remote site is 4.0.3, local version is 4.0.2 uscan:=> Newer package available from https://github.com/neurobin/shc/archive/4.0.3.tar.gz gbp:info: Using uscan downloaded tarball ../shc_4.0.3.orig.tar.gz What is the upstream version? [4.0.3] gbp:error: Upstream tag 'upstream/4.0.3' already exists Thanks
Bug#928099: publishing private e-mail
Hi All, I'm sorry if my message come out wrong, and being perceived as unfriendly. That was not my intention, and I'm sorry that people feel that way. Again, I was trying to say that, we were discussing the public matters that affects the package authors, thus affects the public, and I should have included 928...@bugs.debian.org at the very beginning. And I'm sorry for not having done that sooner, which might have changed everything, or might be not. But I'll start doing it now. On Sun, Jun 16, 2019 at 10:39 AM Mo Zhou - lu...@debian.org wrote: > Hi Tong Sun, > > Please be respectful to the others. Whatever the mail address prefix > the others use, the others have the right to make private discussion > and free speech because these are fundamental rights. I don't know > what happend but your comments are really not friendly. > > If you really received problematic messages from a Debian developer, > please consider reaching out the Anti-harrasment team or DPL for help, > privately. > > > On Sat, Jun 15, 2019 at 07:55:04AM -0400, Tong Sun wrote: > >> > > >> > To me, your message, bearing a @debian.org address, should represent > >> > that of debian.org, both privately or publicly, and never says thing > >> that you will regret later, or say it publicly. Especially we are > >> discussing public matters, that affects the public and all authors. > >> > >> Such decision should not be conducted behind close doors. > > >
Bug#928099: Shc's License
On Tue, Jun 11, 2019 at 7:45 AM Tong Sun wrote: > > > On Tue, Jun 11, 2019 at 4:40 AM Bart Martens wrote: > > > > On Mon, Jun 10, 2019 at 4:26 PM Tong Sun wrote: > > > > > > On Thu, Jun 6, 2019 at 8:05 AM Tong Sun wrote: > > > > > > > > On Wed, Jun 5, 2019 at 8:32 PM Tong Sun wrote: > > > > > > > > > > On Sat, Jun 1, 2019 at 10:24 AM Tong Sun wrote: > > > > > > > > > > > > On Sat, May 25, 2019 at 9:02 AM Tong Sun wrote: > > > > > > > > > > > > > Thx. I'll change the license to GPL-3+. > > > > > > > > > > > > Hi Bart, > > > > > > > > > > > > Do think the following change OK? > > > > > > > > > > > > https://salsa.debian.org/debian/shc/commit/933d1a533842e3ddaf3e79ac3e1580842f4fef12 > > > > > > > > > > I've fixed the GPL thing: > > > > > https://salsa.debian.org/debian/shc/blob/master/debian/copyright > > > > > > > > > > I double-checked when you asked me the GPL or LGPL question, but > > > > > didn't find anything prompted your question myself. > > > > > > > > > > Anyway, the reason I'm asking whether you think the change was OK, is > > > > > that I don't know how to properly express within the debian/copyright > > > > > file that the original author, Francisco, was using GPL-2+ license, > > > > > while new version, from https://github.com/neurobin/shc, is using > > > > > GPL-3+. > > > > > > > > > > So once again, This is the way I'm expressing it: > > > > > > > > > > Files: * > > > > > Copyright: > > > > > Francisco Rosales , Copyright 1994-2015 > > > > > License: GPL-2.0+ > > > > > Files: * > > > > > Copyright: > > > > > Md Jahidul Hamid , Copyright 2015-2019 > > > > > License: GPL-3+ > > > > > > > > > > However, I've got a warning: > > > > > > > > > > shc source: > > > > > global-files-wildcard-not-first-paragraph-in-dep5-copyright > > > > > (paragraph at line 10) > > > > > > > > > > Would that be OK, or there IS a proper way to express it? > > > > > > > > Ah, I now remember, there is a way to suppress lintian warnings. > > > > IMHO, it is the best way so far... > > > > > > > > Thx > > > > > > ping > > > > > > Pong. Has my past feedback been fully used? Are my past e-mails still > > > somewhere > > > in your mailbox? > > > > Sorry, please remind me how did you suggest me to do with this? > > shc source: global-files-wildcard-not-first-paragraph-in-dep5-copyright > (paragraph at line 10) Hi Bart, I don't know how to properly express within the debian/copyright file that the original author, Francisco, was using GPL-2+ license, while new version, from https://github.com/neurobin/shc, is using GPL-3+. And I need your kind help to do it properly. As for the most of the time in the message trail above and in the history, I've guessed wrong about what you meant from your short message. If you can give detailed help, that'd be most appreciated, Thanks tong
