Bug#953685: ITP: ruby-guard-rspec -- Guard gem for RSpec
Package: wnpp Severity: wishlist Owner: hacksk X-Debbugs-CC: debian-devel@lists.debian.org * Package name : ruby-guard-rspec Version : 4.7.3 Upstream Author : 2010-2016 Thibaud Guillaume-Gentil * URL : https://github.com/guard/guard-rspec * License : Expat Programming Lang: Ruby Description : Guard gem for RSpec Guard::RSpec automatically run your specs (much like autotest). . This allows to automatically & intelligently launch specs when files are modified.
Bug#953722: ITP: josm-installer -- Editor for OpenStreetMap (installer)
Package: wnpp Severity: wishlist Owner: Bas Couwenberg * Package name: josm-installer Version : 0.0.1+svn16006 Upstream Author : Bas Couwenberg * URL : https://salsa.debian.org/debian-gis-team/josm-installer * License : GPL-2+ Programming Lang: Python Description : Editor for OpenStreetMap (installer) JOSM is an editor for OpenStreetMap (OSM) written in Java. The current version supports stand alone GPX tracks, GPX track data from OSM database and existing nodes, line segments and metadata tags from the OSM database. . OpenStreetMap is a project aimed squarely at creating and providing free geographic data such as street maps to anyone who wants them. The project was started because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive or unexpected ways. . This package provides a script to install the upstream JARs. The upstream source tree no longer includes all its dependencies, this makes it too cumbersome to provide backports of JOSM, as that also requires backporting all dependencies which will break other reverse dependencies in stable. This package provides a script to download the pre-built JAR from upstream and the application metadata for integration in desktop environments. The package will be maintained with in the Debian GIS team where it will eventually replace the josm package.
Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
Hi, On Fri, Dec 27, 2019 at 04:54:32PM +0100, Jonas Smedegaard wrote: > Quoting Mo Zhou (2019-12-27 02:56:07) > > I created an amount of NEW packages as a DD, and reviewed an amount of > > NEW packages in the NEW queue as FTP trainee. > > Great. Also because your experience as FTP trainee sheds some light on > what may actually aid ftpmaster processing (rather than guessing blindly > from the outside). > > > > Existing tools, workflows; And limitations > > -- > > > > ## Tools > > > > https://wiki.debian.org/CopyrightReviewTools > > > > I'm unfamiliar with most of them. I'm only describing the two I'm > > familiar with. Both licensecheck (Jonas) and debmake (Osamu) do > > template/regex matching. > > Beware that debmake pattern matching and debian/copyright file > serialization is far inferior to that of licensecheck. FYI: I agree ;-) > Long description of debmake claims it "does more than what > licensecheck(1) offers" but I am puzzled what that sentence means - more > polished experience (even if less accurate), perhaps? The licensecheck command before Smedegaard's work which used to reside in devscripts package is what debmake talks about. It took sometime for me to get debmake's internal licensechecking ready. Just about as I released debmake, licensecheck was split and made good progress if I remember correctly. My #1 homework for debmake is to remove internal licensechecking and let it call Smedegaard's licensecheck ;-) debmake should be thin glue to call purpose focused command. ... > Sorry, I cannot help write a UI frontend in Python. > > I might be intrigued to try put together a competing frontend in Perl, > but I have too much on my plate already, so likely wouldn't make enough > time for that. Same here. Osamu
Re: Idea: frontend tool for more efficient license reviewing based on tree-structured IR
Quoting Osamu Aoki (2020-03-12 14:52:24) > On Fri, Dec 27, 2019 at 04:54:32PM +0100, Jonas Smedegaard wrote: > > Long description of debmake claims it "does more than what > > licensecheck(1) offers" but I am puzzled what that sentence means - > > more polished experience (even if less accurate), perhaps? > > The licensecheck command before Smedegaard's work which used to reside > in devscripts package is what debmake talks about. It took sometime > for me to get debmake's internal licensechecking ready. Just about as > I released debmake, licensecheck was split and made good progress if I > remember correctly. Ahh, thanks Aoki-san, for the explanation. The package description makes sense to me now :-) Licensecheck has improved a lot since it was split from devscript 3.5 years ago, and I see now that dbmake simply hasn't been updated for quite some time (which I guess is a _good_ sign!). I now filed a bugreport requesting update of long description to avoid confusion. > My #1 homework for debmake is to remove internal licensechecking and > let it call Smedegaard's licensecheck ;-) debmake should be thin glue > to call purpose focused command. Please do. Also, please file wishlist bugreports against licensecheck for any ideas you might have for information you would like licensecheck to gather and ways to most optimally pass it to your use: I am (still, 3.5 years in) working on reorganizing the code into reusable libraries, and requests and dreams from users are quite helpful. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Packaging new library very similar to another library
On Tue, Mar 10, 2020 at 2:38 PM Aaron Boxer wrote: > > > On Tue, Mar 10, 2020 at 8:46 AM Sudip Mukherjee < > sudipm.mukher...@gmail.com> wrote: > >> On Tue, Mar 10, 2020 at 12:29 PM Aaron Boxer wrote: >> > >> > Thanks, Sudip! I've made those changes, and renamed the library to >> grok-jpeg2000 >> > >> > The only thing missing right now is the copyright file. Is there a way >> of automatically parsing all >> > .cpp/.h files in the project and generating a list of the copyrights ? >> >> There are some tools, you can check >> https://wiki.debian.org/CopyrightReviewTools >> But you will need to check manually also to verify what the tool has >> given is actually correct. >> > > Besides the copyright file, I would like to test building the package. What's the best way of doing this? I am on Ubuntu Eoan. Thanks!
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 12:49:25PM -0400, Aaron Boxer wrote: > Besides the copyright file, I would like to test building the package. > What's the best way of doing this? I am on > Ubuntu Eoan. Thanks! Get a sid system (chroot is probably fine). Install and configure pbuilder or sbuild there. You will also need this system to actually test the resulting package and act on bug reports, if you want to maintain this package in sid. I don't recommend running any packaging tools on non-sid, especially on Ubuntu, unless you know the difference in behavior. -- WBR, wRAR signature.asc Description: PGP signature
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 1:00 PM Andrey Rahmatullin wrote: > On Thu, Mar 12, 2020 at 12:49:25PM -0400, Aaron Boxer wrote: > > Besides the copyright file, I would like to test building the package. > > What's the best way of doing this? I am on > > Ubuntu Eoan. Thanks! > Get a sid system (chroot is probably fine). Install and configure pbuilder > or sbuild there. You will also need this system to actually test the > resulting package and act on bug reports, if you want to maintain this > package in sid. > I don't recommend running any packaging tools on non-sid, especially on > Ubuntu, unless you know the difference in behavior. > Thanks, Andrey. I have followed steps to set up sid system with schroot. How can I test package build using rules file ? > > -- > WBR, wRAR >
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 01:17:29PM -0400, Aaron Boxer wrote: > On Thu, Mar 12, 2020 at 1:00 PM Andrey Rahmatullin wrote: > > > On Thu, Mar 12, 2020 at 12:49:25PM -0400, Aaron Boxer wrote: > > > Besides the copyright file, I would like to test building the package. > > > What's the best way of doing this? I am on > > > Ubuntu Eoan. Thanks! > > Get a sid system (chroot is probably fine). Install and configure pbuilder > > or sbuild there. You will also need this system to actually test the > > resulting package and act on bug reports, if you want to maintain this > > package in sid. > > I don't recommend running any packaging tools on non-sid, especially on > > Ubuntu, unless you know the difference in behavior. > > > > Thanks, Andrey. I have followed steps to set up sid system with schroot. > How can I test package build using rules file ? Install and configure pbuilder or sbuild there. Build your package using that. -- WBR, wRAR signature.asc Description: PGP signature
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 1:26 PM Andrey Rahmatullin wrote:
> On Thu, Mar 12, 2020 at 01:17:29PM -0400, Aaron Boxer wrote:
> > On Thu, Mar 12, 2020 at 1:00 PM Andrey Rahmatullin
> wrote:
> >
> > > On Thu, Mar 12, 2020 at 12:49:25PM -0400, Aaron Boxer wrote:
> > > > Besides the copyright file, I would like to test building the
> package.
> > > > What's the best way of doing this? I am on
> > > > Ubuntu Eoan. Thanks!
> > > Get a sid system (chroot is probably fine). Install and configure
> pbuilder
> > > or sbuild there. You will also need this system to actually test the
> > > resulting package and act on bug reports, if you want to maintain this
> > > package in sid.
> > > I don't recommend running any packaging tools on non-sid, especially on
> > > Ubuntu, unless you know the difference in behavior.
> > >
> >
> > Thanks, Andrey. I have followed steps to set up sid system with schroot.
> > How can I test package build using rules file ?
> Install and configure pbuilder or sbuild there. Build your package using
> that.
>
Thanks, I am using
dpkg-buildpackage -us -uc
but I get the following error:
dpkg-source: error: can't build with source format '3.0 (quilt)': no
upstream tarball found at ../grok-jpeg2000_4.2.0.orig.tar.{bz2,gz,lzma,xz}
Where is it looking for the tarball ?
> --
> WBR, wRAR
>
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 02:05:48PM -0400, Aaron Boxer wrote:
> > > > > Besides the copyright file, I would like to test building the
> > package.
> > > > > What's the best way of doing this? I am on
> > > > > Ubuntu Eoan. Thanks!
> > > > Get a sid system (chroot is probably fine). Install and configure
> > pbuilder
> > > > or sbuild there. You will also need this system to actually test the
> > > > resulting package and act on bug reports, if you want to maintain this
> > > > package in sid.
> > > > I don't recommend running any packaging tools on non-sid, especially on
> > > > Ubuntu, unless you know the difference in behavior.
> > > >
> > >
> > > Thanks, Andrey. I have followed steps to set up sid system with schroot.
> > > How can I test package build using rules file ?
> > Install and configure pbuilder or sbuild there. Build your package using
> > that.
> >
>
> Thanks, I am using
>
> dpkg-buildpackage -us -uc
I told you to use pbuilder or sbuild. They would give the same error, but
still.
> but I get the following error:
>
> dpkg-source: error: can't build with source format '3.0 (quilt)': no
> upstream tarball found at ../grok-jpeg2000_4.2.0.orig.tar.{bz2,gz,lzma,xz}
> Where is it looking for the tarball ?
Just like it tells you, in the parent directory. Did you put it there?
Note that it needs to have a specific name.
--
WBR, wRAR
signature.asc
Description: PGP signature
Re: Packaging new library very similar to another library
On Thu, Mar 12, 2020 at 3:21 PM Andrey Rahmatullin wrote:
> On Thu, Mar 12, 2020 at 02:05:48PM -0400, Aaron Boxer wrote:
> > > > > > Besides the copyright file, I would like to test building the
> > > package.
> > > > > > What's the best way of doing this? I am on
> > > > > > Ubuntu Eoan. Thanks!
> > > > > Get a sid system (chroot is probably fine). Install and configure
> > > pbuilder
> > > > > or sbuild there. You will also need this system to actually test
> the
> > > > > resulting package and act on bug reports, if you want to maintain
> this
> > > > > package in sid.
> > > > > I don't recommend running any packaging tools on non-sid,
> especially on
> > > > > Ubuntu, unless you know the difference in behavior.
> > > > >
> > > >
> > > > Thanks, Andrey. I have followed steps to set up sid system with
> schroot.
> > > > How can I test package build using rules file ?
> > > Install and configure pbuilder or sbuild there. Build your package
> using
> > > that.
> > >
> >
> > Thanks, I am using
> >
> > dpkg-buildpackage -us -uc
> I told you to use pbuilder or sbuild. They would give the same error, but
> still.
>
> > but I get the following error:
> >
> > dpkg-source: error: can't build with source format '3.0 (quilt)': no
> > upstream tarball found at
> ../grok-jpeg2000_4.2.0.orig.tar.{bz2,gz,lzma,xz}
> > Where is it looking for the tarball ?
> Just like it tells you, in the parent directory. Did you put it there?
> Note that it needs to have a specific name.
>
Thanks, solved via
dpkg-buildpackage -b -rfakeroot -us -uc
>
> --
> WBR, wRAR
>
Seeking sponsor for new package
Hello! As you may have seen, I am interested in packaging my image compression library for debian: https://github.com/GrokImageCompression/grok I've tested the packaging locally and as far as I can tell, it's all working correctly. The only thing missing now is a properly updated copyright file. Would anyone here be interested in helping get this package submitted ? Thanks! Aaron
Re: Seeking sponsor for new package
Hi Fabrice, Thanks so much for your reply. This makes sense. I will try git-buildpackage, and I will move the source + debian packaging to a separate branch. Best, Aaron On Thu, Mar 12, 2020 at 7:28 PM Fabrice BAUZAC-STEHLY wrote: > Hello Aaron, > > I'm a newbie in Debian packaging, but here is the first and foremost > thing that seems wrong to me in your grok git repository: > > It looks like you are mixing debian-specific commits with commits of > the main software (distribution-independent). I think you should use > one repository that is distribution-independent (without any debian/ > subdirectory), and a specific distinct directory dedicated to the > debian packaging of the main software, because the two entities have > different lifecycles: you (or someone else) may want to package the > same main software for a few more distributions. > > You have several ways to manage your debian/ directory; I think > popular options include: > > - using git-buildpackage > - having a git repository containing just the debian/ subdirectory > - not using any VCS for the debian packaging (it appears that commands > like "apt-get source" in package devscripts already do wonders > without the need for a version control system) > > Hope this helps! > > Best regards > > -- > Fabrice BAUZAC-STEHLY > PGP 015AE9B25DCB0511D200A75DE5674DEA514C891D >
Work-needing packages report for Mar 13, 2020
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1238 (new: 3) Total number of packages offered up for adoption: 237 (new: 0) Total number of packages requested help for: 63 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: diff-match-patch (#953452), orphaned 3 days ago Description: diff/match/patch algorithms implemented in JavaScript Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/953452 netxx (#953451), orphaned 3 days ago Description: C++ library for network programming Reverse Depends: libnetxx-dev Installations reported by Popcon: 20 Bug Report URL: https://bugs.debian.org/953451 openmama (#953453), orphaned 3 days ago Description: message oriented middleware - Wombat utility libraries Reverse Depends: libmama-dev libmama0 libmamaavis0 libmamacpp0 libmamajni-java libmamda-book-java libmamda-dev libmamda-java libmamda-options-java libmamda0 (4 more omitted) Installations reported by Popcon: 5 Bug Report URL: https://bugs.debian.org/953453 1235 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 237 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 516 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc courier-webadmin cvsweb debbugs-web dms-wsgi doc-central (138 more omitted) Installations reported by Popcon: 97466 Bug Report URL: https://bugs.debian.org/910917 autopkgtest (#846328), requested 1198 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker Installations reported by Popcon: 1166 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3091 days ago Description: An e-mail client for GNOME Installations reported by Popcon: 702 Bug Report URL: https://bugs.debian.org/642906 broadcom-sta (#886599), requested 794 days ago (non-free) Description: Broadcom STA Wireless driver (non-free) Installations reported by Popcon: 1730 Bug Report URL: https://bugs.debian.org/886599 cargo (#860116), requested 1066 days ago Description: Rust package manager Reverse Depends: dh-cargo Installations reported by Popcon: 1648 Bug Report URL: https://bugs.debian.org/860116 cyrus-imapd (#921717), requested 398 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 426 Bug Report URL: https://bugs.debian.org/921717 cyrus-sasl2 (#799864), requested 1632 days ago Description: authentication abstraction library Reverse Depends: 389-ds-base adcli autofs-ldap cyrus-caldav cyrus-clients cyrus-common cyrus-dev cyrus-imapd cyrus-imspd cyrus-murder (78 more omitted) Installations reported by Popcon: 202129 Bug Report URL: https://bugs.debian.org/799864 dee (#831388), requested 1336 days ago Description: model to synchronize mutiple instances over DBus Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-dev zeitgeist-core Installations reported by Popcon: 35382 Bug Report URL: https://bugs.debian.org/831388 developers-reference (#759995), requested 2021 days ago Description: guidelines and information for Debian developers Installations reported by Popcon: 7119 Bug Report URL: https://bugs.debian.org/759995 devscripts (#800413), requested 1626 days ago Description: scripts to make the life of a Debian Package maintainer easier Reverse Depends: apt-build apt-listdifferences aptfs arriero brz-debian buildd customdeb debci debian-builder debmake (32 more omitted) Installations reported by Popcon: 11828 Bug Report URL: https://bugs.debian.org/800413 docker.io (#908868), requested 544 days ago Description: Linux container runtime Reverse Depends: docker-clean golang-github-containers-buildah-dev golang-github-containers-image-dev golang-github-fsouza-go-dockerclient-dev golang-github-openshift-imagebuilder-dev
Bug#953761: ITP: golang-vbom-util -- Go utility packages
Package: wnpp Severity: wishlist Owner: Tong Sun * Package name: golang-vbom-util Version : 0.0~git20180919.efcd4e0-1 Upstream Author : * URL : https://github.com/fvbommel/util * License : Expat Programming Lang: Go Description : Go utility packages Go utility packages. Dependency of github.com/google/go-containerregistry & github.com/GoogleContainerTools/container-diff. This hasn't been uploaded yet, and also need to be updated to the latest version.
