Bug#954760: marked as done (RFS: lighttpd/1.4.53-5 [SPU, RC] -- backport security, bug fixes from upstream)
Your message dated Sat, 30 May 2020 01:49:49 -0400 with message-id <20200530054949.GB184057@xps13> and subject line 954760-done has caused the Debian Bug report #954760, regarding RFS: lighttpd/1.4.53-5 [SPU, RC] -- backport security, bug fixes from upstream 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.) -- 954760: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954760 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important Dear mentors, Please release lighttpd 1.4.53-5 as a stable-update to Buster. I am a lighttpd developer (upstream) and have prepared lighttpd 1.4.53-5 on the 'buster' branch at https://salsa.debian.org/debian/lighttpd/-/tree/buster The debian/changelog entry for 1.4.53-5 is currently marked UNRELEASED. The patches added to debian/patches do the following: * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55 Numerous important fixes have been backported to Debian Buster package for lighttpd 1.4.53, including: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954759 This is my first submission to sponsorship-requests, so your guidance is appreciated. Cheers, Glenn -- System Information: Debian Release: 10.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Thank you, Boyuan, for your guidance and for your offer to assist. I am going to close this ticket out and will follow up with the Debian lighttpd team (team+lighttpd@tracker.d.o) to handle this backport Cheers, Glenn--- End Message ---
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/29/20 10:07 PM, Tobias Frost wrote: > On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: > >> I'm a bit cautious to allow installing games into the user home >> directory. Game files can quickly grow large (up to GB of data). One >> reason why I opted for /opt in the first place. > Speaking of games, are there free (FOSS) games available? A quick Internet > research yielded no results, so I'd appreciate if you could provide pointers. > > Thanks! > Not yet. The engine has been released public for the first time recently. Available right now are example projects including ready-to-run delgas: https://github.com/LordOfDragons/deexamples . The engine can be used for both FOSS and commercial alike without troubles. To makes games though you need the engine in the first place. It's sort of chicken/egg problem here. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On 5/29/20 4:21 PM, Tobias Frost wrote: > Control: tag -1 moreinfo > > Hi Roland, > > On Fri, May 29, 2020 at 03:13:34PM +0200, Roland Plüss wrote: >> On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: >>> On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: >>> >>> (..) >>> There are other issues but I'd rather stop here. Since you yourself is also the upstream, it could be possible for you to actually review the software buildsystem (scons scripts) since it seems to have diverted from traditional software installation procedures on UNIX-like platforms. In any case, the source repository and packaging scripts your provided need >> improvement. >>> It is discouraged to use scons as build system [1]. If you see the >> possiblity >>> please change it to something else, (e.g. cmake) >>> >>> [1] https://wiki.debian.org/UpstreamGuide#SCons >>> >>> >>> >> Switching away from SCons is not an option. As I mentioned on IRC the >> cons against SCons in that article are no cons but incorrectly using >> SCons or not understanding SCons at all. > I'm not aware of this discussion. > >> Like many things in live SCons >> is like a bazooka: if you handle it correctly it gives you a punch like >> nothing else but it doesn't prevent you from pointing it at your own feet. > It is incredible difficult to use scons correctly, as it sometimes lacks > proper > default behaviour. Especially in multiarch and crosscompilations scenarios > (which is relevant for Debian). But if you say you can handle it, go ahead. > >> If for the debian package improvements are required please tell me > I do not sponsor scons based packages. > > However here's something: > - take a look at the mentors page for your package: there are many lintian > reportings to fix. Some of them also indicates that your buildsystem is not > properly building or configured. > - libraries are not built for Multiarch > - dev-pkg-without-shlib-symlink > - hardening. > - debug-file-with-no-debug-symbols > - dont hardcoding the number of CPUS d/rules, scons _-j8_ ) > (- there mihgt be more lintian stuff) > > More hints: > - Section X11 is likely wrong. You maybe want games? > - Spelling errors in binary. > - new-package-should-close-itp-bug > - no watch file. > - A game (engine) should not need a postinst. As said, /opt is off limit for > packages. Don't addgroup games. > - What is about those extern/ directory? There are tarballs… e.g fox*.tar.bz. > You can't have embedded code copies, if they are not in Debian they need to > be packaged. You should remove the complete extern folder using > Files-Exclude, if > possible. (The source package is 46MiB…) > - Where are the fonts in e.g deige/shared/data/data/fonts from? What is the > copyright? > Same for the icons? > - You package does not build in a pbuilder enviornment. Missing > Build-Dependencies (B-D) e.g on scons. > - A ton of other B-Ds are also missing (assuming extern lists the libraries > you > need) > > Looking at your repo: > https://github.com/LordOfDragons/dragengine/blob/debian/debian/rules lines > 34-41 > (you maybe want a install target? It should honour $DESTDIR, though) > looks quite weird. Also lines 27-29 are weird (clean target not working?) > Line 53-58 looks fishy to me. > >> and I'll apply the required changes but I will not go back to makefiles. > For sure you know that cmake is a buildsystem generator. It can > to create Makefiles, but it does not need to. > > Ok, I found many issues by only barley looking, so I marked the RFS as > "moreinfo". > Please fix the issues and then remove the "moreinfo" tag to have the > indication for > sponsors to take a look again. Please read also the "upstream guide" I posted > earlier, > it contains important information who to package software distribution > friendly. You are looking there at an older package version. I fixed some of these points already. For the other points I need to check them out in more detail since some I have no idea what lintian is actually complaining about. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, May 29, 2020 at 12:32:42PM +0200, Roland Plüss wrote: > I'm a bit cautious to allow installing games into the user home > directory. Game files can quickly grow large (up to GB of data). One > reason why I opted for /opt in the first place. Speaking of games, are there free (FOSS) games available? A quick Internet research yielded no results, so I'd appreciate if you could provide pointers. Thanks! -- tobi
Bug#961818: RFS: sleepd/2.11 -- puts an inactive or low battery laptop to sleep
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "sleepd" * Package name: sleepd Version : 2.11 Upstream Author : Joey Hess * URL : https://kitenet.net/~joey/code/sleepd/ * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/sleepd Section : admin It builds those binary packages: sleepd - puts an inactive or low battery laptop to sleep To access further information about this package, please visit the following URL: https://mentors.debian.net/package/sleepd Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/sleepd/sleepd_2.11.dsc Changes since the last upload: * QA upload. . [ Jelmer Vernooij ] * Trim trailing whitespace. * Use secure copyright file specification URI. . [ Ondřej Nový ] * d/control: Add Vcs-* field . [ Debian Janitor ] * Use secure URI in Homepage field. * Explicitly specify source format. * Bump debhelper from old 9 to 12. . [ Sudip Mukherjee ] * Update Standards-Version to 4.5.0 * Add Pre-Depends. * Update compat level to 13. * Use canonical URI with Vcs-Git. * Fix FTBFS with gcc-10. (Closes: #957810) -- Regards Sudip
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: > On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: > > (..) > > > There are other issues but I'd rather stop here. Since you yourself is > > also the upstream, > > it could be possible for you to actually review the software > > buildsystem (scons scripts) since it seems > > to have diverted from traditional software installation procedures on > > UNIX-like platforms. In any case, > > the source repository and packaging scripts your provided need improvement. > > It is discouraged to use scons as build system [1]. If you see the possiblity > please change it to something else, (e.g. cmake) > > [1] https://wiki.debian.org/UpstreamGuide#SCons > > > Switching away from SCons is not an option. As I mentioned on IRC the cons against SCons in that article are no cons but incorrectly using SCons or not understanding SCons at all. Like many things in live SCons is like a bazooka: if you handle it correctly it gives you a punch like nothing else but it doesn't prevent you from pointing it at your own feet. If for the debian package improvements are required please tell me and I'll apply the required changes but I will not go back to makefiles. -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Fri, 29 May 2020 05:33:43 + Paul Wise wrote: > On Thu, May 28, 2020 at 6:33 PM Roland Plüss wrote: > > > What path do you think should I choose to be best conform with Debian? > > I would package the games into Debian packages so that the source > data/code is available and built by the Debian packaging, using paths > something like /usr/share/dlauncher/games/. For games that don't have > Debian packages (I guess you plan to have a central store or > something), install the games to the ~/.local/share/dlauncher/games/ > dir since different users will want different sets of games installed. > You could also add a directory in /usr/local that the sysadmin could > install games to for all users if they want. > > -- > bye, > pabs > > https://wiki.debian.org/PaulWise > > I should have mentioned a point or two. The launchers operate on a single central installation directory only but this does not mean games are necessarily installed there. Delga files do not need to be physically there. They can be also just sym-links. The launchers use the content of this directory to populate the list of installed games. That said launchers can run delgas without being installed at all. You can download a delga and just open it and it launches without the need to be installed at all. Installing though is more convenient but not required. This requires only the "mime-types" included in the package to be properly registered. I'm a bit cautious to allow installing games into the user home directory. Game files can quickly grow large (up to GB of data). One reason why I opted for /opt in the first place. That said the directory used by the launchers can be altered by env-param DELAUNCHER_GAMES . So for multi-user this can be shifted to the home-directory with all the potentially size caveats if required. I think for this package I would prefer /usr/share/delauncher/games with the option of using env-param or maybe global/local directories in the future (needs further discussion because this has its own set of problems). -- Mit freundlichen Grüssen Plüss Roland Game Development and Game Engine Technologies https://dragondreams.ch signature.asc Description: OpenPGP digital signature
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
Control: tag -1 moreinfo Hi Roland, On Fri, May 29, 2020 at 03:13:34PM +0200, Roland Plüss wrote: > On Fri, 29 May 2020 14:21:03 +0200 Tobias Frost wrote: > > On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: > > > > (..) > > > > > There are other issues but I'd rather stop here. Since you yourself is > > > also the upstream, > > > it could be possible for you to actually review the software > > > buildsystem (scons scripts) since it seems > > > to have diverted from traditional software installation procedures on > > > UNIX-like platforms. In any case, > > > the source repository and packaging scripts your provided need > improvement. > > > > It is discouraged to use scons as build system [1]. If you see the > possiblity > > please change it to something else, (e.g. cmake) > > > > [1] https://wiki.debian.org/UpstreamGuide#SCons > > > > > > > > Switching away from SCons is not an option. As I mentioned on IRC the > cons against SCons in that article are no cons but incorrectly using > SCons or not understanding SCons at all. I'm not aware of this discussion. > Like many things in live SCons > is like a bazooka: if you handle it correctly it gives you a punch like > nothing else but it doesn't prevent you from pointing it at your own feet. It is incredible difficult to use scons correctly, as it sometimes lacks proper default behaviour. Especially in multiarch and crosscompilations scenarios (which is relevant for Debian). But if you say you can handle it, go ahead. > If for the debian package improvements are required please tell me I do not sponsor scons based packages. However here's something: - take a look at the mentors page for your package: there are many lintian reportings to fix. Some of them also indicates that your buildsystem is not properly building or configured. - libraries are not built for Multiarch - dev-pkg-without-shlib-symlink - hardening. - debug-file-with-no-debug-symbols - dont hardcoding the number of CPUS d/rules, scons _-j8_ ) (- there mihgt be more lintian stuff) More hints: - Section X11 is likely wrong. You maybe want games? - Spelling errors in binary. - new-package-should-close-itp-bug - no watch file. - A game (engine) should not need a postinst. As said, /opt is off limit for packages. Don't addgroup games. - What is about those extern/ directory? There are tarballs… e.g fox*.tar.bz. You can't have embedded code copies, if they are not in Debian they need to be packaged. You should remove the complete extern folder using Files-Exclude, if possible. (The source package is 46MiB…) - Where are the fonts in e.g deige/shared/data/data/fonts from? What is the copyright? Same for the icons? - You package does not build in a pbuilder enviornment. Missing Build-Dependencies (B-D) e.g on scons. - A ton of other B-Ds are also missing (assuming extern lists the libraries you need) Looking at your repo: https://github.com/LordOfDragons/dragengine/blob/debian/debian/rules lines 34-41 (you maybe want a install target? It should honour $DESTDIR, though) looks quite weird. Also lines 27-29 are weird (clean target not working?) Line 53-58 looks fishy to me. > and I'll apply the required changes but I will not go back to makefiles. For sure you know that cmake is a buildsystem generator. It can to create Makefiles, but it does not need to. Ok, I found many issues by only barley looking, so I marked the RFS as "moreinfo". Please fix the issues and then remove the "moreinfo" tag to have the indication for sponsors to take a look again. Please read also the "upstream guide" I posted earlier, it contains important information who to package software distribution friendly. -- Cheers, tobi > -- > Mit freundlichen Grüssen > Plüss Roland > > Game Development and Game Engine Technologies https://dragondreams.ch >
Re: Assist in maintaining a package
Hello again, I saw that the package was updated after sending some few emails, I opened a bug in the package requesting the insertion of that package in the current version's Backports. I can create a rebuild for Backports to close the error report 961482. That version needs to get to the testing first. There were no major changes compared to my test that I did packing in an unstable cage with Debootstrap. The compilation was successful and the test was performed here. Lastly in reply to Geert Stappers, I don't see that emails offering help are SPAM. Respect for a hierarchy within the project. https://salsa.debian.org/debian/drawing/ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961482 https://tracker.debian.org/news/1148896/accepted-drawing-0413-1-source-into-unstable/ https://wiki.debian.org/Debootstrap Leandro Cunha Em sex., 29 de mai. de 2020 às 06:56, Geert Stappers escreveu: > On Fri, May 29, 2020 at 05:43:55AM -0300, Leandro Cunha wrote: > > Em sex., 29 de mai. de 2020 às 05:30, Andrej Shadura escreveu: > > > On Fri, May 29, 2020 at 10:03:02AM +0200, Andrej Shadura wrote: > > > >On Thu, May 28, 2020 at 09:58:16PM -0300, Leandro Cunha wrote: > > > >> The Drawing package needs attention > ... > > > > I honestly don’t understand the urgency. You’ve been spamming me with > > > > messages about drawing while the package in Debian in only two > versions > > > > behind the upstream. There’s only been a couple of minor fixes > upstream, > > > > this can certainly wait until I find time. > > > > > > > > Also, make sure you understand: the fact you proposed an NMU doesn’t > mean > > > > it has been accepted. So you cannot meaningfully claim that you > "worked alone > > > > on packages like Drawing for Debian". All of the messages you keep > posting > > > > seems a bit like stepping on my toes and hurrying me up for no > reason. > > > > > > > > Please let me maintain the package on the pace I find appropriate. > > > > > > My previous reply was probably a bit harsh, because I was annoyed. That > > > said, I would be happy to accept help, but you need to be more patient > in > > > your attempts to provide it, because an avalanche of emails rarely > helps > > > achieve what you aim for. > > > > > > Let me illustrate. You send an email, I see it, but have a lot of other > > > work, so I don’t reply but I note it in my head, ‘oh, I need to have a > > > look at that thing’. Before I have a chance to answer, you send another > > > email. ‘Oh, but wasn’t the previous email yesterday?’ In less than a > day > > > you propose an NMU which is not of quality I would like, and also ask > for > > > upload permission, but before I have a chance to talk to you and > explain > > > what changes need to be done, you go ahead and attempt to apply for a > > > Debian Maintainer. After that email, my only reaction was to ignore any > > > further emails from you. > > > > > > I understand you’re very motivated to make Debian better, just like > myself > > > before I joined Debian, but you need to give others (e.g. me in this > case) > > > a bit more time and not press the issue instead. > > > > > > If you are okay with slowing down a bit, :) I am willing to work with > you > > > and mentor you as a prospective co-maintainer of this package. It is > small > > > enough to be a package to learn things on. > > > > > > > Hi Geert Stappers and Andrej Shadura, > > Hello Mailinglist > > > > > Thanks for the answers. > > > > As this is the first time that I have this idea of collaborating with the > > project as a contributor after many years using Debian, I haven't worked > on > > a package before and it hasn't gone through any revisions, I just read > the > > documentation and only it. I am not yet authorized to commit to Salsa. > > Which salsa account name are we talking about? > > Which "project"? ( 'project' is a gitlab name thing for git repository > plus extras plus fluh ) > > > I am > > beginning to participate more in the Debian community. So, for that I put > > in the email previous that any help, I would be very grateful. But I am > > offering support to maintain this package and I intend to upload it. I > just > > mentioned that I was testing this package in its new version release from > > upstream and at the same time studying packaging in Debian. > > > > An update now and a submission to backports would close 3 bug reports at > > once. > > Where are those changes? > > > > > > At the same time I was watching this here > > https://github.com/maoschanz/drawing#other-packages-available. > > > > I do not intend to send SPAMs to no one. > > Nobody is spamming. Every message is send with best intensions, > especial the emails with good price deals. > > Just imagine how messages are recieved. > > > > It is open for suggestions to make this work that I did even better, in > the > > quality required by the Debian project. > > > > Leandro Cunha > > > Regards > Geert Stappers > -- > Silence is hard to parse > >
Bug#961722: marked as done (RFS: xmlcopyeditor/1.2.1.3-4.1 [LowNMU] -- fast, free, validating XML editor)
Your message dated Fri, 29 May 2020 08:26:15 -0400 with message-id <49917099d7cbfd5582c7a1347302ba3a776386fe.ca...@debian.org> and subject line Re: RFS: xmlcopyeditor/1.2.1.3-4.1 [LowNMU] -- fast, free, validating XML editor has caused the Debian Bug report #961722, regarding RFS: xmlcopyeditor/1.2.1.3-4.1 [LowNMU] -- fast, free, validating XML 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.) -- 961722: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961722 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for the package "xmlcopyeditor". * Package name: xmlcopyeditor Version : 1.2.1.3-4.1 Upstream Author : Gerald Schmidt, Zane U. Ji * URL : https://xml-copy-editor.sourceforge.io/ * License : [fill in] Section : GPL-2 The source builds these binary packages: xmlcopyeditor - fast, free, validating XML editor xmlcopyeditor-dbg - fast, free, validating XML editor - debug To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xmlcopyeditor Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/x/xmlcopyeditor/xmlcopyeditor_1.2.1.3-4.1.dsc Changes since the last upload: * Non-maintainer upload. * Patch the upstream source to use pkg-config to find the libxml2 and libxslt libraries (Closes: #948793, #949512). Regards, -- Hugh McMaster --- End Message --- --- Begin Message --- Uploaded, thanks. -- Regards, Boyuan Yang On Thu, 28 May 2020 21:36:54 +1000 Hugh McMaster < hugh.mcmas...@outlook.com> wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for the package "xmlcopyeditor". > > * Package name: xmlcopyeditor >Version : 1.2.1.3-4.1 >Upstream Author : Gerald Schmidt, Zane U. Ji > * URL : https://xml-copy-editor.sourceforge.io/ > * License : [fill in] >Section : GPL-2 > > The source builds these binary packages: > > xmlcopyeditor - fast, free, validating XML editor > xmlcopyeditor-dbg - fast, free, validating XML editor - debug > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/xmlcopyeditor > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/x/xmlcopyeditor/xmlcopyeditor_1.2.1.3-4.1.dsc > > Changes since the last upload: > > * Non-maintainer upload. > * Patch the upstream source to use pkg-config to find the libxml2 and > libxslt libraries (Closes: #948793, #949512). > > Regards, > > -- > Hugh McMaster > > signature.asc Description: This is a digitally signed message part --- End Message ---
Bug#961738: RFS: dragengine/1.1 -- Drag[en]gine Game Engine
On Thu, May 28, 2020 at 11:16:18AM -0400, Boyuan Yang wrote: (..) > There are other issues but I'd rather stop here. Since you yourself is > also the upstream, > it could be possible for you to actually review the software > buildsystem (scons scripts) since it seems > to have diverted from traditional software installation procedures on > UNIX-like platforms. In any case, > the source repository and packaging scripts your provided need improvement. It is discouraged to use scons as build system [1]. If you see the possiblity please change it to something else, (e.g. cmake) [1] https://wiki.debian.org/UpstreamGuide#SCons
Bug#961785: Subject: RFS: nfq/1.0.10-1 [ITP] -- punicode DNS filter
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "nfq": * Package name: nfq Version : 1.0.10-1 Upstream Author : Joachim Bauernberger * URL : https://gitlab.com/jbauernberger/nfq/ * License : GPLv3 * Section : net It builds those binary packages: nfq - punicode DNS filter to mitigate homograph phishing attacks To access further information about this package, please visit the following URL: https://mentors.debian.net/package/nfq Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/n/nfq/nfq_1.0.10-1.dsc Changes since the last upload: - n/a Regards, -- Joachim Bauernberger
Re: Assist in maintaining a package
On Fri, May 29, 2020 at 05:43:55AM -0300, Leandro Cunha wrote: > Em sex., 29 de mai. de 2020 às 05:30, Andrej Shadura escreveu: > > On Fri, May 29, 2020 at 10:03:02AM +0200, Andrej Shadura wrote: > > >On Thu, May 28, 2020 at 09:58:16PM -0300, Leandro Cunha wrote: > > >> The Drawing package needs attention ... > > > I honestly don’t understand the urgency. You’ve been spamming me with > > > messages about drawing while the package in Debian in only two versions > > > behind the upstream. There’s only been a couple of minor fixes upstream, > > > this can certainly wait until I find time. > > > > > > Also, make sure you understand: the fact you proposed an NMU doesn’t mean > > > it has been accepted. So you cannot meaningfully claim that you "worked > > > alone > > > on packages like Drawing for Debian". All of the messages you keep posting > > > seems a bit like stepping on my toes and hurrying me up for no reason. > > > > > > Please let me maintain the package on the pace I find appropriate. > > > > My previous reply was probably a bit harsh, because I was annoyed. That > > said, I would be happy to accept help, but you need to be more patient in > > your attempts to provide it, because an avalanche of emails rarely helps > > achieve what you aim for. > > > > Let me illustrate. You send an email, I see it, but have a lot of other > > work, so I don’t reply but I note it in my head, ‘oh, I need to have a > > look at that thing’. Before I have a chance to answer, you send another > > email. ‘Oh, but wasn’t the previous email yesterday?’ In less than a day > > you propose an NMU which is not of quality I would like, and also ask for > > upload permission, but before I have a chance to talk to you and explain > > what changes need to be done, you go ahead and attempt to apply for a > > Debian Maintainer. After that email, my only reaction was to ignore any > > further emails from you. > > > > I understand you’re very motivated to make Debian better, just like myself > > before I joined Debian, but you need to give others (e.g. me in this case) > > a bit more time and not press the issue instead. > > > > If you are okay with slowing down a bit, :) I am willing to work with you > > and mentor you as a prospective co-maintainer of this package. It is small > > enough to be a package to learn things on. > > > > Hi Geert Stappers and Andrej Shadura, Hello Mailinglist > > Thanks for the answers. > > As this is the first time that I have this idea of collaborating with the > project as a contributor after many years using Debian, I haven't worked on > a package before and it hasn't gone through any revisions, I just read the > documentation and only it. I am not yet authorized to commit to Salsa. Which salsa account name are we talking about? Which "project"? ( 'project' is a gitlab name thing for git repository plus extras plus fluh ) > I am > beginning to participate more in the Debian community. So, for that I put > in the email previous that any help, I would be very grateful. But I am > offering support to maintain this package and I intend to upload it. I just > mentioned that I was testing this package in its new version release from > upstream and at the same time studying packaging in Debian. > > An update now and a submission to backports would close 3 bug reports at > once. Where are those changes? > > At the same time I was watching this here > https://github.com/maoschanz/drawing#other-packages-available. > > I do not intend to send SPAMs to no one. Nobody is spamming. Every message is send with best intensions, especial the emails with good price deals. Just imagine how messages are recieved. > It is open for suggestions to make this work that I did even better, in the > quality required by the Debian project. > > Leandro Cunha Regards Geert Stappers -- Silence is hard to parse
Re: cmake help needed for metabat
hi,
Le 29/05/2020 à 10:10, Andreas Tille a écrit :
>
>> In test/CMakeLists.txt, there is a reference to them as
>> "${CMAKE_BINARY_DIR}/contigs_depth.txt", but it should be
>> "${CMAKE_CURRENT_SOURCE_DIR}/contigs_depth.txt", unless the text files
>> should be copied while building, but that doesn't seem the case.
>
> I'll check upstream Git or file an issue about this.
>
> Unfortunately your patch did not applied cleanly - no idea why. I have
> added it manually and reread your explanation which I think are
> implemented correctly. Unfortunately in my pbuilder I get the same
> cmake failure as before and since I think I've now understand the issue
> I'm even more in vain since its not working anyway for me but you
> confirmed that it should work. Could you be so kind to have another
> look on the latest state in Git?
I've looked at your commit on git, and the issue is that you need to
remove both "add_dependencies" completely in src/CMakeLists.txt.
zlib and htslib targets doesn't exist anymore as they were created by
scripts in cmake/ folder.
>
> Thanks again
>
> Andreas.
>
--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
Re: Assist in maintaining a package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Geert Stappers and Andrej Shadura, Thanks for the answers. As this is the first time that I have this idea of collaborating with the project as a contributor after many years using Debian, I haven't worked on a package before and it hasn't gone through any revisions, I just read the documentation and only it. I am not yet authorized to commit to Salsa. I am beginning to participate more in the Debian community. So, for that I put in the email previous that any help, I would be very grateful. But I am offering support to maintain this package and I intend to upload it. I just mentioned that I was testing this package in its new version release from upstream and at the same time studying packaging in Debian. An update now and a submission to backports would close 3 bug reports at once. At the same time I was watching this here https://github.com/maoschanz/drawing#other-packages-available. I do not intend to send SPAMs to no one. It is open for suggestions to make this work that I did even better, in the quality required by the Debian project. Leandro Cunha -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEysaC+eNLfZD4qp+5nPfyyNGyXFcFAl7QwVYACgkQnPfyyNGy XFfArg/8CPRo1aRv587yI5sUPxA0vdyzr8eEZ+Kg2ZbPz+cz34OO+XnoWh9iiV+5 ++EBGJxbvLP28lgq0QunHgo0W3JBK1iMUxErIKsgfRD64iUWhCpf7zravdqwbjUs f1kc2XPxS0JLQ396lvpG/DXsWQjGt9dx5Eujwz3eeKlnQR5hTSPtU4wp4zUnwCR9 XKBtUFRK0oxSfwod9nGL6fZq3Jn3Vw9I2qQRjSby/eF9aEuGuNTRShO4dhL5pOql xlQRtHLf5ZGzq72TGVqwWxkgbJKlglOJGrRAfdD2oJHXZRoFgrDqfMUtPpKXle7j eIlP3QuX2xzCsobBpQGa+ByJFTye/+zRazySDZv3b9Q/wiLQB4rKNYFSwr0iz6tY uHj5mL9r2z/JNBzfZUemmPsxwcm0GRCUvUur9wwc77onvzfV/3vhRX1rH40zbLkR Yycq8/Bhk8bVQpKJTXaRvTX6RcyZJSV9p3OFN81yj7ele3DCFbL6gz6MWjQx497k 8kNyvQregKrN/dXKMqmDmXqRXZ8kuVdFIPH0Mytkqd2BW2vTcnX/eCOL+Pd0f0z6 yN7SVpUx7dhHsWJmXLFmdfqYaorHsbKXqG/8/0ovibp7bB2iZCZR38XeVEeTXDGs OpA1TZnubwsjb/S4p+pUUESXujTrBit8j3UnZj0IG1IVId+6pRo= =EdGi -END PGP SIGNATURE- Em sex., 29 de mai. de 2020 às 05:30, Andrej Shadura escreveu: > On Fri, May 29, 2020 at 10:03:02AM +0200, Andrej Shadura wrote: > >On Thu, May 28, 2020 at 09:58:16PM -0300, Leandro Cunha wrote: > >> The Drawing package needs attention today, the 28th, completes three > >> months without updates, and Buster does not have an alternative to > MyPaint > >> and I needed one that could be present in Backports and I can attest > that > >> it is 100% compatible. With that in mind, I offer to help maintain > >> the package in Debian and follow the upstream. The maintainer maintains > >> several packages and I intend only to help maintain it, which is Andrej > >> Shadura who is Debian Developer. I dedicated time and tested a packing > for > >> this package with NMU (non maintainer update). I did this by following > the > >> Debian developers reference for assistance. It was presented as novelty > >> for version of Mint 19.3 release in finish of 2019. I even drew > attention > >> to Mailing List debian-devel about bug report in open, asking to update > >> with date of 29th of February. > > > I honestly don’t understand the urgency. You’ve been spamming me with > > messages about drawing while the package in Debian in only two versions > > behind the upstream. There’s only been a couple of minor fixes upstream, > > this can certainly wait until I find time. > > > > Also, make sure you understand: the fact you proposed an NMU doesn’t mean > > it has been accepted. So you cannot meaningfully claim that you "worked > alone > > on packages like Drawing for Debian". All of the messages you keep > posting > > seems a bit like stepping on my toes and hurrying me up for no reason. > > > > Please let me maintain the package on the pace I find appropriate. > > My previous reply was probably a bit harsh, because I was annoyed. That > said, I would be happy to accept help, but you need to be more patient in > your attempts to provide it, because an avalanche of emails rarely helps > achieve what you aim for. > > Let me illustrate. You send an email, I see it, but have a lot of other > work, so I don’t reply but I note it in my head, ‘oh, I need to have a > look at that thing’. Before I have a chance to answer, you send another > email. ‘Oh, but wasn’t the previous email yesterday?’ In less than a day > you propose an NMU which is not of quality I would like, and also ask for > upload permission, but before I have a chance to talk to you and explain > what changes need to be done, you go ahead and attempt to apply for a > Debian Maintainer. After that email, my only reaction was to ignore any > further emails from you. > > I understand you’re very motivated to make Debian better, just like myself > before I joined Debian, but you need to give others (e.g. me in this case) > a bit more time and not press the issue instead. > > If you are okay with slowing down a bit, :) I am willing to work with you > and mentor you as a prospective co-maintainer of this package. It is small > enough to be a package to
Re: cmake help needed for metabat
Hi Alexis,
thanks a lot for your extremely helpful explanation.
On Thu, May 28, 2020 at 10:04:02PM +0200, Alexis Murzeau wrote:
>
> There is a Debian patch that replace cmake/htslib.cmake with a
> pkg_check_modules call, which doesn't create targets, so that why it fails.
> There is the same issue with zlib, and a missing header
> "metabat_version.h" created by cmake/git-watcher.cmake.
>
>
> About HTSlib issue
> --
>
> With pkgconfig, you instead get just variables (no target), including
> these interesting ones:
> - HTSlib_LIBRARIES
> - HTSlib_INCLUDE_DIRS
>
> (The HTSlib comes from the first argument of pkg_check_modules)
>
> In cmake version 3.6 and later, an argument to pkg_check_modules can
> create a target to be used with target_link_libraries that will take
> care of the libraries and include dirs.
> This is the IMPORTED_TARGET option, it will create a target named
> PkgConfig::.
>
> So you can have:
> ```
> pkg_check_modules(HTSlib REQUIRED IMPORTED_TARGET htslib)
> ```
>
> and then use it:
> ```
> target_link_libraries(target [...] PkgConfig::HTSlib)
> ```
>
> But metabat seems to require only cmake 3.5, so it might not be allowed
> for upstream to do that.
>
> Instead you can just do the same as done for Boost and add:
> ```
> include_directories(${HTSlib_INCLUDE_DIRS})
> ```
> and
> ```
> target_link_libraries(target [...] ${HTSlib_INCLUDE_DIRS})
> ```
Makes sense.
> About zlib issue
>
>
> FindPackage(ZLIB) don't create any "zlib" target, but a "ZLIB::ZLIB"
> target instead, which can be used with target_link_libraries.
>
> So you can just replace the add_dependencies(target zlib) with a new
> item there:
> ```
> target_link_libraries(target [...] ZLIB::ZLIB)
> ```
>
> About the metabat_version.h header issue
>
>
> cmake/git-watcher.cmake generate metabat_version.h from
> metabat_version.h.in.
> So as with the patch, git-watcher.cmake is not used anymore, you still
> need to handle that.
>
> Either put fake stuff like this:
> ```
> set(PRE_CONFIGURE_FILE "metabat_version.h.in")
> set(POST_CONFIGURE_FILE "metabat_version.h")
> # include(cmake/git-watcher.cmake)
>
> # Add this:
> set(GIT_RETRIEVED_STATE "")
> set(GIT_HEAD_SHA1 "nosha")
> set(GIT_IS_DIRTY 0)
> set(BUILD_TIMESTAMP 0)
> configure_file("${PRE_CONFIGURE_FILE}" "${POST_CONFIGURE_FILE}" @ONLY)
> include_directories("${CMAKE_CURRENT_BINARY_DIR}")
> ```
>
> Or you change directly the code that use these defines to use different
> data (like Debian version instead).
Makes sense. I was not up to this issue - just was dealing with errors
step by step but I guess this would have been my next question. ;-)
Thanks a lot for the proactive answer.
> Conclusion
> --
>
> I'm attaching a patch with what I've said here.
> The build still doesn't work because of tests failure.
> The tests require data files like "contigs_depth.txt" but can't find them.
OK, I need to deal with this.
> In test/CMakeLists.txt, there is a reference to them as
> "${CMAKE_BINARY_DIR}/contigs_depth.txt", but it should be
> "${CMAKE_CURRENT_SOURCE_DIR}/contigs_depth.txt", unless the text files
> should be copied while building, but that doesn't seem the case.
I'll check upstream Git or file an issue about this.
Unfortunately your patch did not applied cleanly - no idea why. I have
added it manually and reread your explanation which I think are
implemented correctly. Unfortunately in my pbuilder I get the same
cmake failure as before and since I think I've now understand the issue
I'm even more in vain since its not working anyway for me but you
confirmed that it should work. Could you be so kind to have another
look on the latest state in Git?
Thanks again
Andreas.
> --
> Alexis Murzeau
> PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F
> diff --git a/debian/patches/use_debian_packaged_libs.patch
> b/debian/patches/use_debian_packaged_libs.patch
> index 05c4a0e..b532dc9 100644
> --- a/debian/patches/use_debian_packaged_libs.patch
> +++ b/debian/patches/use_debian_packaged_libs.patch
> @@ -1,7 +1,15 @@
> -Author: Andreas Tille
> +From: Andreas Tille
> +Date: Thu, 28 May 2020 21:21:02 +0200
> +Subject: Use Debian packaged libraries
> +
> Last-Update: Thu, 28 May 2020 17:21:42 +0200
> -Description: Use Debian packaged libraries
> +---
> + CMakeLists.txt | 15 ---
> + src/CMakeLists.txt | 8
> + 2 files changed, 16 insertions(+), 7 deletions(-)
>
> +diff --git a/CMakeLists.txt b/CMakeLists.txt
> +index 638c27c..6166143 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -8,8 +8,10 @@ endif()
> @@ -17,32 +25,52 @@ Description: Use Debian packaged libraries
>
> set(CMAKE_CXX_STANDARD 11)
> set(CMAKE_CXX_STANDARD_REQUIRED ON)
> -@@ -23,7 +25,7 @@ add_definitions(-D_XOPEN_SOURCE=700)
> +@@ -23,7 +25,14 @@ add_definitions(-D_XOPEN_SOURCE=700)
>
> set(PRE_CONFIGURE_FILE "metabat_version.h.in")
> set(POST_
Re: Assist in maintaining a package
Hi Leandro, On Thu, May 28, 2020 at 09:58:16PM -0300, Leandro Cunha wrote: > The Drawing package needs attention today, the 28th, completes three > months without updates, and Buster does not have an alternative to MyPaint > and I needed one that could be present in Backports and I can attest that > it is 100% compatible. With that in mind, I offer to help maintain > the package in Debian and follow the upstream. The maintainer maintains > several packages and I intend only to help maintain it, which is Andrej > Shadura who is Debian Developer. I dedicated time and tested a packing for > this package with NMU (non maintainer update). I did this by following the > Debian developers reference for assistance. It was presented as novelty > for version of Mint 19.3 release in finish of 2019. I even drew attention > to Mailing List debian-devel about bug report in open, asking to update > with date of 29th of February. I honestly don’t understand the urgency. You’ve been spamming me with messages about drawing while the package in Debian in only two versions behind the upstream. There’s only been a couple of minor fixes upstream, this can certainly wait until I find time. Also, make sure you understand: the fact you proposed an NMU doesn’t mean it has been accepted. So you cannot meaningfully claim that you "worked alone on packages like Drawing for Debian". All of the messages you keep posting seems a bit like stepping on my toes and hurrying me up for no reason. Please let me maintain the package on the pace I find appropriate. -- Cheers, Andrej
