Becoming Maintainer of Cinelerra
I would like to become a maintainer of a debian package for the cinelerra video editting software http://www.heroinewarrior.com/. I haven't seen any reference to any other effort or past effort for this software so I'm willing to take it up. There are rpm packages for cinelerra provided directly by the developers of it. I've used alien to install them, but I'd prefer to be able to apt-get them straight from a debian mirror. B This is my first attempt at making a debian package, but just about every other program I use already has a debian package. Though I have done a couple of rpm packages before. Cinelerra includes a lot of libraries in it that are available externally like libavc1394. Most of the libraries are already available as debian packages and are the same versions provided in unstable, but most are at least close to the same version. libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is in unstable. Should I remove them from the cinelerra source code and use the version in debian? Also, if I do so, then that will leave me with a huge diff file removing a lot of code from the original tarball, should I just find a way to disable them or slightly modify the original tarball just to remove those libraries? cinelerra has alsa-lib, audiofile, esound, freetype, libavc1394, libmpeg3, libraw1394, libsndfile, quicktime, tiff, toolame, libvorbis, libogg, libdv, ffmpeg, and probably some I've missed. -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C pgpMbsnGResnP.pgp Description: PGP signature
Becoming Maintainer of Cinelerra
I would like to become a maintainer of a debian package for the cinelerra video editting software http://www.heroinewarrior.com/. I haven't seen any reference to any other effort or past effort for this software so I'm willing to take it up. There are rpm packages for cinelerra provided directly by the developers of it. I've used alien to install them, but I'd prefer to be able to apt-get them straight from a debian mirror. B This is my first attempt at making a debian package, but just about every other program I use already has a debian package. Though I have done a couple of rpm packages before. Cinelerra includes a lot of libraries in it that are available externally like libavc1394. Most of the libraries are already available as debian packages and are the same versions provided in unstable, but most are at least close to the same version. libraw1394 version 0.9.0 is in the cinelerra and version 0.10.1 is in unstable. Should I remove them from the cinelerra source code and use the version in debian? Also, if I do so, then that will leave me with a huge diff file removing a lot of code from the original tarball, should I just find a way to disable them or slightly modify the original tarball just to remove those libraries? cinelerra has alsa-lib, audiofile, esound, freetype, libavc1394, libmpeg3, libraw1394, libsndfile, quicktime, tiff, toolame, libvorbis, libogg, libdv, ffmpeg, and probably some I've missed. -- I sense much NT in you. NT leads to Bluescreen. Bluescreen leads to downtime. Downtime leads to suffering. NT is the path to the darkside. Powerful Unix is. Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C pgp0s2waN6zEI.pgp Description: PGP signature
Looking for sponsor with update for Debian package
Hello, I noticed that the rpm package was getting slightly stale and is listed as an RFA package so I decided to take some time to help get an update out for it. As the RPM 4.19.x branch has changed the underlying build system, it will require a little more work which I am still in the middle of completing, but I have finished an update to bring it up to the latest 4.18.x which is still supported upstream. As I don't currently have access to Salsa, I have put a copy of the repo up on my site here: http://www.north-winds.org/git/rpm.git I don't currently have a VCS browser so it will need to be cloned to review it. I also published a source package here: http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg-1.debian.tar.xz http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg-1.dsc http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg-1_source.build http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg-1_source.buildinfo http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg-1_source.changes http://www.north-winds.org/unix/rpm/rpm_4.18.2+dfsg.orig.tar.xz Once I finish fixing a couple issues with 4.19.x, I hope to have that as well. What are the next steps to get this pushed as a proposed update for this package? I am looking towards possibly becoming a sponsored maintainer and onward. Thank you, -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B signature.asc Description: PGP signature
Re: Looking for sponsor with update for Debian package
On Sun, Jan 21, 2024 at 11:36:37AM +0100, Hilmar Preuße wrote: > On 21.01.24 11:29, Loren M. Lang wrote: > > Hi, > > > As I don't currently have access to Salsa, I have put a copy of the > > repo up on my site here: > > > > http://www.north-winds.org/git/rpm.git > > > Just for the records: Yes, I don't have a CGI Web browser for the VCS so it can't be viewed with standard HTTP clients, but it is accessible to git if cloned: $ git clone http://www.north-winds.org/git/rpm.git Cloning into 'rpm'... Fetching objects: 26455, done. Maybe I should throw it up on GitHub or somewhere else with a browser, but I didn't see a need to for this review. > > hille@haka2:~$ LANG=C wget http://www.north-winds.org/git/ > --2024-01-21 11:35:25-- http://www.north-winds.org/git/ > Resolving www.north-winds.org (www.north-winds.org)... 2001:470:e9d7::101, > 50.126.69.19 > Connecting to www.north-winds.org > (www.north-winds.org)|2001:470:e9d7::101|:80... connected. > HTTP request sent, awaiting response... 403 Forbidden > 2024-01-21 11:35:25 ERROR 403: Forbidden. > > Same for http://www.north-winds.org/git/rpm.git . > > H. > -- > Testmail > -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B signature.asc Description: PGP signature
Question on why package was rebuilt
Hello, I recently had a package sponsors and entered into unstable called tiv. It can be seen here: https://packages.debian.org/sid/tiv Everything went OK, but I see that the amd64 arch package appears to have been re-built for some reason. It's version is showing up with a +b1. I am curious if there is some long to indicate what the issue might have been that led to a rebuild. Could there have been a compilation issue or other things I should be concerned about or is it likely something harmless? Is there a log for this case? -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Handling a file with mixed copyrights
I have a project where most files are under the original author copyright and license, but within one source file, there is a different copyright as it is copied from another source. The section of code in question is delineated with comments indicating the start and end. It is under a different copyright and license that the rest of the file or source tree, in general. How should I best indicate this in d/copyright? My current approach is to have a Files: * stanza which is the majority of the source tree and a separate Files: stanza pointing to this specific file with it's copyright and license. In the comments property, I'll indicate that this stanza only applies to a section of this file as delineated by comments and that the rest of the file should be in the default copyright and license listed above. Is this sufficient? Here is the code in question: https://github.com/brave/adblock-rust/blob/dd970f26bc5877bef68f9e29d26db19c2f65b34b/src/resources/resource_storage.rs#L23 And here is my current example: https://salsa.debian.org/penguin359/debcargo-conf/-/blob/e8d22158840e1e40385e7f01dceaa0074b4d37e4/src/adblock/debian/copyright#L32 Thanks, -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Does a rejected package require a version bump?
My original submission was rejected while in the FTP Master's NEW queue and required a minor correction. Should I bump the version with a new changelog entry when I resubmit it or should I just keep it at the initial entry? -- Sent from my Nexus 4 with K-9 Mail. Please excuse my brevity.
Is FTP Master's NEW queue handled manually?
This is just for my own curiosity and understanding. Is the NEW queue on FTP Master handled entirely manually? I see a number of packages that go back quite a few months, however, it's not exactly clear to me what kind of things are holding those packages up at least from looking at the website. For example, looking at stac-validator, I see it's been in the queue for 6 months now looking at the bug report linked for it, there doesn't seem to be any indication of what might be holding it up. Is every item in this queue ultimately waiting for a human to give it a green light or is there some automated check that might block them? I'm just trying to better understand the process here and how to tell what is holding a package back when it's been in the queue for months. I have nothing myself so it's just for understanding. -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Naming a new package for Debian
Hello, I am working on packaging a new program for Debian. I currently have it successfully Debianized and the binary package installs and works, but I still need to complete some metadata on it and fix the remaining Lintian errors/warnings. However, I have a question on how to name the package. It seems to generally be referred to by it's executable name, tiv, which stands for Terminal Image Viewer. I was going to name the Debian package tiv, but I don't know if that's recommended to have such a short package name for a very specific piece of software. The GitHub repo for it is called TerminalImageViewer, but when it's compiled and installed, it is named tiv. The other, longer package name I was considering was terminal-image-viewer, but that might lead to confusion by a user installing it. https://github.com/stefanhaustein/TerminalImageViewer As another example, I did see an X11 image viewer that was just named feh after it's executable so that might not be a big issue. And second, this might be a question for a different list, but I'm not sure how to best enter in the license information. According to their LICENSE file, it can be redistributed under either the GPL 3.0 license or the Apache 2.0 Software License, both approved for Debian. I was considering just listing it as one of them, but I don't know if that's proper. -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B
Bug#1062534: RFS: tiv/1.2.1+dfsg-1 [ITP] -- high-resolution command-line image viewer
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "tiv": * Package name : tiv Version : 1.2.1+dfsg-1 Upstream contact : Stefan Haustein * URL : https://github.com/stefanhaustein/TerminalImageViewer * License : GPL-3+ or Apache-2.0 * Vcs : https://salsa.debian.org/penguin359/tiv Section : graphics The source builds the following binary packages: tiv - high-resolution command-line image viewer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/tiv/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/tiv/tiv_1.2.1+dfsg-1.dsc Changes for the initial release: tiv (1.2.1+dfsg-1) unstable; urgency=low . * Initial release. Closes: #1062455 Regards, -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Re: Looking for sponsor with update for Debian package
On Sun, Jan 21, 2024 at 03:12:41PM +0100, Norwid Behrnd wrote: > @Loren As an sponsored maintainer and hence subscriber to this mailing list, I > think a subject line with a specific ticket number, package name and -- in the > particular case -- the acronym RFS would ease to follow up the progress of > your work. Ideally it were the template reaching level 4 / Find a sponsor[1] > offers. Thank you for your feedback. While I am a long-time Debian user and built packages for personal use, this is my first attempt to contribute back so am still learning the process. I will work on filing a proper RFS bug report with the template as documented on the Mentors Wiki. > > Inferring from your message filed by Sun, 21 Jan 2024 02:29:20 -0800 your work > relates to rpm[2] with its RFA[3] (and hence, an existing ticket) I fetched a > fork by > > ``` > git clone http://www.north-winds.org/git/rpm.git > ``` > > File `/debian/changelog` for your new version 4.18.2+dfsg-1 does not > explicitly mention to close (including the corresponding ticket numbers, and > a `closes: #NNN`) one of the bugs currently (15:10 UTC +1) listed on > https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=rpm. If > your work addressed them, may you amend accordingly the changelog file? Yes, I will upload the changelog. So the standard procedure it to normally file a bug report first so the changelog can be updated to reflect it and then the source package can be generated for upload? > > Are you member of the pkg-rpm-team? If not, and if the package now were > maintained by you, a successful upload to Debian likely might require an > update of debian/control, in lines of `Vcs-Browser:` and `Vcs-Git:`. I have sent a request to join the team from the email in the Maintainers field. I also looked at the Team page, but they reference a non-existent mailing list on Alioth. https://wiki.debian.org/Teams/pkg-rpm I don't plan to move the Git hosting from Salsa. My branches are based on the latest tip from the repo on Salsa and my goal is that that are just merged into that repo. > > Best regards, > > Norwid > > [1] https://mentors.debian.net/intro-maintainers/ > [2] https://tracker.debian.org/pkg/rpm > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923352 > -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: ftp://ftp.north-winds.org/pub/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
How to handle marked for removal
Hello Mentors, I was notified that a package of mine is now marked for removal in testing due to the time_t change. This seems to be with packages that are indirect build dependencies. I don't see anything in my own package that uses time_t or date/time operations. I just want to know what my responsibility is for maintaining my package through this. As it does not seem to be my direct build dependency, I'm not sure if I even need to consider rebuilding anything. My specific package is tiv which has a build-dep on cimg-dev and it seems somewhere down the line it has this: 1062125: gimp: NMU diff for 64-bit time_t transition https://bugs.debian.org/1062125 1063178: nifticlib: NMU diff for 64-bit time_t transition https://bugs.debian.org/1063178 Do I need to respond or just wait it out? Thanks -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Re: Remove package from unstable?
On Mon, Mar 04, 2024 at 12:09:26AM +0100, Hilmar Preuße wrote: > On 29.02.24 00:42, Lyndon Brown wrote: > > Hello, > > > b) Re-upload 2.10.08+ds-1 with a version number like '2.11.01+ds-3- > > really2.10.08+ds-1', such that it will count as a higher version number > > than the mistaken upload of 2.11.01+ds-3 and thus replace it in package > > upgrades. You'd then continue with this pattern for 2.10.x updates > > until the eventual proper migration of 2.11 to unstable, at which point > > you can simplify the version numbering back to '2'11.x'. > > > > I'm sure you'll agree that option B would probably be preferable. > > > > Yes, agreed. Currently I'm trying to find out how to reflect that downgrade > in my gbp style git repository. > > I try to build my source package by calling "gbp buildpackage > --git-upstream-tree=upstream_2.10.08+ds", where "upstream_2.10.08+ds" is a > new upstream branch containing the source code for version 2.10.08. It tries > to build the binary package, which fails b/c the BD's are not fulfilled. > However I just need the source package. How I can prevent from running > "dpkg-buildpackage -us -uc -ui -i -I", I just need "dpkg-buildpackage > -S". Have you just tried passing through -S from gbp? As in "gbp buildpackage -S"? It might not work if you have set a different builder like schroot, but you can just pass --git-builder=debuild or similar in that case. > > Hilmar > -- > Testmail > -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
Re: Bug#1065078: Question about the debian group on Salsa
On Sun, Mar 03, 2024 at 12:02:36AM -0700, Soren Stoutner wrote: > Loren, > > Yes, I would say that is generally correct. If you have a package that is > team maintained, it is best under the team namespace. If it is not team > maintained, it is generally best under the debian namespace (which is the > team > of all Debian Developers). It makes it easier for others to pick up if > something happens to you. > > However, there may be specific cases where you do want to keep it in your own > namespace. I maintain one package where I am also the upstream developer. I > keep the Debian packaging in my own namespace because I want to have a very > high threshold for other people making changes to it. At this stage, if > something were to happen to me, both the Debian package and the upstream > project would need to be adopted by someone else, which would probably > necessitate a renaming of the project. Down the road, I would like to get > more people involved in both the upstream development and the Debian > packaging. When that happens I will probably move the Salsa project to a > team > namespace. > > There is certainly nothing wrong with keeping your project under your own > namespace, but if you would like to move it to the debian namespace, grant me > full access to it (my Salsa username is soren) and I can then move it to the > debian namespace and grant you full access to the project there. Thanks! I've granted you full access to https://salsa.debian.org/penguin359/tiv -Loren > > Soren > > On Saturday, March 2, 2024 11:34:14 PM MST Loren M. Lang wrote: > > On Sat, Mar 02, 2024 at 01:11:46AM +0100, Salvo Tomaselli wrote: > > > In data venerdì 1 marzo 2024 05:12:51 CET, Soren Stoutner ha scritto: > > > > Generally you should create the repository under the debian namespace > > > > > > You need to ask a DD to do that. Non DD don't have permissions for this. > > > > So is having all packages (at least those not maintained by a team) > > under the debian/ namespace considered a best practice for all but the > > most sensitive of packages? Should I actually have my own package > > transfered to this namespace? > > > > I just have a small, CLI package that I maintain alone and, since I > > don't have DD permissions, just assumed that I should put it under my > > own namespace. Is it recommended to just keep it under the neutral > > debian namespace just in case I am no longer able to keep it maintained > > in the future? > > > > My current package is https://salsa.debian.org/penguin359/tiv > > > > -Loren > > -- > Soren Stoutner > so...@debian.org -- Loren M. Lang lor...@north-winds.org http://www.north-winds.org/ Public Key: http://www.north-winds.org/lorenl_pubkey.asc Fingerprint: 7896 E099 9FC7 9F6C E0ED E103 222D F356 A57A 98FA signature.asc Description: PGP signature
