Bug#564533: Current unofficial package maintainer intends to package for Debian
Package: wnpp Followup-For: Bug #564533 Owner: Paul Boddie I am the current maintainer of the aforementioned unofficial package and have been attempting to upload a suitable package to Debian Mentors. It occurs to me that an ITP is necessary for that service to agree to process my packages (instead of apparently ignoring them). -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#564533: Deb source package
On Thursday 04 March 2010 19:16:52 D Haley wrote: > Hello Paul, > > Have you uploaded this to mentors or provided a DSC somewhere? I am happy > to have a brows through it -- I maintain one package in debian currently, > so I am no expert, but I can run my eye over it if you have a link. Here's the mentors link: http://mentors.debian.net/cgi-bin/sponsor-pkglist?action=details;package=shedskin I aim to refresh this packaging soon to take various changes into account, notably the resolution of some uncertainty around the licensing of various contributions. Thanks for taking an interest! Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003042204.36120.p...@boddie.org.uk
Bug#564533: Deb source package
On Thursday 04 March 2010 22:56:27 D Haley wrote: > OK, so here are my comments. Feel free to ignore whatever you like, as I am > often not right. Here goes! > * Lintian is giving native package errors. If you do a quick source build > with debuild (debuild -S -i -I), this will tell you what your tarball > should be called, so as to aid navigating this annoying notation. I really need to concentrate on proper version identifiers. Previously I had the ubuntu stuff in these version identifiers, and there are other issues about targeting unstable which I think I've fixed in this packaging. > * I got a warning whilst building source package.. Are you seeing this? > > dpkg-source: warning: diff > `~/Documents/deb/shedskin/shedskin_0.3-2.diff.gz.new.Haj083' doesn't > contain any patch I should note that I've only tested this with pbuilder. See this page for my methods: http://packages.boddie.org.uk/ > *The permissions from the DSC are a bit odd? Everything in debian/ seems to > be 755? should it not be 644 (except rules I think)? I'll check this. > * Shouldn't the description be wrapped at 80 chars in debian/control, with > each new line preceded by a space? I've left the first line as a one-line description as this seems to be the convention. Maybe there's a line break in there for clarity, but it is wrapped to either 78 or 80 lines. > *In debian/copyright, there are some chars that are not showing properly: > > 75 Copyright (c) 2009 Jérémie Roquet This is UTF-8-encoded text: if there's an encoding declaration I should add, could you perhaps point me to the appropriate documentation? > * Standards version is old school. Should be 3.8.4 (or maybe even later...) I must admit that I generally don't follow the standards versions and just propagate what I find in contemporary packages. Hints welcome! > * debina/changelog seems to contain program changes, rather than package > changes? changelog should be package only AFAIK. Any program changes should > be hopefully distributed by upstream I guess I've misunderstood this. I always thought that it was a standardised summary of changes, which would be really useful, of course. > * adding a watchfile is good (debian/watch) This is the repository/upstream monitoring, right? > * You may have been alluding to this before, but does the GPL trump the > AS-IS free stuff, as you are building them together? Particularly section > 5b > > " > b) The work must carry prominent notices stating that it is > released under this License and any conditions added under section > 7. This requirement modifies the requirement in section 4 to > "keep intact all notices". > " > You may need to contact upstream and ask them to sort this out, once a > correct course of action has been identified. I haven't pursued this vigourously yet, but obviously they need to retain original notices. Adding the GPL notices is a "best practice" for affected files, but it should be noted that the project maintainer intends to have the library files under a permissive or weak copyleft licence. > * Keeping this on a VCS somewhere would be nice, makes it easy for other > packagers to pull down your package at some later date. This integrates > neatly with the debian PTS. to do this just set Vcs-Git/Vcs-Svn or whatever > in debian/control It's actually here: https://hg.boddie.org.uk/shedskin-packaging/ I'll add the field. Apologies for the certificate! I may end up just doing HTTP for this site. > *I get a warning whilst attempting to build the binary version. > > dpkg-deb: warning: 'debian/shedskin/DEBIAN/control' contains user-defined > field 'Python-Version' I guess this is some policy-related stuff that should have been discarded a long time ago. > *Make clean still appears to leave files behind (build-python-*, > debian/shedskin.1.gz, ...). I usually use a VCS to help me work out if I > have accidently not done a proper clean (do a commit, then see what changes > before and after clean using fakeroot make -f debian/rules clean ). I'll look into this. The rules file is still a bit of a mystery to me. > * Lintian outputs a good wad of errors and warnings: [...] > Hope thats not too much! Much of that was already explained above. I'll take a look at these warnings and try and improve the quality. My role in this has been to try and nudge Shed Skin closer to "proper Debian" status based on some fairly informal packaging I've done for myself before, so if anything I'll learn how to make cleaner packages. Thanks for the feedback! Paul -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003050129.04680.p...@boddie.org.uk
Bug#820593: [Calendarserver-discuss] Bug#820593: ITP: imip-agent -- agent programs to handle calendar information in e-mail
On Sunday 10. April 2016 13.48.50 Jonas Smedegaard wrote: > Package: wnpp > Severity: wishlist > Owner: Jonas Smedegaard Thanks for looking into this! I'll put some thoughts and notes here so that they don't get lost. Multiple Packages - In previous informal discussions, the idea of multiple packages providing the sum of the different parts has been suggested, and I think that there would need to be a basic package that provides the core functionality (mail handling) plus a package that provides the Web functionality. The basic package would include the imiptools Python package, and the imip_person.py, imip_person_outgoing.py and the imip_resource.py programs. It would provide the tools to administer the data store. It would probably provide the locale/message resources even though some of them are intended for the Web functionality. The Web package would include the imipweb Python package, and the imip_manager.py program. It would provide the htdocs directory. Bundled Libraries - There are some files that are arguably bundled: markup.py originates from a SourceForge project but has been modified to fix various things: http://markup.sourceforge.net/ vCalendar.py, vContent.py and vRecurrence.py originate from a separate project of mine, but they are unlikely to have been used in anyone else's projects; ideally, they would be packaged separately as a plain Debian library package. Configuration for Other Packages As far as configuration is concerned, I've looked for other packages that provide standalone configuration fragments for Exim, but there really isn't much I can find... fusionforge has a fearsome shell script that generates "router" definitions: http://sources.debian.net/src/fusionforge/6.0.3%2B20151023-1/post- install.d/mta-exim4/mta-exim4.sh/ whereami has a shell script for MTA configuration: http://sources.debian.net/src/whereami/0.3.34-0.3/scripts/setmailrelay/ virtuoso-opensource just provides fragments in the documentation: http://sources.debian.net/src/virtuoso- opensource/6.1.6%2Bdfsg2-3/binsrc/maildrop/INSTALL/ I couldn't really find anything else of relevance. I hope these notes are helpful. Paul
Bug#1051352: ITP: shedskin -- Python-to-C++ compiler designed to speed up Python programs
Package: wnpp Severity: wishlist Owner: Paul Boddie * Package name: shedskin Version : 0.9.7 Upstream Author : Mark Dufour * URL : https://shedskin.github.io/ * License : GPL-3+ Programming Lang: Python Description : Python-to-C++ compiler designed to speed up Python programs Shed Skin converts programs written in a static subset of Python to C++. The C++ code can be compiled to executable code, which can be run either as a standalone program or as a module imported from Python. This package was previously included in Debian but was discarded when Python 2 ceased to be supported for most areas of distribution functionality. This software has since been updated to run using Python 3. Previously, I found a sponsor for the package via the Debian Mentors service. It might make sense to maintain this new package within the Debian Python team, and much of the packaging has been done according to their packaging standards.
Bug#1051352: ITP: shedskin -- Python-to-C++ compiler designed to speed up Python programs
On Thursday, 7 September 2023 06:48:11 CEST Paul Wise wrote: > > Please note the extra steps when reintroducing packages, ie bug triage: > > https://www.debian.org/doc/manuals/developers-reference/ pkgs.en.html#reintroducing-packages Thank you for the reference. I looked in the removal log: https://ftp-master.debian.org/removals-2020.txt Here are the bugs closed when the package was removed: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757125 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=938476 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956489 Only the first one was directly related to the package itself. The others were related to Python 2 removal. As part of repackaging this software, I have set up the packaging repository on Salsa: https://salsa.debian.org/pboddie/shedskin The CI functionality is being used to run the test suite as part of the autopkgtest job in each invoked pipeline: https://salsa.debian.org/pboddie/shedskin/-/pipelines This suite takes over an hour to complete and is therefore not part of the normal package build process. For example: https://salsa.debian.org/pboddie/shedskin/-/jobs/4671845 This should at least mitigate against the inadvertent breakage that occurred with bug #757125. Regards, Paul
Bug#1051352: ITP: shedskin -- Python-to-C++ compiler designed to speed up Python programs
Package: shedskin Version: 0.9.9 X-Debbugs-Cc: debian-pyt...@lists.debian.org After discussion on the Debian Python mailing list, the packaging repository for this software now resides at the following location: https://salsa.debian.org/python-team/packages/shedskin Having updated the packaging resources for the latest upstream release, the CI pipeline has been run successfully: https://salsa.debian.org/python-team/packages/shedskin/-/pipelines/695723 More information on the latest upstream release is available here: http://shed-skin.blogspot.com/2024/06/shed-skin-restricted-python-to-c.html I remain hopeful in getting this useful and impressive software packaged for Debian. Paul
