Re: Source package origin file differs from the official archive
That worked, thanks Nilesh. Would you be interested in sponsoring the upload? https://mentors.debian.net/package/git-credential-oauth/ is ready. I pushed the Git commits to https://salsa.debian.org/go-team/packages/git-credential-oauth . On Tue, 27 Dec 2022 at 13:36, Nilesh Patra wrote: > On Tue, Dec 27, 2022 at 09:56:57AM +, M Hickford wrote: > > Hi. Any ideas how to fix the error below? I built my package with `gbp > > build-package` and uploaded with `dput -f mentors ../*.changes` > > Try to build/upload with this orig tarball > > > http://deb.debian.org/debian/pool/main/g/git-credential-oauth/git-credential-oauth_0.1.5.orig.tar.gz > > It spits the error in the output, that is the checksums of the orig > tarball and yours do not match. > (I can't say _why_ that's the case, now for you) > > But since this is a go team package, you could simply ask for sponsorship > on the mailing list, I am > not very sure as to why you are pushing it to mentors.d.n, but HTH. > > > [1] Package source > > > https://salsa.debian.org/go-team/packages/git-credential-oauth/-/merge_requests/3 > > Origin file : git-credential-oauth_0.1.5.orig.tar.gz > > > > sha256sum in upload : > > defc68ce1a25423423e17dea77e3b3627aa0f99a98f4758aef3e708327c2664c > > sha256sum in archive: > > 5c36b29368a13af6cf394cd689a5616d5eec3fca7dc862e50ea070eb4f6d154c > > > > Please try to fix it and re-upload. > > -- > Best, > Nilesh >
Re: lintian errors packaging Barry's Emacs
On Tue, Dec 27, 2022 at 10:57:51AM -0700, Soren Stoutner wrote: > Barry, > > Figuring out how to package for Debian has a stiff learning curve (speaking > as someone > who is going through the process myself). > > There are a couple of website that collect links to information that might be > useful to you. > I'd also add Raphael Hertzog's Debian handbook for most things Debian debian-handbook is the Debian package to install, though you can also buy a printed version. It's a gold mine of generally useful information structured as a case study of an imaginary factory setup but with good information on specfics. All best, Andy Cater
Re: lintian errors packaging Barry's Emacs
Barry, Figuring out how to package for Debian has a stiff learning curve (speaking as someone who is going through the process myself). There are a couple of website that collect links to information that might be useful to you. https://mentors.debian.net/intro-maintainers/[1] https://wiki.debian.org/Packaging[2] The references that I personally found most helpful were there following: https://packages.debian.org/bookworm/developers-reference[3] (Install the package and then read /usr/share/developers-reference/developers- reference.pdf) https://packages.debian.org/bookworm/maint-guide[4] (Install the package and then read /usr/share/doc/maint-guide/maint-guide.en.pdf) Note that this document is considered outdated and replaced by https://www.debian.org/ doc/manuals/debmake-doc/index.en.html[5] but I found it to be a more useful read, even though they share an author. You will discover that almost all Debian documentation is outdated, because writing documentation is almost always less exciting than writing code. So, you almost always have to adjust anyway. Also, if you decide to use Git, definitely check out the git-buildpackage documentation: https://packages.debian.org/bookworm/git-buildpackage[6] (Install the package and then read /usr/share/doc/git-buildpackage/manual-html/ index.html) On Tuesday, December 27, 2022 9:24:18 AM MST Barry Scott wrote: > On 27/12/2022 11:16, Ole Streicher wrote: > > Hi Barry, > > > > Barry Scott writes: > >> I am build my first Debian package for Barry's Emacs > >> (https:://barrys-emacs.org) > > > > Aside from Santiagos technical tips: If you really want to contribute > > your package to the Debian distribution, you should also have a few > > other things in mind: > > > > * Your package should come with a proper DFGS compliant [1] license. Your > > > >Github upstream package [2] doesn't have one, and it would be useful > >(not only for Debian packaging) to add one there. > > I plan to state it is Apache-2.0 licensed. There is an issue to fix this. > > > * I would recommend to follow the usual procedures here. Specifically, > > > >you should open an "Intend To Package" (ITP) bug [3] to indicate your > >packaging efforts. > > Happy to contribute bemacs and my other packages to debian. > > The others include scm-workbench, but that needs PyQt6 Scintilla > to get packaged only PyQt5 Scintilla is packaged at the moment. signature.asc Description: This is a digitally signed message part.
Re: lintian errors packaging Barry's Emacs
On 27/12/2022 12:49, Santiago Vila wrote: El 27/12/22 a las 13:12, Ole Streicher escribió: Santiago Vila writes: If you don't have deb-src lines, they are the same as the usual deb lines except that they begin with deb-src. Just curious: why are the deb line not used by default here? There is a question during install about deb-src lines (in expert mode at least), and the user has the opportunity to say "no", so it is possible that OP does not have those lines in his system by default. I do not recall Ubuntu asking such a question. But the deb-src lines are in the /etc/apt/sources.list but commented out. (Not sure at all if that was the meaning of your question)
Re: lintian errors packaging Barry's Emacs
On 27/12/2022 11:16, Ole Streicher wrote: Hi Barry, Barry Scott writes: I am build my first Debian package for Barry's Emacs (https:://barrys-emacs.org) Aside from Santiagos technical tips: If you really want to contribute your package to the Debian distribution, you should also have a few other things in mind: * Your package should come with a proper DFGS compliant [1] license. Your Github upstream package [2] doesn't have one, and it would be useful (not only for Debian packaging) to add one there. I plan to state it is Apache-2.0 licensed. There is an issue to fix this. * I would recommend to follow the usual procedures here. Specifically, you should open an "Intend To Package" (ITP) bug [3] to indicate your packaging efforts. Happy to contribute bemacs and my other packages to debian. The others include scm-workbench, but that needs PyQt6 Scintilla to get packaged only PyQt5 Scintilla is packaged at the moment. Also I need to package PyPI xml-preferences (I'm upstream for that as well. I guess I need an account in the debian infrastructure to do the work under? Bare in mind that I know nothing about what is expected in terms of accounts, contrib agreements etc for debian. Learning debian's ways is like learning a foreign language, there is new grammar and vocabulary I'm encountering. I know the Fedora RPM grammar and vocabulary (I'm a Fedota packager). * The target distribution for the packaging is "unstable" (sid). From there it migrates to the Debian distribution. It also migrates to Ubuntu, Mint, and all the other derivative distributions. Cool. * The packaging efforts should be separated from the software development itself and usually happens on the Salsa Gitlab server [4]. I'd strongly recommend to allow team maintainance, to lower the barrier of packaging-related contributions. I develop features and packaging together as they often play into each other. I support 4 OS (Fedora, macOS, Windows, netbsd) at the moment and want to add debian/ubuntu. Being able to experiment with packaging is valuable to me. I can use the native debian workflow for releasing to public consumption. As I do for Fedora packages I'm the maintainer for. Barry Best regards Ole [1] https://www.debian.org/social_contract#guidelines https://wiki.debian.org/DFSGLicenses [2] https://github.com/barry-scott/BarrysEmacs [3] https://wiki.debian.org/ITP [4] https://salsa.debian.org
Bug#1026823: RFS: zvbi/0.2.39-1 -- Vertical Blanking Interval (VBI) utilities
Hi, The old way involves meeting in person, briefly waving a government-looking id in the face of someone who has no ability to verify the id's authenticity in any way -- and, as we joke, an id is valid if the photo doesn't look like you as that's how real ids look (only a forger would be a try-hard enough to get a photo that actually resembles you!). And it's trivial to get fakes that are good enough to fool professionals anyway. The new way is to have a quick video chat (in order to ascertain you didn't hire a random drunkie), and wave aforemented government-looking id. I had read about key endorsements [1] and was only hoping to get that (not a key signature) as this seems like the simplest way to complete the DM application. I thought this was the new way, especially for those looking only for DM. Would you be willing to endorse? I promise I did not hire a random drunkie, although I might be one already ;) Thank you for continuing to upload zvbi for me. But I am hoping to become a DM so that I can do these uploads myself in the future. [1] https://lists.debian.org/debian-devel-announce/2020/11/msg3.html -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Source package origin file differs from the official archive
On Tue, Dec 27, 2022 at 09:56:57AM +, M Hickford wrote: > Hi. Any ideas how to fix the error below? I built my package with `gbp > build-package` and uploaded with `dput -f mentors ../*.changes` Try to build/upload with this orig tarball http://deb.debian.org/debian/pool/main/g/git-credential-oauth/git-credential-oauth_0.1.5.orig.tar.gz It spits the error in the output, that is the checksums of the orig tarball and yours do not match. (I can't say _why_ that's the case, now for you) But since this is a go team package, you could simply ask for sponsorship on the mailing list, I am not very sure as to why you are pushing it to mentors.d.n, but HTH. > [1] Package source > https://salsa.debian.org/go-team/packages/git-credential-oauth/-/merge_requests/3 > Origin file : git-credential-oauth_0.1.5.orig.tar.gz > > sha256sum in upload : > defc68ce1a25423423e17dea77e3b3627aa0f99a98f4758aef3e708327c2664c > sha256sum in archive: > 5c36b29368a13af6cf394cd689a5616d5eec3fca7dc862e50ea070eb4f6d154c > > Please try to fix it and re-upload. -- Best, Nilesh signature.asc Description: PGP signature
Re: lintian errors packaging Barry's Emacs
El 27/12/22 a las 13:12, Ole Streicher escribió: Santiago Vila writes: If you don't have deb-src lines, they are the same as the usual deb lines except that they begin with deb-src. Just curious: why are the deb line not used by default here? There is a question during install about deb-src lines (in expert mode at least), and the user has the opportunity to say "no", so it is possible that OP does not have those lines in his system by default. (Not sure at all if that was the meaning of your question)
Re: lintian errors packaging Barry's Emacs
On 2022-12-27 at 07:12, Ole Streicher wrote: > Hi Santiago, > > Santiago Vila writes: > >> If you don't have deb-src lines, they are the same as the usual deb >> lines except that they begin with deb-src. > > Just curious: why are the deb line not used by default here? As a place to look for source-package information in the absence of deb-src lines, you mean? While I have no inside knowledge on this, my inference has always been that it's to avoid downloading (and updating) and storing the index data for source packages, for that presumed large majority of people who have no need to care about source packages. I.e., the act of adding a deb-src line is the way for the sysadmin to denote "for this computer, having convenient access to Debian source packages is sufficiently important that the cost of the index data - in local storage, in network traffic, and in remote-server transmission load - is worth paying". In principle it would probably be possible to design a way of flagging that in reverse (so that deb lines would get both types of index by default, and only if a flag is set would the source-package idex data not be gotten), but just at a glance that looks like it'd be more complicated to engineer, and in any case the transition seems as if it'd be mildly horrific. -- 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 signature.asc Description: OpenPGP digital signature
Re: lintian errors packaging Barry's Emacs
Hi Santiago, Santiago Vila writes: > If you don't have deb-src lines, they are the same as the usual deb lines > except that they begin with deb-src. Just curious: why are the deb line not used by default here? Best Ole
Re: lintian errors packaging Barry's Emacs
El 27/12/22 a las 12:28, Barry Scott escribió: How do I go from a installed package and find its debian source? On a Debian/Ubuntu system, if you have deb-src lines in your /etc/apt/sources.list, then apt-get source source-package-name will retrieve the source and unpack it automatically. If you don't have deb-src lines, they are the same as the usual deb lines except that they begin with deb-src. For example, I have this in a sid chroot used to build packages: deb http://deb.debian.org/debian sid main contrib non-free deb-src http://deb.debian.org/debian sid main contrib non-free Hope this helps. Note: As explained by Ole, if your program is libre, it is in the best interest of everyone that you try to package it for Debian, not just for yourself.
Re: lintian errors packaging Barry's Emacs
Hi Barry, Barry Scott writes: > I am build my first Debian package for Barry's Emacs > (https:://barrys-emacs.org) Aside from Santiagos technical tips: If you really want to contribute your package to the Debian distribution, you should also have a few other things in mind: * Your package should come with a proper DFGS compliant [1] license. Your Github upstream package [2] doesn't have one, and it would be useful (not only for Debian packaging) to add one there. * I would recommend to follow the usual procedures here. Specifically, you should open an "Intend To Package" (ITP) bug [3] to indicate your packaging efforts. * The target distribution for the packaging is "unstable" (sid). From there it migrates to the Debian distribution. It also migrates to Ubuntu, Mint, and all the other derivative distributions. * The packaging efforts should be separated from the software development itself and usually happens on the Salsa Gitlab server [4]. I'd strongly recommend to allow team maintainance, to lower the barrier of packaging-related contributions. Best regards Ole [1] https://www.debian.org/social_contract#guidelines https://wiki.debian.org/DFSGLicenses [2] https://github.com/barry-scott/BarrysEmacs [3] https://wiki.debian.org/ITP [4] https://salsa.debian.org
Re: lintian errors packaging Barry's Emacs
On 27/12/2022 01:37, Santiago Vila wrote: El 26/12/22 a las 16:28, Barry Scott escribió: E: bemacs source: malformed-debian-changelog-version 8.9.3 (for non-native) [debian/changelog:1] It seems that the changelog issue is around lintian mandating a issue to close? I have no issue what do I put in the changelog? Or do I have to configure this check off? It's not related to closing issues. Look at the error message: it says [debian/changelog:1] that the error happens in the very first line of the debian/changelog, probably you wrote something like this as the very first line: bemacs (8.9.3) unstable; urgency=medium This is only ok if you are creating a native package. I assume your package is not native, so version should really be 8.9.3-1 for the first Debian revision, 8.9.3-2 for the second, and so on. Your guess is correct I did not have a in the changelog. I was going to ask where that was set. E: bemacs source: python3-depends-but-no-python3-helper bemacs This seems to mean that I need something in the rules file to make lintian be happy. My build system can set the shebang to what ever is expected. I have tried with /usr/bin/python3 and /usr/bin/python3.10 both get errors. Explanation here: https://lintian.debian.org/tags/python3-depends-but-no-python3-helper My advice here is to take a look at other Debian python packages. Happy to do that but I do not know how to go from a package like python3-brotli and find its source to read. I found https://sources.debian.org/ but I've failed to track down that package. I tried a couple of packages to hunt for. How do I go from a installed package and find its debian source? I'm guessing that I need to add a call to something, a macro expansion maybe that I can use in my build logic. When I do that I assume that lintian will be happy that I did things right in the build. E: bemacs source: source-is-missing [HTML/extn_intro.html] This I am baffled by. The named sources are in the bemacs_8.9.3.orig.tar.gz but this error claims they are not present. Explanation here: https://lintian.debian.org/tags/source-is-missing I read this and found myself none the wiser. It says this: "The source of the following file is missing. Lintian checked a few possible paths to find the source, and did not find it." No where does it say that lintian is assuming that the file is the result of machine generation from source that is not in the package. Did you really write extn_intro.html by hand from scratch, or maybe you created it from something else before putting it inside bemacs_8.9.3.orig.tar.gz? Yes I hand write HTML. FYI the original versions of these files is very old 30+ years ago and predate markdown etc. Lintian thinks it's the latter, hence the complain. If it's really the former, use a lintian override. I figured out the override to silence the error. Barry
Re: E: simpleprogram: unstripped-binary-or-object usr/bin/simpleprogram
Previous-Subject: Re: Lintian error about a simple program On Tue, Dec 27, 2022 at 11:02:44AM +0100, albert wrote: > L.S. > I have a simple program, created by an official Debian tool (fasm). $ apt show fasm 2>/dev/null | sed --silent -e '/^Description/,$p' Description: fast assembler for the x86 and x86-64 architectures Flat assembler is a fast, self-compilable assembly language compiler for the x86 and x86-64 architecture processors, which does multiple passes to optimize the size of generated machine code. > If I put it into a debian archive I get (among others complaints) > > E: lina: unstripped-binary-or-object usr/bin/lina > > I'm perfectly willing to strip lina > > ~/PROJECT/ciforths/ciforth$ strip lina > strip: error: the input file 'lina' has no sections > ~/PROJECT/ciforths/ciforth$ echo $? > 1 > > So strip refuses to work, moreover it gives an error, possibly > indicative of more problems. > > I can find a flag to give to strip to suppress the error condition it gives > back. (-: strip: error: the input file 'lina' has no sections :-) > My personal opinion is that lintian should check on superfluous > information, such as debugging symbols. The absence of sections should > exonerate a program from containing superfluous information. Acknowledge. And what is expected from sharing the personal opinion? In other words: If you don't know what the purpose of `strip` is, say so. If you see a possible improvement on Lintian, express it clearly. ( http://www.catb.org/~esr/faqs/smart-questions.html#idm368 ) Groeten Geert Stappers -- Silence is hard to parse
Source package origin file differs from the official archive
Hi. Any ideas how to fix the error below? I built my package with `gbp build-package` and uploaded with `dput -f mentors ../*.changes` Kind regards [1] Package source https://salsa.debian.org/go-team/packages/git-credential-oauth/-/merge_requests/3 -- Forwarded message - From: mentors.debian.net Date: Mon, 26 Dec 2022 at 01:48 Subject: git-credential-oauth_0.1.5-3_amd64.changes: REJECTED To: Hello, Unfortunately your package "git-credential-oauth" was rejected because of the following reason: Dsc is invalid Source package origin file differs from the official archive: Origin file : git-credential-oauth_0.1.5.orig.tar.gz sha256sum in upload : defc68ce1a25423423e17dea77e3b3627aa0f99a98f4758aef3e708327c2664c sha256sum in archive: 5c36b29368a13af6cf394cd689a5616d5eec3fca7dc862e50ea070eb4f6d154c Please try to fix it and re-upload. Thanks, -- mentors.debian.net
Lintian error about a simple program
L.S. I have a simple program, created by an official Debian tool (fasm). If I put it into a debian archive I get (among others complaints) E: lina: unstripped-binary-or-object usr/bin/lina I'm perfectly willing to strip lina ~/PROJECT/ciforths/ciforth$ strip lina strip: error: the input file 'lina' has no sections ~/PROJECT/ciforths/ciforth$ echo $? 1 So strip refuses to work, moreover it gives an error, possibly indicative of more problems. I can find a flag to give to strip to suppress the error condition it gives back. My personal opinion is that lintian should check on superfluous information, such as debugging symbols. The absence of sections should exonerate a program from containing superfluous information. Groetjes Albert
Bug#1027052: RFS: dh-runit/2.15.2 -- debhelper add-on to handle runit runscripts
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dh-runit": * Package name : dh-runit Version : 2.15.2 Upstream contact : Lorenzo Puliti * URL : https://salsa.debian.org/debian/dh-runit * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-runit Section : admin The source builds the following binary packages: dh-runit - debhelper add-on to handle runit runscripts runit-helper - dh-runit implementation detail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.15.2.dsc git repo: https://salsa.debian.org/debian/dh-runit/-/tree/next Changes since the last upload: dh-runit (2.15.2) unstable; urgency=medium . * bump Standards-Version * release to unstable Regards, Lorenzo Puliti
