Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 21:01:47 +0200 Tobias Frost wrote: > On Tue, Sep 08, 2020 at 08:10:48PM +0200, Alec Leamas wrote: >> On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: >> All this said: do you think it's motivated to make such a patch? > > I guess. (Again being Debianite ;-)) OK, will do. Being Debianite is your role here, right?! > Debianites are generally very sensitive about privacy, so any feature that > "calls home"* feature is usually frowned upon; And this is kind of a side > effect of a plugin manager that pulls stuff from the Internet… I see the arguments and concur. >> The plugins uses a CI build chain which supports the core architectures. >> Plugins are built and uploaded automatically. They become available to >> users when url and metadata is included in the catalog -- this is >> semi-automatic process ending up in a PR against the catalog. > > For Debian core architecures means > https://wiki.debian.org/DebianBuster#Architectures Just after pushing the Send button I knew that referring to Debian core architectures was wrong. Our users basically either uses a PC or some raspberry device; we support x86_64 and armhf when it comes to plugins. Now, this should not really change anything. OpenCPN is perfectly usable without any plugins, and builds fine on all Debian core platforms (sic!) Cheers! --alec
Bug#969782: RFS: jag/0.3.8-1 -- arcade and puzzle 2D game
Hi Sudip Mukherjee, > The test added just does 'jag &' which does not provide significant > > test coverage as is evident from the output. > > autopkgtest [21:14:03]: test command1: jag & > > autopkgtest [21:14:03]: test command1: [--- > > qt.qpa.xcb: could not connect to display > > qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though > it was > found. > > This application failed to start because no Qt platform plugin could be > initialized. > Reinstalling the application may fix this problem. > > Even though the test passes, it does not necessarily mean that the package > > under test is actually functional. > > Please add "Restrictions: superficial" to debian/tests/control. > > More details at: > https://sources.debian.org/data/main/a/autopkgtest/5.14/doc/README.package-tests.rst I am very grateful to evaluate my package. Added "Restrictions: superficial". I forgot to mention it in debian/changelog and added the bug FTCBFS has been fixed. (Closes: #958672) Thanks! -- ⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao] ⣾⠁⢠⠒⠀⣿⡁ Debian Wiki: https://wiki.debian.org/coringao ⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780 ⠈⠳⣄⠀⠀⠀ 2157 630B D441 A775 BEFF D35F FA63 ADA6 B638 B780 signature.asc Description: This is a digitally signed message part
Bug#968450: RFS: anacron/2.3-30 [QA] -- cron-like program that doesn't go by time
Dear friends Christian Kastner and Tobias Frost. grateful for your attention. I had some problems in the last few weeks which took me away from working with Debian, but I have already returned to work and I will listen to my friend Christian Kastner's comments about working with the Anacron package thankful. On Tue, Sep 8, 2020 at 12:39 PM Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Jpaulo, > > please follow up on the review by Christian, and when ready remove the > moreinfo > tag! > > Thanks for contributing to Debian! > > -- > tobi >
Bug#969924: RFS: dh-runit/2.10.0 -- 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": This version adds support for invoke-rc.d actions, especially whether or not to restart a service during upgrade. It may also help with #924132 * Package name: dh-runit Version : 2.10.0 Upstream Author : Lorenzo Puliti * URL : https://salsa.debian.org/debian/dh-runit * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-runit Section : admin It builds those binary packages: runit-helper - dh-runit implementation detail dh-runit - debhelper add-on to handle runit runscripts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-runit/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.10.0.dsc Updated git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/dh-runit/-/tree/2.10.0-release Changes since the last upload: dh-runit (2.10.0) experimental; urgency=medium . * Add invoke-rc.d actions support into dh-runit (Closes: #969511) * Deprecate the noreplace option, coupled with onupgrade=nostop * Add onupgrade=reload * Bump our version to 2.10.0 * Don't call sv if is runit is not installed (Closes: #968114) Regards, -- Lorenzo Puliti
Bug#969923: RFS: netkit-ftp-ssl/0.17.34+0.2-5.1 [NMU] -- FTP client with SSL or TLS encryption support
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a NMU sponsor for the package "netkit-ftp-ssl": * Package name: netkit-ftp-ssl Version : 0.17.34+0.2-5.1 Section : net It builds those binary packages: ftp-ssl - FTP client with SSL or TLS encryption support To access further information about this package, please visit the following URL: https://mentors.debian.net/package/netkit-ftp-ssl/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/netkit-ftp-ssl/netkit-ftp-ssl_0.17.34+0.2-5.1.dsc Changes since the last upload: netkit-ftp-ssl (0.17.34+0.2-5.1) unstable; urgency=medium . * Non-maintainer upload. * Build with libedit (Closes: #966383). Regards, Bastian
Bug#969241: RFS: hydrapaper/1.12 [ITP]] -- sets desktop wallpaper on different monitors
Greetings! Thanks for all the comments. That's quite a lot of needed fixes; I guess that's why mentors exists :) On Tue, 2020-09-08 at 22:01 +0200, Tobias Frost wrote: > Control: tags -1 moreinfo > > Hi Francisco, > > On Sat, 29 Aug 2020 17:16:50 -0300 Francisco M Neto wrote: > > Package: hydrapaper > > Version: 1.12-1 > > Upstream has released 2.0 in the meantime. Can you update it please? Will do. > I: hydrapaper source: quilt-patch-missing-description 010_fix-quotation-marks- > in-fstring.patch > - the patch does not have dep3 headers. Have you sent the patch upstream? I did. And I remember creating that header; I probably made some mistake when committing. > d/copyright: > - 1st files section says License: GPL3+, but License text says "Version 2" at > two locations. > - Usually it is best to have the same license for the debian/* part as > upstream. If you make the debian/* GPL3+, d/copyright can become even > shorter. > (Yes, GPL2+ includes GPL3+, but the version 2 is moot in combination) Interesting; I hadn't thought about that! > d/control: > Build Depends on cmake and meson. Does it need both? > The list on Build-Depends on the README.md is shorter than in d/control. > Please re-check your B-Ds if they are really needed. Something in the source tree made me believe I'd need both; I'll recheck that. > d/watch has some extra lines. > d/watch could be more elegant, see https://wiki.debian.org/debian/watch#Gitlab > i.e. > version=4 > https://gitlab.com/gabmus/HydraPaper/tags?sort=updated_desc > archive/@ANY_VERSION@/HydraPaper-\d\S*@ARCHIVE_EXT@ Nothing to say here; this is more elegant, I suppose I got a little paranoid with the regexps. > (Noting here that your orig source tarball is tar.xz, but upstream has no > tar.xz… How did you create the orig.xz tarball? Please stick to the upstream > provided one…) That orig tarball was generated automagically, probably when I imported the upstream source... I'm not sure why it was generated like that. I didn't see a tag when I ran lintian so I didn't notice it. > Nitpicks: > There is no need to override maintainer-manual-page. Overrides should not be > used to silence lintian, but only if lintian is wrong. > However, if you override you should provide more information in the override, > like the MR where the manpage can be found. > But ASFAIS the next release will have the manpage, so no need for action. That tag kept triggering my OCD; but I get your point - overrides should be meaningful. Thank you very much for all the comments! -- []'s, Francisco M Neto www.fmneto.com 3E58 1655 9A3D 5D78 9F90 CFF1 D30B 1694 D692 FBF0 signature.asc Description: This is a digitally signed message part
Re: About sponsorship in real life
Thank you everyone for all the comments; I guess being frustrated is part of the deal, really. That's why I exercise caution when things take longer than I expect. This time I guess I got a little more anxious, though. -- []'s, Francisco M Neto www.fmneto.com 3E58 1655 9A3D 5D78 9F90 CFF1 D30B 1694 D692 FBF0 signature.asc Description: This is a digitally signed message part
Bug#969241: RFS: hydrapaper/1.12 [ITP]] -- sets desktop wallpaper on different monitors
Control: tags -1 moreinfo Hi Francisco, On Sat, 29 Aug 2020 17:16:50 -0300 Francisco M Neto wrote: > Package: hydrapaper > Version: 1.12-1 Upstream has released 2.0 in the meantime. Can you update it please? I: hydrapaper source: quilt-patch-missing-description 010_fix-quotation-marks- in-fstring.patch - the patch does not have dep3 headers. Have you sent the patch upstream? d/copyright: - 1st files section says License: GPL3+, but License text says "Version 2" at two locations. - Usually it is best to have the same license for the debian/* part as upstream. If you make the debian/* GPL3+, d/copyright can become even shorter. (Yes, GPL2+ includes GPL3+, but the version 2 is moot in combination) d/control: Build Depends on cmake and meson. Does it need both? The list on Build-Depends on the README.md is shorter than in d/control. Please re-check your B-Ds if they are really needed. d/watch has some extra lines. d/watch could be more elegant, see https://wiki.debian.org/debian/watch#Gitlab i.e. version=4 https://gitlab.com/gabmus/HydraPaper/tags?sort=updated_desc archive/@ANY_VERSION@/HydraPaper-\d\S*@ARCHIVE_EXT@ (Noting here that your orig source tarball is tar.xz, but upstream has no tar.xz… How did you create the orig.xz tarball? Please stick to the upstream provided one…) Nitpicks: There is no need to override maintainer-manual-page. Overrides should not be used to silence lintian, but only if lintian is wrong. However, if you override you should provide more information in the override, like the MR where the manpage can be found. But ASFAIS the next release will have the manpage, so no need for action. d/control: There is a double-space in the long description before MATE Please fix those issues and then remove the moreinfo tag! -- tobi PS: There are two other packages with your name attached are marked "Need sponsor: No" on mentors.d.n. I could not find a RFS either. Is this intentional? signature.asc Description: This is a digitally signed message part
Bug#969918: RFS: mtd-utils/1:2.1.2-0.1 [NMU] -- Memory Technology Device Utilities
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for an NMU sponsor for the package "mtd-utils". This packages a new upstream version and closes some bugs that the package maintainer did not react to in a while. * Package name: mtd-utils Version : 1:2.1.2-0.1 Upstream Author : David Oberhollenzer * URL : http://www.linux-mtd.infradead.org/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/mtd-utils Section : utils It builds those binary packages: libubi-dev - UBIFS Development Libraries libmtd-dev - Memory Technology Device Development Libraries mtd-utils - Memory Technology Device Utilities To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mtd-utils/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mtd-utils/mtd-utils_2.1.2-0.1.dsc Changes since the last upload: mtd-utils (1:2.1.2-0.1) unstable; urgency=medium . [ Bastian Germann ] * Non-maintainer upload. * Import new upstream version (Closes: #965155, #716414) * Use arch:linux-any (Closes: #745187) * Add d/watch with pubkey * d/copyright: Convert to DEP-5 * d/copyright: Add new copyrights for 2.1.2 * Revert "lib*-dev: Don't include private kernel header" * lib*-dev: Mark Multi-Arch: same (Closes: #965213) . [ Balint Reczey ] * Ignore test results on architectures where tests are not known to pass . [ Debian Janitor ] * Trim trailing whitespace. * Bump debhelper from deprecated 9 to 12. * Set debhelper-compat version in Build-Depends. * Drop unnecessary dependency on dh-autoreconf. * Drop unnecessary dh arguments: --parallel * Update standards version to 4.5.0, no changes needed. Regards, Bastian
Bug#969782: RFS: jag/0.3.8-1 -- arcade and puzzle 2D game
Hi, On Mon, Sep 07, 2020 at 11:31:02PM -0300, Carlos Donizete Froes wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "jag": > >* Added autopkgtest. The test added just does 'jag &' which does not provide significant test coverage as is evident from the output. autopkgtest [21:14:03]: test command1: jag & autopkgtest [21:14:03]: test command1: [--- qt.qpa.xcb: could not connect to display qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found. This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem. Even though the test passes, it does not necessarily mean that the package under test is actually functional. Please add "Restrictions: superficial" to debian/tests/control. More details at: https://sources.debian.org/data/main/a/autopkgtest/5.14/doc/README.package-tests.rst -- Regards Sudip
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, Sep 08, 2020 at 08:10:48PM +0200, Alec Leamas wrote: > On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: > > > > Not really. Do you think a patch is motivated? If so, for each and every > > > plugin, or just for the first one? > > > > I'm not sure how plugins are installed. If there is an UI, the warning > > could be presented in that gui. > > The basic workflow is similar to the browsers: User sees a list of > possible plugins, points to plugin to install, it's downloaded and > installed. > > It is certainly possible to patch this with a dialog showing some info, > for example for the first installed plugin. I know the code good enough > to make such a patch. > > All this said: do you think it's motivated to make such a patch? I guess. (Again being Debianite ;-)) Debianites are generally very sensitive about privacy, so any feature that "calls home"* feature is usually frowned upon; And this is kind of a side effect of a plugin manager that pulls stuff from the Internet… (* is is not uncommon that call home features (sometimes just called "check for updates") are patched away in Debian) > > > > I meant with Man in the Middle: There would be many possiblities for > > attacks… > > If they are not protected by e.g a checksum, Malice one could > > replace them, either in the repo or in transit. There is no gurantee > > that binaries match the sources, as well, if not build in trusted > > enviorments > > or somehow signed. … > > > Checksum/signing is definitely on the agenda, the plugin system is still > not mature. That said, as of today I think an attack needs to hijack > either a github url (for the catalog) or some url on the cloudsmith > deployment server. While certainly possible, it's probably not trivial > To be honest, this is probably not the biggest attack surface on opencpn (It happened before that binaries were replaced by an attacker and served malware to people for quite a time until people noticed. Through being hacked or just through weak credentials.) > > > "tight control upstream" somehow sounds that you control what plugins > > can be installed. Just to make sure that we cover all those freedoms > > we care about: I can have my own plugin installed, right? > > > Yes, using an import function any plugin can be installed from disk. > > > > OK, maybe, I'm not a user, so I can't tell. > > However, you don't likely need _all_ plugins packaged… > > > Focusing on the other aspect: the workflow (think of the browser's > plugin systems) is really hard to implement when installation requires > root privileges. > > Thinking about it, it might be possible to install from a .deb package, > basically "downloading" from /usr/lib instead of an url. Might be worth > an upstream bug. Not sure how much user-value this would add, though. > Will file upstream bug. Hows about having two locations to look at plugins when loading them? (This is how e.g gnome-shell does it) As a side bonus, this would allow people to package plugins indepedently. > > > Packaged plugins have advantages too, because > > the packaging system can be your friend: > > > We have had these discussions in depth. Also, as you might noticed, I'm > not completely new to packaging. Yes, they have advantages. But in the > opencpn context the cons weighs more. It's the combination of user > experience, the need to install as a regular user, multiple linux > distros and administrative work. Yes, I read the bug report. However note that there is not only Debian and Ubuntu, there are very many Debian-derivates that just pull packages from Debian. Do you want to have meta data for each of them? > It's certainly not a binary black and white decision. But, it is a decision. > > > > How are you planning to support all the architecures Debian supports? > > > The plugins uses a CI build chain which supports the core architectures. > Plugins are built and uploaded automatically. They become available to > users when url and metadata is included in the catalog -- this is > semi-automatic process ending up in a PR against the catalog. For Debian core architecures means https://wiki.debian.org/DebianBuster#Architectures > > > Welcome, and sorry for being too Debianite ;-) > > > No need for apologies, discussions are always good. If I required an > apology for these remarks I should probably not be in this business...:) > > As a result I will file two upstream bugs. And perhaps make a patch, if > you deem it motivated. All good things. > > > > Your plugin approach is not how we usually do things here… > > > I know. But still not unheard of, the browsers comes to mind. Browsers are completly different beasts, in terms of complexity, difficult upstream, etc… They have some specialities which are grudgingly accepted, because of no other choice. And yet, there are quite a few browser extensions accepted. > Now, I need to do some work. Will unfortunately not happen today, need > to prepare for work
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, 8 Sep 2020 19:05:21 +0200 Tobias Frost wrote: > > Not really. Do you think a patch is motivated? If so, for each and every > > plugin, or just for the first one? > > I'm not sure how plugins are installed. If there is an UI, the warning > could be presented in that gui. The basic workflow is similar to the browsers: User sees a list of possible plugins, points to plugin to install, it's downloaded and installed. It is certainly possible to patch this with a dialog showing some info, for example for the first installed plugin. I know the code good enough to make such a patch. All this said: do you think it's motivated to make such a patch? > I meant with Man in the Middle: There would be many possiblities for attacks… > If they are not protected by e.g a checksum, Malice one could > replace them, either in the repo or in transit. There is no gurantee > that binaries match the sources, as well, if not build in trusted enviorments > or somehow signed. … Checksum/signing is definitely on the agenda, the plugin system is still not mature. That said, as of today I think an attack needs to hijack either a github url (for the catalog) or some url on the cloudsmith deployment server. While certainly possible, it's probably not trivial To be honest, this is probably not the biggest attack surface on opencpn > "tight control upstream" somehow sounds that you control what plugins > can be installed. Just to make sure that we cover all those freedoms > we care about: I can have my own plugin installed, right? Yes, using an import function any plugin can be installed from disk. > OK, maybe, I'm not a user, so I can't tell. > However, you don't likely need _all_ plugins packaged… Focusing on the other aspect: the workflow (think of the browser's plugin systems) is really hard to implement when installation requires root privileges. Thinking about it, it might be possible to install from a .deb package, basically "downloading" from /usr/lib instead of an url. Might be worth an upstream bug. Not sure how much user-value this would add, though. Will file upstream bug. > Packaged plugins have advantages too, because > the packaging system can be your friend: We have had these discussions in depth. Also, as you might noticed, I'm not completely new to packaging. Yes, they have advantages. But in the opencpn context the cons weighs more. It's the combination of user experience, the need to install as a regular user, multiple linux distros and administrative work. It's certainly not a binary black and white decision. But, it is a decision. > How are you planning to support all the architecures Debian supports? The plugins uses a CI build chain which supports the core architectures. Plugins are built and uploaded automatically. They become available to users when url and metadata is included in the catalog -- this is semi-automatic process ending up in a PR against the catalog. > Welcome, and sorry for being too Debianite ;-) No need for apologies, discussions are always good. If I required an apology for these remarks I should probably not be in this business...:) As a result I will file two upstream bugs. And perhaps make a patch, if you deem it motivated. All good things. > Your plugin approach is not how we usually do things here… I know. But still not unheard of, the browsers comes to mind. Now, I need to do some work. Will unfortunately not happen today, need to prepare for work tomorrow. Cheers! --alec
Re: Bug#969895: RFS: extsmail/2.4-2 -- enables the robust sending of e-mail to external commands
Control: tags -1 -moreinfo Hi, Thanks for spotting this ! Fixed, re-uploaded. Regards, -- Olivier Girondel signature.asc Description: OpenPGP digital signature
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
On Tue, Sep 08, 2020 at 05:54:42PM +0200, Alec Leamas wrote: > Hi Tobias, > > Thanks for taking some time for this! > > On 08/09/2020 16:29, Tobias Frost wrote: > > > a short review: > > > > * New upstream release including plugin downloader. Closes: 948702 > > > > It is a privacy violation to download stuff. Do you inform your user about > > it? > > > Not really. Do you think a patch is motivated? If so, for each and every > plugin, or just for the first one? I'm not sure how plugins are installed. If there is an UI, the warning could be presented in that gui. > > > Are the downloads somehow validated that it won't execute malicious / (MITM) > > modified code? > > > I'm fairly active upstream where these plugins are created. They all > live on github, and the sources are available. > > The actual list of downloadable plugins (the plugin catalog) is kept > under tight control upstream. I meant with Man in the Middle: There would be many possiblities for attacks… If they are not protected by e.g a checksum, Malice one could replace them, either in the repo or in transit. There is no gurantee that binaries match the sources, as well, if not build in trusted enviorments or somehow signed. … "tight control upstream" somehow sounds that you control what plugins can be installed. Just to make sure that we cover all those freedoms we care about: I can have my own plugin installed, right? > > > (It would be better if plugins of relevance would be packaged.) > > > It's just not feasible. There are some 20 plugins, and just the > administrative work is IMHO prohibitive. Also, the user experience is > built around a workflow which does not fly using packaged plugins. OK, maybe, I'm not a user, so I can't tell. However, you don't likely need _all_ plugins packaged… On the other side, it feels like reinventing the wheel… Packaged plugins have advantages too, because the packaging system can be your friend: eg. the dependency handling, security, support when your package is part of a stable release (where you e.g can't update your package at will; so you possibly need to maintain the plugins for several years until the stable release becomes no longer supported… (I think you mentioned that problem in #948702#20 with gtk2/gtk3… how do you plan to solve that when future Debian unstable has a higher gtk stack than a stable one; just an extreme example for the dependency hell that might loom here, even if this'd be worst case…) IOW, I think you will just upstream the required work that the packaging system would take away from you… (Beside that Debian release mechanics are working differnetly here, problably getting in your way sooner or later: testing/ unstable is quite a moving target… Debian users also expect that the software is _stable_ in the sense of _feature stable_, so e.g upgrading plugins in a stable release will cause surprises to the causal Debian user) (Also, likely, the plugins would be similar enough so that the overhead is limited, once one package is nice enough as a master copy for the others ;-)) How are you planning to support all the architecures Debian supports? But as indicated earlier, I'm OK with that (other Debian member might not); Its just you need to be aware of the downsides as well… OpenCPN#2033 has some very valid points. > > > Consistency: in other changelog entries you write a #bugnumber, here only > > bugnumer… > > > > * Add two plugin compatiblity patches (#1997). > > > The lower numbers are upstream bugs. Sort of obvious, but only for me... > Should the notation opencpn#1997 work? Nah, I meant the fist line and second line of the d/changelog. d/changelog is actually only to record changes for the Debian packaging itself, not for upstream changes. (IOW, dont record stuff in d/changelog that have no changes in the debian directory) > > > Spelling error: > > W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility > > > Agreed, will fix > > > - d/copyright has some todos: > > > "blushes" Will fix. > > > - compat-level is still at 12. > > > Actually on purpose to make ubuntu backports somewhat easier. I could > certainly upgrade if you feel that this is the correct decision. OK, valid point for me. > Sending this reply now so I hopefully can get some more input before > doing real work. > > Again: thanks for reviewing! Welcome, and sorry for being too Debianite ;-) You plugin approach is not how we usually do things here… > > Cheers! > --alec signature.asc Description: PGP signature
Bug#968450: RFS: anacron/2.3-30 [QA] -- cron-like program that doesn't go by time
Control: tags -1 moreinfo Hi Jpaulo, please follow up on the review by Christian, and when ready remove the moreinfo tag! Thanks for contributing to Debian! -- tobi
Bug#969910: RFS: grcompiler/5.2-2.1 [NMU] [RC] -- Compiler of smart (graphite) fonts
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a NMU sponsor for the package "grcompiler". It was just autoremoved from testing. This upload has the patches for the bugs that caused the autoremoval: * Package name: grcompiler Version : 5.2-2.1 Upstream Author : silgraphite-de...@lists.sourceforge.net * URL : https://github.com/silnrsi/grcompiler * License : MIT, FSFULLR, LGPL-2.1+ or CPL-0.5+, public-domain, LGPL-2+, GPL-2+ with Autoconf exception, OFL-1.1, X11, BSD-2-clause * Vcs : https://salsa.debian.org/fonts-team/grcompiler Section : devel It builds those binary packages: grcompiler - Compiler of smart (graphite) fonts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/grcompiler/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/g/grcompiler/grcompiler_5.2-2.1.dsc Changes since the last upload: grcompiler (5.2-2.1) unstable; urgency=medium . * Non-maintainer upload. * Add upstream patches for big endian (Closes: #961445) * Add upstream patch for font names (Closes: #961438) * d/copyright: Add missing Upstream-Contact Regards, Bastian
Bug#960742: RFS: lazpaint/7.1.3 ITP -- add LazPaint to Debian
On Sat, May 16, 2020 at 11:28:34AM +0200, Johann ELSASS wrote: > Hello Tobias, > > Thanks for your reply. I came up with the following. > > First install "lazarus-package" as it is required to compile. > > Then the source package would consist of the following: > - in bgrabitmap subdir extract > https://github.com/bgrabitmap/bgrabitmap/archive/master.zip > - in bgracontrols subdir extract > https://github.com/bgrabitmap/bgracontrols/archive/master.zip > - in lazpaint subdir extract > https://github.com/bgrabitmap/lazpaint/archive/master.zip > - in the base dir add make.sh (provided as attachment of this mail) > > Running it compiles and creates the Deb package in > lazpaint/lazpaint/release/debian/ > > Am I getting closer? I fear there you need to check the packaging mechanics in Debian … E.g you can't have manual steps. Your (Debian) source package needs to have all the instructions to make a Debian package. The instructions are in the debian/ directory of a source package… Maybe those resource will be of help for an introdcution to Debian packageing: - https://mentors.debian.net/intro-maintainers/ (esp. the linked resources) - https://wiki.debian.org/Packaging/Intro - https://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf In shorter words, you need to produce a source package where you can simply say "dpkg-buildpackage" and this command generates a *.deb. The second problem: You cannot download external resources while building a package. So you need to have (IIUC) bgrabitmap, bgracontrols already as Debian package and "Build-Depend" (an entry in debian/control) to retrieve them. There should be lazarus based packages already in Debian. Maybe look at those packages ddrescueview, doublecmd, dozzaqueux, mricron, optgeo, transgui, vmg, winff* For that, do a apt-source $package to get the source and take a look at it. Maybe it helps to get started… (As said, it is the debian directory that is most important.) -- tobi (* disclaimer: only a quick grep over sources, I did not check details / suitability) > > -- > Johann ELSASS > circu...@operamail.com > > On Sat, May 16, 2020, at 8:29 AM, Tobias Frost wrote: > > Control: tags -1 wontfix > > > > Hi Johann, > > > > thanks for your interest to contribute to Debian! > > However, it's unfortunatly not that straight forward… See below for > > info and resources! > > > > On Sat, May 16, 2020 at 08:04:00AM +0200, Johann ELSASS wrote: > > > Package: sponsorship-requests > > > Severity: wishlist > > > > > > Dear mentors, > > > > > > I am looking for a sponsor for my package "lazpaint": > > > > > > * Package name: lazpaint > > >Version : 7.1.3 > > >Upstream Author : Johann ELSASS > > > * URL : https://github.com/bgrabitmap/lazpaint/releases > > > * License : GPL3 > > > * Vcs : > > > https://github.com/bgrabitmap/lazpaint/tree/master/lazpaint/release/debian > > >Section : Graphics App > > > > > > I don't understand very well what I am supposed to write in here. > > > > > > What I can say is that I build the debian package for 32-bit and 64-bit > > > using the binary produced by the dev environment Lazarus and that I put > > > it into the package using the bash script in lazpaint/release/debian > > > folder. > > > > You need to compile lazpaint _while_ creating the debian package, it is > > not acceptable to pre-compile it and then > > "just" copy the resulting binary into it. > > > > I'm not a Pascal guy, there should be a few examples in the Debian > > archives which might gives you hints how to do it: > > codesearch.debian.net on lazarus in debian/control might give you hints > > where to look for examples: > > https://codesearch.debian.net/search?q=lazarus+path%3Adebian%2Fcontrol=1=1 > > > > Beside that, please read this resource as starting point: > > https://mentors.debian.net/intro-maintainers > > As you are also upstream, you might also want to read: > > https://wiki.debian.org/UpstreamGuide > > > > Cheers, > > tobi > > > > (marking as wont fix for now -- that means that it cannot be sponsored > > that way and avoids > > that other people spend uncessary time on this bug report. Remove the > > tag when you are ready with > > a package that compiles from source.) > > > > > To access further information about this package, please visit the > > > following URL: > > > > > > https://github.com/bgrabitmap/lazpaint > > > > > > Regards, > > > > > > -- > > > Johann > > > > >
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Hi Tobias, Thanks for taking some time for this! On 08/09/2020 16:29, Tobias Frost wrote: > a short review: > > * New upstream release including plugin downloader. Closes: 948702 > > It is a privacy violation to download stuff. Do you inform your user about it? Not really. Do you think a patch is motivated? If so, for each and every plugin, or just for the first one? > Are the downloads somehow validated that it won't execute malicious / (MITM) > modified code? I'm fairly active upstream where these plugins are created. They all live on github, and the sources are available. The actual list of downloadable plugins (the plugin catalog) is kept under tight control upstream. > (It would be better if plugins of relevance would be packaged.) It's just not feasible. There are some 20 plugins, and just the administrative work is IMHO prohibitive. Also, the user experience is built around a workflow which does not fly using packaged plugins. > Consistency: in other changelog entries you write a #bugnumber, here only > bugnumer… > > * Add two plugin compatiblity patches (#1997). The lower numbers are upstream bugs. Sort of obvious, but only for me... Should the notation opencpn#1997 work? > Spelling error: > W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility Agreed, will fix > - d/copyright has some todos: "blushes" Will fix. > - compat-level is still at 12. Actually on purpose to make ubuntu backports somewhat easier. I could certainly upgrade if you feel that this is the correct decision. Sending this reply now so I hopefully can get some more input before doing real work. Again: thanks for reviewing! Cheers! --alec
Bug#969895: RFS: extsmail/2.4-2 -- enables the robust sending of e-mail to external commands
Control: tags -1 moreinfo Hello, it seems you have missed the change of #969825; diffing the source on mentors against the archive only gives a change in d/changelog. Additionally, lintian compplains on https://mentors.debian.net/package/extsmail Package has lintian errors E latest-changelog-entry-without-new-date I typo-in-manual-page usr/share/man/man5/extsmail.conf.5.gz unsucessful unsuccessful $diff -Naur archive/*/ new/*/ diff -Naur archive/extsmail-2.4/debian/changelog new/extsmail- 2.4/debian/changelog --- archive/extsmail-2.4/debian/changelog 2020-01-31 16:37:26.0 +0100 +++ new/extsmail-2.4/debian/changelog 2020-01-31 16:37:26.0 +0100 @@ -1,3 +1,9 @@ +extsmail (2.4-2) unstable; urgency=low + + * debian/tests/control: Add Restrictions: superficial (Closes: #969825). + + -- Olivier Girondel Fri, 31 Jan 2020 16:37:26 +0100 + Please fix and then remove the moreinfo tag! Thanks for contributing to Debian! -- tobi signature.asc Description: This is a digitally signed message part
Bug#969902: marked as done (RFS: etktab/3.2-12 [RC] -- ASCII guitar tab editor)
Your message dated Tue, 08 Sep 2020 16:45:01 +0200 with message-id <88bace1db808cc4e5e977f15fa4aaab7a6fab2a7.ca...@debian.org> and subject line Re: RFS: etktab/3.2-12 [RC] -- ASCII guitar tab editor has caused the Debian Bug report #969902, regarding RFS: etktab/3.2-12 [RC] -- ASCII guitar tab editor to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 969902: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=969902 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "etktab": * Package name: etktab Version : 3.2-12 Upstream Author : Jason Sonnenschein * URL : https://sourceforge.net/projects/etktab/ * License : Artistic-1.0 * Vcs : https://salsa.debian.org/debian/etktab Section : sound It builds those binary packages: etktab - ASCII guitar tab editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/etktab/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/etktab/etktab_3.2-12.dsc Also the Vcs repository, on salsa, is up do date: https://salsa.debian.org/debian/etktab Changes since the last upload: etktab (3.2-12) unstable; urgency=medium . * debian/copyright: added Upstream-Contact field. * debian/patches/: - 005_convert-files-to-utf8.patch: added to convert some files to UTF-8, rather than use national encoding. - Refreshed all patches. - Removed some trailing whitespace from patches 001 to 003. - Updated all patches headers to include Forwarded field. * debian/tests/control: - Added '-a' option to xvfb-run to get a free server number. - Test marked as superficial since does not provide significant test coverage. Thanks to Sudip Mukherjee. (Closes: #969823) Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683 ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ GPG:rsa4096/7EF63B2E --- End Message --- --- Begin Message --- Uploaded as is, thanks for your contribution to Debian! -- tobi--- End Message ---
Bug#965363: RFS: opencpn/5.2.0+dfsg-1 [RC] -- Open Source Chartplotter and Marine GPS Navigation Software
Control: tags -1 moreinfo Hi Alec, a short review: * New upstream release including plugin downloader. Closes: 948702 It is a privacy violation to download stuff. Do you inform your user about it? Are the downloads somehow validated that it won't execute malicious / (MITM) modified code? (It would be better if plugins of relevance would be packaged.) (I'll gonna ignore that, but other people might file an RC bug because of that) Consistency: in other changelog entries you write a #bugnumber, here only bugnumer… * Add two plugin compatiblity patches (#1997). Spelling error: W: opencpn-plugins: spelling-error-in-changelog compatiblity compatibility - d/copyright has some todos: "Files: plugins/wmm_pi/src/GeomagnetismLibrary.c Copyright: protection. / ed works consisting predominantly of the material produced by" seems to be wrong… "License: Khronos Please fill license Khronos from header of include/GL/glext.h " please do so - compat-level is still at 12. Please comment / explain / fix / … those and we can proceed :)
Bug#969902: RFS: etktab/3.2-12 [RC] -- ASCII guitar tab editor
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "etktab": * Package name: etktab Version : 3.2-12 Upstream Author : Jason Sonnenschein * URL : https://sourceforge.net/projects/etktab/ * License : Artistic-1.0 * Vcs : https://salsa.debian.org/debian/etktab Section : sound It builds those binary packages: etktab - ASCII guitar tab editor To access further information about this package, please visit the following URL: https://mentors.debian.net/package/etktab/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/etktab/etktab_3.2-12.dsc Also the Vcs repository, on salsa, is up do date: https://salsa.debian.org/debian/etktab Changes since the last upload: etktab (3.2-12) unstable; urgency=medium . * debian/copyright: added Upstream-Contact field. * debian/patches/: - 005_convert-files-to-utf8.patch: added to convert some files to UTF-8, rather than use national encoding. - Refreshed all patches. - Removed some trailing whitespace from patches 001 to 003. - Updated all patches headers to include Forwarded field. * debian/tests/control: - Added '-a' option to xvfb-run to get a free server number. - Test marked as superficial since does not provide significant test coverage. Thanks to Sudip Mukherjee. (Closes: #969823) Regards, -- ⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich ⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683 ⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E ⠈⠳⣄ GPG:rsa4096/7EF63B2E
Re: About sponsorship in real life
On 08/09/2020 13:10, Geert Stappers wrote:
> On Tue, Sep 08, 2020 at 07:39:14AM +0200, Thomas Dettbarn wrote:
>>> Francisco M Neto hat am 08.09.2020 03:31 geschrieben:
>>>
>>>
>>> Greetings,
>>>
>>> I see a lot of RFS email that just sits there in the mailing list,
>>> without ever getting a response... is that normal? Do responses about
>>> requests
>>> for sponsorship usually not get sent to debian-mentors?
>>>
>>> Is there something I should be doing to get someone to sponsor my
>>> package?
>>>
>>
>> Yes, the process is highly frustrating.
>> Hang in there, buddy!
>>
> Yes, the same webpage has a list of RFS that need follow-up.
Indeed. I have actually one of two RC bugs ("Important bugs") sitting
here since end of July. Even so, not much happens.
> Just "Hang in" will not help.
Hm... yes. I will have to do something, I guess. Not entirely clear to
me what that would be, though. But thanks for suggestions.
--alec
Bug#969895: RFS: extsmail/2.4-2 -- enables the robust sending of e-mail to external commands
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "extsmail" * Package name: extsmail Version : 2.4-2 Upstream Author : Laurence Tratt * URL : https://tratt.net/laurie/src/extsmail/ * License : BSD/MIT Section : mail It builds this binary package: extsmail - enables the robust sending of e-mail to external commands The package appears to be lintian-clean To access further information about this package, please visit the following URL: https://mentors.debian.net/package/extsmail Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/extsmail/extsmail_2.4-2.dsc Changes since the last upload: * debian/tests/control: Add Restrictions: superficial (Closes: #969825). Regards, -- Olivier signature.asc Description: OpenPGP digital signature
Bug#963733: marked as done (RFS: ete/3.1.1-8 [ITP] -- A Python framework for the analysis and visualization of trees (Python 3))
Your message dated Tue, 8 Sep 2020 14:19:31 +0300 with message-id <04a689c2-364e-6ad2-6ef4-b84ac44c1...@debian.org> and subject line 963733: uploaded as source:python-ete3 has caused the Debian Bug report #963733, regarding RFS: ete/3.1.1-8 [ITP] -- A Python framework for the analysis and visualization of trees (Python 3) to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 963733: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963733 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "ete" * Package name: ete Version : 3.1.1-1 Upstream Author : Jaime Huerta Cepas * URL : https://etetoolkit.org/ * License : GPL * Vcs : https://github.com/etetoolkit/ete Section : python It builds those binary packages: python3-ete - A Python framework for the analysis and visualization of trees (Python 3) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ete and https://salsa.debian.org/zhaofeng-shu33-guest/ete Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/ete/ete_3.1.1-1.dsc Changes since the last upload: * Initial release Regards, -- Feng Zhao --- End Message --- --- Begin Message --- Hello, Source package 'ete' seems to be uploaded as 'python-ete3', thus I am closing this bug. Andrius--- End Message ---
Re: About sponsorship in real life
On Tue, Sep 08, 2020 at 07:39:14AM +0200, Thomas Dettbarn wrote: > > Francisco M Neto hat am 08.09.2020 03:31 geschrieben: > > > > > > Greetings, > > > > I see a lot of RFS email that just sits there in the mailing list, > > without ever getting a response... is that normal? Do responses about > > requests > > for sponsorship usually not get sent to debian-mentors? > > > > Is there something I should be doing to get someone to sponsor my > > package? > > > > Yes, the process is highly frustrating. > Hang in there, buddy! > Yeah as in real life. You are completely free to feel frustrated. You are also free to enjoy other sides of life. Visit https://bugs.debian.org/sponsorship-requests for list of resolved sponsorship request. Yes, the same webpage has a list of RFS that need follow-up. Just "Hang in" will not help. Groeten Geert Stappers -- Silence is hard to parse
Bug#969404: RFS: enki/20.03.1-1 [ITP] -- text editor for programmers
On Wed, Sep 02, 2020 at 02:16:41PM +0800, Peter Ji wrote: > * Package name: enki >Version : 20.03.1-1 > It builds those binary packages: > > enki - text editor for programmers Hi! The build fails with: ModuleNotFoundError: No module named 'PyQt5' Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Bug#969291: RFS: sane-backends/1.0.31-1~experimental1 [RC] -- API library for scanners [transitional package]
Hello, > > The change from libsane to libsane1 requires IMHO a transition. Therefore only > in experimental. > > > I saw you switched from "libsane" to "libsane1". This was not really > > warranted, the lintian warning that you fixed with this rename > > was harmless and you should consider the cost to update all the > > reverse build dependencies (and there are quite a few). However > > now that you have added the transitional package and that you are > > already gone through NEW, I guess it's ok to push this to completion. > > Thanks. > We will have for some while, both libsane1 and libsane transitional package. Rebuilding the reverse-dependencies will make libsane go away faster, but there is no real need to rebuild anything right now, because both dependencies will be satisfied. So, since the ABI seems to have not changed, this is not a "transition" but more a "lets rebuild reverse dependencies so the transitional package can go away faster" But in any case, reverse-dependencies are likely to have some unrelated upload in the next months, so rebuilding them now might be unnecessary (for sure it isn't necessary for testing migration). FWIW in Ubuntu I did the rebuilds :) Gianfranco
Bug#969789: RFS: elfio/3.7-1 [ITP] -- C++ header-only library for reading and generating ELF files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "elfio": * Package name: elfio Version : 3.7-1 Upstream Author : Serge Lamikhov-Center * URL : http://serge1.github.io/ELFIO * License : MIT * Vcs : https://github.com/serge1/ELFIO Section : devel It builds those binary packages: elfio - C++ library for reading and generating ELF files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elfio/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elfio/elfio_3.7-1.dsc Changes for the initial release: elfio (3.7-1) unstable; urgency=medium . * Initial release (Closes: #839382) Initially, the package was requested as a dependency for Apache Mesos (#839382). The library is used by many processor design companies and academic institutions. Regards, -- Serge Lamikhov-Center
Re: About sponsorship
On Mon, Sep 07, 2020 at 10:57:04PM -0300, Francisco M Neto wrote: > On Tue, 2020-09-08 at 01:41 +, Paul Wise wrote: > > On Tue, Sep 8, 2020 at 1:32 AM Francisco M Neto wrote: > > > > > Is there something I should be doing to get someone to sponsor my package? > > > > Keep maintaining your packages and keep your RFSen up to date. > > > > There are some other tips for this in the FAQ: > > > > https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages > > Thank you so much for all the info. I'll keep working on them, and keep > them updated on salsa and mentors.d.o. Quoting https://wiki.debian.org/DebianMentorsFaq#How_do_I_get_a_sponsor_for_my_package.3F Your RFS message is like an ad for your package. It's likely to be the only thing that prospective sponsors will judge your package on. You can have all the extra URLs you like in there where sponsors can get more information, but unless your initial message piques their interest, they'll never look at them. And do know that a uploading sponsor doesn't have be at this mailinglist. So promote the done packaging also elsewhere. Groeten Geert Stappers -- Silence is hard to parse
Bug#969446: RFS: vguitar-2.6 [ITP] -- Play Guitar in any term window. Use with a MIDI synthesizer (qsynth).
Hi Boyuan Yang, > Please review each of those files and make sure that unnecessary > template placeholders are not included in your packaging debian/ dir. > Please pay special attention to the debian/copyright file since it was I have manually reviewed & edited all these files with special attention to debian/copyright. These changes have been updated to my repository as 2.6. apt-get source vguitar ---vguitar_2.6.orig.tar.gz ---vguitar_2.6-1.dsc ---vguitar_2.6-1.debian.tar.xz I am unfamiliar with much of Debian packaging. Thank you for mentoring. Nick Strauss
Re: About sponsorship
Hello, maybe a hint for help Is it a package to be team-amintained? Then ask at the team too Regards Am 08.09.20 um 07:39 schrieb Thomas Dettbarn: > Yes, the process is highly frustrating. > Hang in there, buddy! > > Thomas > >> Francisco M Neto hat am 08.09.2020 03:31 geschrieben: >> >> >> Greetings, >> >> I see a lot of RFS email that just sits there in the mailing list, >> without ever getting a response... is that normal? Do responses about >> requests >> for sponsorship usually not get sent to debian-mentors? >> >> Is there something I should be doing to get someone to sponsor my >> package? >> >> >> -- >> []'s, >> >> Francisco M Neto >> www.fmneto.com >> >> 3E58 1655 9A3D 5D78 9F90 >> CFF1 D30B 1694 D692 FBF0 > -- Mechtilde Stehmann ## Debian Developer ## PGP encryption welcome ## F0E3 7F3D C87A 4998 2899 39E7 F287 7BBA 141A AD7F signature.asc Description: OpenPGP digital signature
