Bug#945337: why is the version from elpa needed
All I know is many bugs are fixed in the newer versions. Fine.
Bug#945337: why is the version from elpa needed
OK, working with $ apt-cache policy emacs emacs: Installed: 1:27.1+1-3 Candidate: 1:27.1+1-3 Version table: *** 1:27.1+1-3 990 990 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages tramp-version is a variable defined in ‘tramp-cmds.el’. Its value is "2.4.3.27.1" I.e., already about 11 versions deep on https://elpa.gnu.org/packages/tramp.html What's worse is: A debian users visits https://elpa.gnu.org/packages/tramp.html and sees To install this package, run in Emacs: M-x package-install RET tramp RET but as debian already has an old tramp, so underneath his fingertips this expands to tramp-theme and unless he notices what happened, he still can't advance beyond the old tramp version! All he has done is install tramp-theme, not tramp. Also $ aptitude search elpa-|wc -l 343 $ w3m -dump -cols 999 https://elpa.gnu.org/packages/index.html|perl -nwle 'print if /^a/../^$/'|wc -l 276 So there are more elpa- packages in Debian than even on the official elpa website! Therefore I propose that all packages on the elpa website be automatically included in Debian.
Bug#982402: Firmware needs prober
Package: wnpp Severity: wishlist Sure, one can install all the firmware-* packages in Debian, and thus be sure one has all the firmware one needs. However that is a big waste. Many megabytes of wasted updates for who knows what, some IBM printer from 1967, who knows? Therefore there should be a package, that probes the system, to see exactly what firmware packages one really needs. Yes, it needs to be a highly specialized script that knows what kinds of places to probe for what. (like lshw.) And in its man page it needs to say "turn on / plug in all your devices for best results." Sure, a lot of firmware needs just cannot be probed, and one must wait for problems to occur before one starts searching Google with the symptoms, finally finding the answer, hopefully. Yes, it would be nice if each hardware that needed firmware could be probed in a standard way so that it would respond saying what firmware it needed. Etc.
Bug#968194: Prerelease getmail6 .deb
I can test a Prerelease getmail6 .deb for you when you make one.
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
> "OA" == Osamu Aoki writes: OA> Hi, OA> I am about to request for package removal of current getmail package. OA> So whoever decide to package this new python3 getmail, please go ahead OA> without worrying file conflict. Maybe don't remove it, but just hand it over to Sudip for upgrade.
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
Actually I am guessing the current maintainer isn't reading these emails, and you Sudip, should consider non-maintainer uploads or steps on how to take over the project altogether from non-active maintainers.
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
Indeed in https://github.com/getmail6/getmail6/issues/33#issuecomment-681888347 we see the trend across distributions is for a single getmail package upgraded to 6 and not two packages.
Bug#969021: RFP: getmail6 -- Mail retriever with support for POP3, IMAP4 and SDPS
> "SM" == Sudip Mukherjee writes: SM> X-Debbugs-Cc: Osamu Aoki I'm not sure that line will work there. I'll CC him anyway. SM> This getmail6 will install files like: SM> /usr/bin/getmail SM> /usr/bin/getmail_fetch SM> /usr/bin/getmail_mbox SM> /usr/bin/getmail_maildir SM> /usr/bin/getmail-gmail-xoauth-tokens SM> /usr/lib/python3/dist-packages/getmailcore SM> which are also installed by getmail. SM> So, I guess the best possible way might be if getmail maintainer updates SM> to this source, else I can package getmail6 with a "Breaks: getmail". Ah, good catch! I'm estimating that the current Debian getmail maintainer would actually be very happy if you Sudip, could take over the entire Debian getmail project. Then there indeed would be no need for two independent packages!
Bug#969021: getmail6 as parallel package
After reviewing https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968194 one feels yes, an independent getmail6 package would be the best solution for now rather than upgrading a single getmail package.
Bug#951444: List packages where maintainer might be unfit
Package: wnpp https://www.debian.org/devel/wnpp/ apparently only shows package where a maintainer has cried for help, or packages that don't exist yet, and people wish existed. It should also list and mention how to file reports about * Packages that reporters worry that the maintainer might be ill or have died. * Packages that reporters worry that the maintainer is otherwise not worthy of being the maintainer, and should have a new maintainer. Indeed these would be new categories of the current "Packages in need of a new maintainer" section.
Bug#951439: Table of contents for wnpp/work_needing webpage
Package: wnpp
These sections need to show up in some table of contents,
$ w3m -dump https://www.debian.org/devel/wnpp/work_needing | grep -P ^\\w ...
Packages up for adoption, by maintainer
Orphaned packages
Else they are buried deep within the document.
("Packages up for adoption" is at top, so that's all the user finds easily.)
Feel free to move this bug to Package: www.debian.org if more
appropriate.
Bug#832161: can't run
To run the program, after downloading, do $ java -jar GpsMaster_*.jar (But this did not seem to work. So maybe do something else) Exception in thread "main" java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException
