Bug#838941: RFS: duperemove/0.11~beta3-3 ITP
On 26 September 2016 at 23:12, wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "duperemove" > > * Package name: duperemove >Version : 0.11~beta3-3 Hi, First of all, thank you for your contribution. I am DD but can't sponsor you because my key expired. Some comments: - this is ITP bug so in d/changelog you should have one entry. with one version, with Initial release and (Closes: #). - in your patch there seems to be some UTF problem in the From: - can you push pristine tar branches to the git ? I can't build it. In d/control, the passage is not needed, options, arguments have place in a man page. "When given the -d option, duperemove will submit those extents for deduplication using the btrfs-extent-same ioctl."
Bug#761636: RFS: raceintospace/1.1+dfsg1-1 [ITP]
> >> > >> I recall reviewing this several months back; I haven't looked at it > >> again yet, but I remember that there were a number of issues with the > >> package at the time that were left unfixed, most notably that the > >> build system tries to fetch remote resources during the build itself. > >> Has this since been fixed? > > > > It does not try to fetch anymore if the dependencies are fulffiled. > > Now, with the new patch they are. I could completely patch the system > > to even not try when there are no deps presents (some weirdo archs > > maybe ). > > Yes, the build system should _never_ try to fetch any remote resource. > If build deps are unsatisfied, the result should be a FTBFS, not an > attempt to fetch the missing deps during the build itself; patch the > build system if you must in order to ensure this. > Ok the package patched not to download libs is in git, ready to be reviewed and sponsored. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#761636: RFS: raceintospace/1.1+dfsg1-1 [ITP]
On 19.09.14 11:17:17, Hendrik Weimer wrote: > Dariusz Dwornikowski writes: > > > I also filled d/copyright completely and now it works with physfs 2.0, > > which is in Debian. > > The copyright file does not contain the correct information on the > physfscompat patch. Modulo the license texts, it should read: > > Files: debian/patches/physfscompat.patch > Copyright: 2004-2014 Andrey Korotaev >2001-2011 Ryan C. Gordon and others >2014 Hendrik Weimer > License: GPL-2 and Zlib > Thank You, I will fix this asap. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
On 16.09.14 21:13:13, Tobias Frost wrote: > On Tue, 2014-09-16 at 09:07 +0200, Dariusz Dwornikowski wrote: > > > > Hi Dariusz, > > > > > > somehow the d/copyright is still not matching 100% to the code... > > > At least for many files there is a "Copyright (c) 2005-2009 Collecta, > > > Inc" which is not in d/copyright. So probably this copyright owner is > > > missing for the * rule. Can you please fix it. > > > > Yes I fixed this. > > > > > > > > Also, I'm missing see a proof for the "or later" option of the GPL, as > > > it would have to be explictly stated by upstream, see GPL-3 §14. So > > > write GPL-3 or ask upstream for clarification. > > > > Fixed, yes they have GPL-3 not later. > > > > > > (Please wrap your comment, there is also two empty lines at the end of > > > the file and one empty line in the middle. Those are nitpicks, though) > > > > Wrapped. > > > > We're there, almost... Last question: Do you want to change the license > of debian/* also to MIT and GPL-3 (without later)? > Fixed that and uploaded to mentors I chose GPL-3 for debian only -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#761636: RFS: raceintospace/1.1+dfsg1-1 [ITP]
On 16.09.14 01:05:05, Vincent Cheng wrote: > Hi Dariusz, > > On Mon, Sep 15, 2014 at 2:31 AM, Dariusz Dwornikowski > wrote: > > Package: sponsorship-requests > > Severity: wishlist > > > > Dear mentors, > > > > I am looking for a sponsor for my package "raceintospace" > > > > * Package name: raceintospace > >Version : 1.1+dfsg1-1 > >Upstream Author : Michael K McCarty > > Pace Willisson > > Krzysztof Kosciuszkiewicz > > Will Glynn > > * URL : http://www.raceintospace.org/ > > * License : GPL-2+ > >Section : games > > > > It builds those binary packages: > > > > raceintospace - free software version of the Liftoff! board game > > raceintospace-data - free software version of the Liftoff! board game - > > data file > > > > To access further information about this package, please visit the > > following URL: > > > > http://mentors.debian.net/package/raceintospace > > > > Alternatively, one can download the package with dget using this command: > > > > dget -x > > http://mentors.debian.net/debian/pool/main/r/raceintospace/raceintospace_1.1+dfsg1-1.dsc > > > > or go directly to the VCS: > > http://anonscm.debian.org/cgit/pkg-games/raceintospace.git > > > > More information about raceintospace can be obtained from > > http://www.raceintospace.org/ > > > > > > This is the initial release: > > > > * Initial release (Closes: #748321) > > I recall reviewing this several months back; I haven't looked at it > again yet, but I remember that there were a number of issues with the > package at the time that were left unfixed, most notably that the > build system tries to fetch remote resources during the build itself. > Has this since been fixed? It does not try to fetch anymore if the dependencies are fulffiled. Now, with the new patch they are. I could completely patch the system to even not try when there are no deps presents (some weirdo archs maybe ). I also filled d/copyright completely and now it works with physfs 2.0, which is in Debian. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
> Hi Dariusz, > > somehow the d/copyright is still not matching 100% to the code... > At least for many files there is a "Copyright (c) 2005-2009 Collecta, > Inc" which is not in d/copyright. So probably this copyright owner is > missing for the * rule. Can you please fix it. Yes I fixed this. > > Also, I'm missing see a proof for the "or later" option of the GPL, as > it would have to be explictly stated by upstream, see GPL-3 §14. So > write GPL-3 or ask upstream for clarification. Fixed, yes they have GPL-3 not later. > > (Please wrap your comment, there is also two empty lines at the end of > the file and one empty line in the middle. Those are nitpicks, though) Wrapped. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libstrophe" - again. The last version was rejected because of undocumented licensing. I fixed these now, after claryfing things with FTP Masters. NOTE: the package links to OpenSSL but we choose the license to be MIT, so it is not a violation. The code is however licensed both GPL and MIT. * Package name: libstrophe Version : 0.8.6-1 Upstream Author : Jack Moffit * URL : http://strophe.im/libstrophe/ * License : MIT and GPL-3+ Section : libdevel It builds those binary packages: libstrophe-dev - Library for writing XMPP clients - development files libstrophe0 - Library for writing XMPP clients - shared library libstrophe is a minimal XMPP library written in C. It has almost no external dependencies, only an XML parsing library (expat or libxml are both supported). It is designed for both POSIX and Windows systems. I worked with libstrophe upstream past months to make it suitable for Debian. I helped them with autotools, so that shared library is built along the static one. Encouraged them to tag relases in github, and together we closed some pull requests. Libstrophe is used by profanity.im, a console XMPP client inspired by IRSSI, which I intend to pack too, this week. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libstrophe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libs/libstrophe/libstrophe_0.8.6-1.dsc Or go directly to the VCS at Alioth git: http://anonscm.debian.org/cgit/collab-maint/libstrophe.git More information about *libstrophe* can be obtained from http://strophe.im/libstrophe/. Changes since the last upload: * Initial release (Closes: #511341) Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915103051.gd16...@blackstar.cs.put.poznan.pl
Bug#761636: RFS: raceintospace/1.1+dfsg1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "raceintospace" * Package name: raceintospace Version : 1.1+dfsg1-1 Upstream Author : Michael K McCarty Pace Willisson Krzysztof Kosciuszkiewicz Will Glynn * URL : http://www.raceintospace.org/ * License : GPL-2+ Section : games It builds those binary packages: raceintospace - free software version of the Liftoff! board game raceintospace-data - free software version of the Liftoff! board game - data file To access further information about this package, please visit the following URL: http://mentors.debian.net/package/raceintospace Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/raceintospace/raceintospace_1.1+dfsg1-1.dsc or go directly to the VCS: http://anonscm.debian.org/cgit/pkg-games/raceintospace.git More information about raceintospace can be obtained from http://www.raceintospace.org/ This is the initial release: * Initial release (Closes: #748321) Regards, Dariusz Dwornikowski -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#759479: RFS: profanity/0.4.4-1 [ITP]
On 29.08.14 08:24:24, Eriberto Mota wrote: > 2014-08-29 5:46 GMT-03:00 Dariusz Dwornikowski > : > >> 2. d/copyight: > >> - Put the license 'GPL-3+ with OpenSSL exception' only one time > >> in your file. You can see an example here[2]. > >> - The files have this append (not in License.txt): > >> > >> * You must obey the GNU General Public License in all respects for all of > >> the > >> * code used other than OpenSSL. If you modify file(s) with this > >> exception, you > >> * may extend this exception to your version of the file(s), but you are > >> not > >> * obligated to do so. If you do not wish to do so, delete this exception > >> * statement from your version. If you delete this exception statement > >> from all > >> * source files in the program, then also delete it here. > >> > >> - Please, use the license from a file. > >> - To public license, insert a period (.) at the end of sentence. > >> - To public license, use the years found in src/tools/p_sha1.c > >> (it will be equal to .h) > > > > yeah I did that but do not know if this is what you meant. > > No... Please, see the attached example. > Sorry for that. Updated as you requested.. and new version in mentors. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#759479: RFS: profanity/0.4.4-1 [ITP]
> Hi again Dariusz. Please: > > 1. d/control: reorganize your long description using topics. You can > see an example here[1]. As suggestion to increase the chance of the > users find your package, add the words 'Jabber', 'instant messenger > (IM)' and 'network'. I did my best there, fixed the description to look better and included some keywords. > > [1] http://sources.debian.net/src/bittwist/2.0-4/debian/control/ > > 2. d/copyight: > - Put the license 'GPL-3+ with OpenSSL exception' only one time > in your file. You can see an example here[2]. > - The files have this append (not in License.txt): > > * You must obey the GNU General Public License in all respects for all of the > * code used other than OpenSSL. If you modify file(s) with this exception, > you > * may extend this exception to your version of the file(s), but you are not > * obligated to do so. If you do not wish to do so, delete this exception > * statement from your version. If you delete this exception statement from > all > * source files in the program, then also delete it here. > > - Please, use the license from a file. > - To public license, insert a period (.) at the end of sentence. > - To public license, use the years found in src/tools/p_sha1.c > (it will be equal to .h) yeah I did that but do not know if this is what you meant. > > [2] > http://metadata.ftp-master.debian.org/changelogs/main/n/netmate/unstable_copyright > > 3. To test, I need libstrophe-dev. Libstrophe can be built from my git repo, best if you use -2 library. -1 has some problems, that do not affect its functionality but makes profanity crash sometimes. I will upload -2 as soon as -1 gets into Debian. http://anonscm.debian.org/cgit/collab-maint/libstrophe.git New Profanity package version is in mentors now. > > Thanks for your work. Very good. > > Cheers, > > Eriberto > > > 2014-08-27 11:32 GMT-03:00 Dariusz Dwornikowski > : > > Package: sponsorship-requests > > Severity: wishlist > > > > I am looking for a sponsor for "profanity". I managed to convince > > upstream (fortunately one copyright holder) to add OpenSSL exception. > > > > Mind that profanity depends on libstrophe-dev, which is in NEW now. > > > > * Package name: profanity > > Version : 0.4.4-1 > > Upstream Author : James Booth > > * URL : http://www.profanity.im/ > > * License : GPL-3+ with OpenSSL exception > > Section : net > > > > It builds those binary packages: > > > > profanity - Console based XMPP client > > > > Profanity is a console based XMPP client written in C, > > inspired by Irssi. > > It Supports: > > . > > XMPP chat services, including GoogleTalk and Facebook. > > OTR message encryption > > Roster management > > Desktop notifications > > Flexible resource and priority settings > > > > > > To access further information about this package, please visit the > > following URL: > > > > http://mentors.debian.net/package/profanity > > > > Alternatively, one can download the package with dget using this command: > > > > dget -x > > http://mentors.debian.net/debian/pool/main/p/profanity/profanity_0.4.4-1.dsc > > > > Alternatively, you can access my alioth git repo here: > > > > http://anonscm.debian.org/?p=collab-maint/profanity.git;a=summary > > > > More information about *profanity* can be obtained from > > http://www.profanity.im > > > > Changes since the last upload: > > > > * Initial release (Closes: #745872) > > > > Regards, > > - -- > > Dariusz Dwornikowski, > > Institute of Computing Science, Poznań University of Technology > > www.cs.put.poznan.pl/ddwornikowski/ > > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > > > > > > -- > > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > > with a subject of "unsubscribe". Trouble? Contact > > listmas...@lists.debian.org > > Archive: > > https://lists.debian.org/20140827143228.gb29...@blackstar.cs.put.poznan.pl > > -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Bug#759479: RFS: profanity/0.4.4-1 [ITP]
> Hi Dariusz, > > I'm not a DD, so I can't sponsor your package, but here's my review: > > d/changelog: > -Remove the note about the "UNRELEASED" 0.4.3 > > d/copyright: > -You should release the Debian-specific changes also with the OpenSSL > exception > -src/tools/p_sha1.c and src/tools/p_sha1.h appear to be in the public domain > > I haven't been able to test the software yet since libstrophe hasn't > been accepted yet, but I can see that it's in the NEW queue. > Thanks for good catches. The new version of package is now in mentors. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#758646: RFS: ryu/3.12-1 [ITP]
> Hi! > > A last issue... > > I think that there a mistake in d/copyright. You removed the original > debian/ when you generated the tarball and remade the debian/ > structure. So, I think you must remove the upstream name from debian/* > in d/copyright and should add a d/README.source to explain about the > original debian/ remotion. > > I will wait your opinion. > I will leave them there because some of things they have done I kept. I think that explaining removal of debian/ is not neccessary. It is generally done out of the box by git-import-orig anyways. But personally I think it does not hurt, I added the explanation as you suggested. The new version is in mentors. > > > 2014-08-27 3:40 GMT-03:00 Dariusz Dwornikowski > : > >> Hi Dariusz, how are you? > >> > >> Please: > >> > >> 1. d/clean: you package doesn't build twice because the d/clean > >> removes files only (not directories - man dh_clean). :-P > >> > >> I saw you are using an override in d/rules to remove files. Why you > >> need a d/clean? > > > > I fixed that, now it is onlu in d/rules. I use git-buildpackage, my > > build area is in a different place, so for me the package always built > > cleanly twice. > > > >> > >> 2. d/control: in short descriptions, remove the program name and put > >> each designation between brackets. My suggestion: > >> > >> Description: defined networking framework (Python libs) > >> Description: defined networking framework (ryu binary) > >> Description: defined networking framework (docs) > > > > Great advice, I followed it. > > > >> > >> You can change it. > >> > >> 3. d/copyright: > >> - debin? :-D > >> - Please, review all source code carefully. I didn't see the > >> 'Nippon Telegraph and Telephone Corporation' in your d/copyright. > > > > Yes, I updated the copyright, also did som clarification on a "weird" > > license I encoutered inside on debian-legal@ [1]. > > > >> > >> 4. d/docs: I think that this file is a mistake because you created the > >> python-ryu-doc.docs. Am I wrong? > >> > > > > You are not wrong mister :) I deleted the docs file. > > > >> 5. d/ryu-bin.ryu.init: please, remove all useless lines as "Add code > >> here, if necessary,...". > > > > I deleted not needed comments. > > > >> > >> 6. d/ryu.conf: I think it is confused. Can you add comments to help > >> the user? Please, adopt a format to commented lines (# with spaces or > >> # without spaces). > > > > Did some research on this, kept only options needed to run basic ryu > > and commented them. I deleted options connected to OpenStack, if > > someone wants to run OpenStack with ryu, they should use OpenStack's > > doc howto do it, not ryu's. > >> > > [1] https://lists.debian.org/debian-legal/2014/08/msg00073.html > > > > > > I uploaded the new version to mentors. > > > > -- > > Dariusz Dwornikowski, > > Institute of Computing Science, Poznań University of Technology > > www.cs.put.poznan.pl/ddwornikowski/ > > room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#759479: RFS: profanity/0.4.4-1 [ITP]
Package: sponsorship-requests Severity: wishlist I am looking for a sponsor for "profanity". I managed to convince upstream (fortunately one copyright holder) to add OpenSSL exception. Mind that profanity depends on libstrophe-dev, which is in NEW now. * Package name: profanity Version : 0.4.4-1 Upstream Author : James Booth * URL : http://www.profanity.im/ * License : GPL-3+ with OpenSSL exception Section : net It builds those binary packages: profanity - Console based XMPP client Profanity is a console based XMPP client written in C, inspired by Irssi. It Supports: . XMPP chat services, including GoogleTalk and Facebook. OTR message encryption Roster management Desktop notifications Flexible resource and priority settings To access further information about this package, please visit the following URL: http://mentors.debian.net/package/profanity Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/profanity/profanity_0.4.4-1.dsc Alternatively, you can access my alioth git repo here: http://anonscm.debian.org/?p=collab-maint/profanity.git;a=summary More information about *profanity* can be obtained from http://www.profanity.im Changes since the last upload: * Initial release (Closes: #745872) Regards, - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827143228.gb29...@blackstar.cs.put.poznan.pl
Bug#758646: RFS: ryu/3.12-1 [ITP]
> Hi Dariusz, how are you? > > Please: > > 1. d/clean: you package doesn't build twice because the d/clean > removes files only (not directories - man dh_clean). :-P > > I saw you are using an override in d/rules to remove files. Why you > need a d/clean? I fixed that, now it is onlu in d/rules. I use git-buildpackage, my build area is in a different place, so for me the package always built cleanly twice. > > 2. d/control: in short descriptions, remove the program name and put > each designation between brackets. My suggestion: > > Description: defined networking framework (Python libs) > Description: defined networking framework (ryu binary) > Description: defined networking framework (docs) Great advice, I followed it. > > You can change it. > > 3. d/copyright: > - debin? :-D > - Please, review all source code carefully. I didn't see the > 'Nippon Telegraph and Telephone Corporation' in your d/copyright. Yes, I updated the copyright, also did som clarification on a "weird" license I encoutered inside on debian-legal@ [1]. > > 4. d/docs: I think that this file is a mistake because you created the > python-ryu-doc.docs. Am I wrong? > You are not wrong mister :) I deleted the docs file. > 5. d/ryu-bin.ryu.init: please, remove all useless lines as "Add code > here, if necessary,...". I deleted not needed comments. > > 6. d/ryu.conf: I think it is confused. Can you add comments to help > the user? Please, adopt a format to commented lines (# with spaces or > # without spaces). Did some research on this, kept only options needed to run basic ryu and commented them. I deleted options connected to OpenStack, if someone wants to run OpenStack with ryu, they should use OpenStack's doc howto do it, not ryu's. > [1] https://lists.debian.org/debian-legal/2014/08/msg00073.html I uploaded the new version to mentors. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Bug#759296: RFS: psensor/1.0.4-1
> > > > I am not DD, I cannot sponsor you package but have a question, > > why is priority for psensor extra ? Should it not be optional ? > > > > [1] https://www.debian.org/doc/debian-policy/ch-archive.html > > According to the definition of 'optional': > "This is all the software that you might reasonably want to install if > you didn't know what it was" On the other hand the definition for extra is: The extra priority will usually work for new packages that conflict with others with non-extra priorities. Since your package is normal package and does not conflict with anything else, IMHO it should be optional. extra is fine for debugging symbols, maybe big manuals and so on. Your package is a GUI that can be optional. Policy also points to TeX as an example. You do not need it, it is optional, you can install it and it will not conflict with anything else. > > psensor is a GUI for monitoring hardware sensor, it displays graphs and > raise alerts to users (AppIndicator, notify bubbles, tray icon). AFAIK, > it is not required by any other packages. > > I don't see any reason why it should be installed if the user does not > want to access himself information about fan speeds, CPU temperatures, > etc. I don't believe that most users take care of this kind of information. Optional does not mean this. It just means "hey you can install it if you want or need this package". It does not imply that you must install it or it is pulled by something. That is just my opinion, it would be the best that some DD would clarify this, thus I cc eriberto on this. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Bug#759296: RFS: psensor/1.0.4-1
On 26.08.14 00:28:28, jeanfi wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "psensor" > > * Package name: psensor >Version : 1.0.4-1 >Upstream Author : Jean-Philippe Orsini > * URL : http://wpitchoune.net/psensor > * License : GPL v2 >Section : utils > I am not DD, I cannot sponsor you package but have a question, why is priority for psensor extra ? Should it not be optional ? [1] https://www.debian.org/doc/debian-policy/ch-archive.html -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#742077: RFS: vcmi/0.95-1 [ITP]
Hi Johannes, Thanks for your work, but I think that your package should go to contrib, because in order to work it needs HoMM game, so it depends on something non free [1]. Installation instruction from upstream's web page clearly state that you need to install Heroes data files [2] I also found info on this game on Debian Games suggested games website [3] stating the above. I am CCing the Debian Games list too. [1] https://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib [2] http://wiki.vcmi.eu/index.php?title=Installation_on_Linux [3] https://wiki.debian.org/Games/Suggested#VCMI -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140823090409.ga7...@blackstar.cs.put.poznan.pl
Bug#758907: RFS: penguin-command/1.6.11-3 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "penguin-command" * Package name: penguin-command Version : 1.6.11-3 Upstream Author : Karl Bartel * URL : http://www.linux-games.com/penguin-command/ * License : GPL-2+ Section : games It builds those binary packages: penguin-command - missile command clone To access further information about this package, please visit the following URL: http://mentors.debian.net/package/penguin-command Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/penguin-command/penguin-command_1.6.11-3.dsc More information about *penguin-command* can be obtained from http://www.linux-games.com/penguin-command/. Changes since the last upload: * New maintainer (Closes: #728867) * gbp.conf added * migrated to autoconf, and newer automake-dev * dropped cdbs from d/control * desktop file added (Closes: #738000, #472573) * Vcs filed added to d/control * zlib added to Build-Deps (Closes: #672943) * Patch added to fix install dir for .ja manpage (Closes: #337762) Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140822174835.ga16...@blackstar.cs.put.poznan.pl
Bug#758815: RFS: libircclient/1.8-1 [ITA]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 21.08.2014 21:16, Eriberto Mota wrote:
> tags 758815 moreinfo thanks
>
>
> Hi Dariusz.
>
> Please:
>
> 1. d/changelog: add an explanation about why your removed the -dfsg. Please,
> see the field 'Source' in d/copyright header.
Done, good catch thanks.
>
> 2. d/control: in 'Package: libircclient-dev', remove 'Pre-Depends:
> ${misc:Pre-Depends}'.
Done.
>
> 3. d/copyright: - Fix the 'Source' field in header.
Fixed.
> - See it[1] and put the correct range of the years for each Debian
> maintainer.
Fixed.
> - Update the upstream copyright years (2004-2013).
Fixed.
> - Search with 'grep -sri copyright * | grep -v Georg' for other authors.
Did that. Added Authors from cocoa/ folder.
>
> [1] https://packages.qa.debian.org/libi/libircclient.html
>
> 4. libircclient-dev.install: remove .a. From Maintainers Guide[2]:
>
> Shared libraries are distributed as *.so files. (Neither *.a files nor *.la
> files)
>
> [2] https://www.debian.org/doc/manuals/maint-guide/advanced.en.html[2]
>
I will leave them if it is ok with you.
> 5. Remove useless file README.source.
Done.
>
> 6. Please, tell me why you make a patch. Your package is installing
> libircclient.h only. The original program is installing libirc_options.h,
> libircclient.h, libirc_errors.h, libirc_rfcnumeric.h and libirc_events.h.
Good catch, super thanks. I added installing of other header files. I made patch
because the legacy build system builds only one .so file, and I was advised on
#debian-mentors that it is better to patch build system than to make symlinks
for ldconfig in d/rules.
>
> 7. The upstream site has lot[3] of instructions about the library. I suggest
> you create a README.Debian with notice about it.
>
> [3] http://www.ulduzsoft.com/libircclient
>
I added this, you are right it is nice to have some doc.
I reuploaded to mentors, also this can be found in my collab-maint repo.
- --
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQIcBAEBCAAGBQJT9xlYAAoJECEac8aaew/HcTsP/1VgYlvF9tStexwMEKogLRm/
3HUHFiStFwJ094m2GbECfEKaIMclHcVqSbQVLGpOqESOgDmhsIEXS3E8pNe3qOxr
nb3pzTIhNOLo97CCR6zoMKQRMjPNp1BiQweQYuFw+UtwZobdBz5y2KEwBugCYSmg
K3wFthwL5P2shc9yUvvpJJJyrJfe6YixhlwGiBh+gP1h5XdkjmtSH/UOfPP7ib0G
J+cjTLmKu8ydeedKaItPOE4waCF8a6HzAWeWvH62u/wSTqg7J50rTSqYB6CSe4P2
EqG8UL9eJnbGwBP7I5ZoorctqCuoCsYoeoWELRoU+yqIPvOgHpt7OLwPV55Lxj68
LdGTyynjb5kzUf/pT9ErVxE4eFlPOoB9VZ0KiSSvwv2/gTWTKVq+C0RboreJ2Qz7
LjOsaxipe2bz/2iGT+MngleS6Ljt/Cn2f1q6G8ATMYnZi4pzldlqT5mJbMNyTrAu
/sZSGYd4GF2tKkHsZYKdMeCg0w/ogrEfQwlAKZECk6hsiWrxBMhGkYnb8Ngm1yXs
Q1f3Fa6o4+dGuzkzwACZUB7msew2pv4bNaceKBcFrQmkkKcM3OUbmtMCy9/kw6QC
b875AH6fY+5xoWrfplrTWMlk8bk8MrXEqg0+Njh2IQxwEUMmBIR3yjwsu0v9LVOS
OnsHK4Jk964V8XxkQKVF
=ZgKY
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f71958.6080...@cs.put.poznan.pl
Bug#758815: RFS: libircclient/1.8-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libircclient" * Package name: libircclient Version : 1.8-1 Upstream Author : George Yunaev * URL : http://sourceforge.net/projects/libircclient/ * License : LGPL-3+ Section : libdevel It builds those binary packages: libircclient-dev - development files for libircclient libircclient1 - C library to create IRC clients To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libircclient Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libi/libircclient/libircclient_1.8-1.dsc More information about libircclient can be obtained from http://sourceforge.net/projects/libircclient/. Changes since the last upload: * Imported Upstream version 1.8 * Bump standards to 3.9.5, no changes needed * New maintainer (Closes: #674882) * Build-Dep in d/control changed to debhelper>=9 * Added myself to d/copyright * d/compat changed to 9 * Deleted 00_fix_missing_headers patch, not needed * Added dh-autoreconf to Build-Deps * Switched to multiarch (Thanks Andreas Rönnquist) * patch/proper-lib-building.patch - removed old build system - uses autoconf and libtool - allows using legacy --enable system Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#758691: RFS: profanity/0.4.3-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20.08.2014 18:36, Jakub Wilk wrote: > * Dariusz Dwornikowski , > 2014-08-20, 15:39: >>> It's still linking with OpenSSL, via libstrophe, right? This >>> won't work. Also, libstrophe isn't packaged. >> >> It is linking to libstrophe, which is linking to ssl. Lintian >> does not bork about this, since it is not a direct linking. > > If the copyright file is in the machine-readable format, > and it says that all the files are GPL-ed (which is the case here > AFAICS), then adequate(1) should be able to detect GPL+OpenSSL > license conflict, even when it is caused by indirect linking. > > In fact adequate does the job but only after the installation of the package, not while building. Anyways, good to know this tool, and... profanity is violating the license. Back to upstream then :) - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9NF+AAoJECEac8aaew/HHSkQANCiJzyn2jdZ2NNmUgNnGY40 pCuY602SA+j5zjKQqP1Tsu8swNe7xJuxy2756ssfCej+/pptaV+ubLeDakmh1b0m 70ANZXkG1wA+33D9b+HjV9v75sJyKbfSd+gK3Ofb6mfBOStcMYgWhb8l5pUnHBYE dR0FUgPo6Sy9iESD0me3es1YrtHxmVoVn0giHUxmnMWnmUBDpbfvYAT2g5NOvULq hyBPwilvsbCglg9D5wHWiz4AIvNNla35dZi0jX1Mj8wv/+gpf1q7s5eRBhC7hCdv 0tFU1ONHdd1zX/xQSQ53kDXcscxTKnP/voE9tXtTMBeWcQAzqeGEYvNug7/qUvd1 TWr+5RXDhRHFcFMVOYjy1yysX16NGOQnmRnTfHKF6ClPOWkd2v0bVECWysNvy+Zm DfiKkWJWwf9Xaw2Nn+TGU/CjWlyAvWkaHkN4/6seZTHz4DdHeLF15S7fvgYdzo5Z feSyl0O0Z5/M/ZKhQjNDGxygly/GeGUdCiQqgBAqT7dGGkjjmuj51NufwZS1Ulv5 NCop+2FGy8yVHG8EGotzhy2weFcIj7aXbyfaNXetiVrXKxTIZ/RtIfsIBf/Bbpcr JJxZHVL+420Ehz/FMp76gSSp5qv4w9bFuD2cSzvMaWz3cNZyvJE/paUIMzplkixF ULmrA3g9SGvkGFpCVoYe =fa7R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f4d17e.3050...@cs.put.poznan.pl
Bug#758691: RFS: profanity/0.4.3-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20.08.2014 14:31, Andrey Rahmatullin wrote: > On Wed, Aug 20, 2014 at 09:16:06AM +0200, Dariusz Dwornikowski > wrote: >> http://anonscm.debian.org/?p=collab-maint/profanity.git;a=summary > >> ITYM http://anonscm.debian.org/cgit/collab-maint/profanity.git/ > > It's still linking with OpenSSL, via libstrophe, right? This won't > work. Also, libstrophe isn't packaged. > It is linking to libstrophe, which is linking to ssl. Lintian does not bork about this, since it is not a direct linking. Profanity's linking to ssl is redundant and not needed, I removed it with a patch, also upstream removed it from the master branch (not released yet). It is still a violation ? If it is I could force upstream to add the excerpt. Libstrophe is waiting in the NEW queue already. - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9KUoAAoJECEac8aaew/HyQUQAK4Ckqx04qVvBlWMsfQ/wjfk pqq8ojvWTJoAyqwNKYawN86I/kUIiY9rU2ysKYNzjLk7SB0D92VKJk82/B05BaxX 7juHZdrCupHs4zc9962fxvopPQ42n4xkw/LfUNYWguFME5+F0AD/LIKaYsEGA682 42Y2CS+V6cadSDeWLqZNXJUm6ehetmryOm7jmNq5TGAY89n9GP/jW5B2x26ksaVe KkOQ7tvp6X/mBZ1uLZgPNbkNL1pVjW+kQBEWFEBcY16ZSkzGGN2mJIwNPc1G/frf 9CaTfqIRAlxkQqcNrjipaaDRvgXuLH0DXODmsvHoJ5DFg3jjpv/MOQGQpTcuA64j vIxqa02IlCrZxLsemqqfLYtMbXeHyIrZwvj06QcSaCRVJEy2BWTrQHzs/3Mpcrq2 Aivx7xZzQyWtpZ/m77H4DATxPvQ5WDIUteW5dYudVmFPoN8RhXeYEaNHCrta4uYw IMx2EmrzvrtmZCe07F2EB3Xxjvbze80UqqiMt3w/L/MbLgUd+3NGvZtdXs/2XT2c MTz6n0nUUmk3SwI1lmNCuoyBdLmJsUv54nKbU8E86i7THrXo5Og3znMwBZroVuyG h1IEQPzX49mKPyzLiXQ8rekMkHCPT8APCdZ13H34FoodpLUs0YwHe4fP23mgWNB4 KYaDzEomccSPitnIFOGF =qein -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f4a528.8060...@cs.put.poznan.pl
Bug#758691: RFS: profanity/0.4.3-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 20.08.2014 09:42, Jeroen Massar wrote: > On 2014-08-20 09:16, Dariusz Dwornikowski wrote: >> Package: sponsorship-requests Severity: wishlist >> >> * Package name: profanity Version : 0.4.3-1 Upstream >> Author : James Booth * URL : >> http://profanity.im/ > > Without www that URL does not work[1]. http://www.profanity.im/ > does work. Thanks, I fixed that in git. - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9Fb7AAoJECEac8aaew/HOZQP/Rbo6F7LNzsLGMCGDI/dp+2z FnA3ac+S0La0KJKhBdF/2S/QKanFYl3AErDx/FGAhRvwZ40L1qO9ERfvZN6FFmki 8V3AqX7kwjKXxj00KRXJQLcegZO3inxP0N8nNmK5tg6ky0y5GuWyeoaMh6agLRig k05mYT/Qch7DaWwnvoyu6Njz1tOMIV7y/DKTLjWGREn0t/mG5wH+idzf+qJAVCW2 q/I2MJHjFI4Ftb+7U5lXlCQJ4SVRg/hJRTfvKtn1oGbep0nR1YyfxS5yTAu8NAWK /1EhJ7Wu+oU8KlpukL0Gg8ur/OEsiKElM0xS7VShNJT0JejnHs16ta8Tg9MqmHfS uJmrUjFUm6O3EJ4xZF1O0TG4jaNSLlNR7NELMEpuZ6DaO6m6LbqLo+E0Q7PSuVUH 7JjIX4GViU9NNRqP9rikfwRjet1FEtpyjpw6qKH9SrGs0xVvA9MT8FKLk/VddM2N 9e+pEuRq4ie7VNyvxzeD0UQy2MN+GZOnWNzECiniG9Z/omCLTjzpg9c7qZ0/EKfc lbqh1V31mEZTcxKP/DAZIbMnaT75uHiDVXj/A/TiVtwnPmpW0rSJLU4zGv6R7SfI +RWmFvRG46fvn+glQ9m+C+MASmQ/pLjvJOgff+3CrLWNbhrchOuqQRcICklUJZ+l FIlTk4Jz8AZ5ijBMo7mt =Qi8m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f456fb.8000...@cs.put.poznan.pl
Bug#758691: RFS: profanity/0.4.3-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: sponsorship-requests Severity: wishlist * Package name: profanity Version : 0.4.3-1 Upstream Author : James Booth * URL : http://profanity.im/ * License : GPL-3+ Section : net It builds those binary packages: profanity - Console based XMPP client Profanity is a console based XMPP client written in C, inspired by Irssi. It Supports: . XMPP chat services, including GoogleTalk and Facebook. OTR message encryption Roster management Desktop notifications Flexible resource and priority settings To access further information about this package, please visit the following URL: http://mentors.debian.net/package/profanity Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/profanity/profanity_0.4.3-1.dsc Alternatively, you can access my alioth git repo here: http://anonscm.debian.org/?p=collab-maint/profanity.git;a=summary More information about *profanity* can be obtained from http://profanity.im Changes since the last upload: * Initial release (Closes: #745872) Regards, - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT9Es2AAoJECEac8aaew/HcRgP/RkxwUruMJSqXWYCdoZ6aaaZ gipc88ZXsSuZ/MmJx+4SNaqT94ORSsqUWyPtGqDBraMtUHPYNdEPEM9NYdih7UR3 49Wjx9IL2sGuIHI7qCX/34ys2C+fw0yJ+jZMmnPz5KUxW2/uotY6abyNxgslK4OT rkhkDkD+tUC17YYVTEI+W84o9zfKbjFBcojawfaQT3/uGgkBnnk+C3+iQopociTQ WsRSKhba0R+oXFzjc6d5x1G+MDxwURIhnrVIvWZevYrDb0FMmxI0e33MNQtvqtW5 iX4BAkRcAEfZowlLm0lpxTPLbCeY0/fXKcmfoGOrYAG00/YAlnse/8g5PN9NcBo1 9zifx/fMlPwUKq29Bjb3L1QwPHPJwQ4Kl4BG4vTR5pWL9mcSqhtEg9sGB5dULyIh ysnivQXYa+R0pFHnqlXoLltzEd4jnYwae8QcJENqVnzbghNSAuQSzamTOd9ivDyu 63xGR/BEgtkb+fFg7SS/JRplgCiGAH0kTqBq36p38zq5mnAejDBx2JR8uOCVf+LK GPteqX51TGRO9yml8wdAUklOmne+nsgvWQ56gG/sjzvWvkOg+/worFkZtvI1CEol raWZ7WT9SQMCYdSjjzFoqt4hI8Ncw7G9pHatIZtAVEDBl+RqjVo7nh61OgATBPsq 60F6xO5liDYehg2XAdOx =wbsm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f44b36.3020...@cs.put.poznan.pl
Bug#758646: RFS: ryu/3.12-1 [ITP]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: sponsorship-requests Severity: normal [wishlist] Dear mentors, I am looking for a sponsor for my package "ryu" * Package name: ryu Version : 3.12-1 Upstream Author : Ryu Project Team * URL : http://osrg.github.io/ryu/ * License : Apache 2.0 Section : python It builds those binary packages: python-ryu - Ryu is a software defined networking framework -- Python libs python-ryu-doc - Ryu is a software defined networking framework -- ryu docs ryu-bin- Ryu is a software defined networking framework -- ryu binary To access further information about *ryu* , please visit the following URL: http://mentors.debian.net/package/ryu Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/ryu/ryu_3.12-1.dsc Or you can directly see my alioth repo: http://anonscm.debian.org/gitweb/?p=collab-maint/ryu.git More information about ryu can be obtained from http://osrg.github.io/ryu/ Changes since the last upload: * Initial release (Closes: #758509) Regards, - -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT82pzAAoJECEac8aaew/H2VEQAI44tnm3PdTH0rg/6ukWs9j7 fODUnQmB4dzwoUHBy0mJwVZJfTjYlMWa+UJPsZ4ZuG0UuKTVfkW9aUa86K8N809A R6x3qVAdMEOsMZAKky28/EBLKZ2uZfQKypPqrKoSYnHa8F5S2ZUBz5Wl1yrdmMKo IEHbW9LAw8xBl7uCo72kr7NF+2XhRy2hUzk3KC8vL2nohMufc3PJeOZnTarr6kUg hNXjBajlw11KL565YxJUNhIXxW9dGdtR9sqeh/ejO+P30BZZKnnLq9rUanwQdOvv jnIkZKbNWKdyYo6mK5u1hSOQ3Uaxcv4XiiTWvCx7Wp1rD27g8b1wzq9GfIyMB/Es 2tRsYpxWIRfZi4asksqIG+P5+gzWvz8wdjHN9xSo4CrT7XlLjYwbGlYDJPpp69fD jr+O7fQBwUpt5SNamsCPjHOnMOldJ+gune8kY/K0wFUG+BLXqIZq6NZRB17U9vpl 7eumPDn6iiy33z3bcj/jEVRuvcjFU7FL+NHJEaoC7PE1Qk0PFhhAB2gaYMvMhtAj KZs7qgOoDVATNa0XNLE4ZNHzLARGm8dYrmkDo0AjRc77H7R3UtmKdP3AFBM8+5hX tm52hVmJ5Qq6acOrBTILpgSw5jv5+Tdla+Bb9wMvCqTgKogwShKti3eVtMf4wHRc CaRayHCLjelJnwwj3luM =jtgg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f36a73.5000...@cs.put.poznan.pl
Bug#757669: RFS: libstrophe/0.8.6-1 [ITP]
> > This Pre-Depends is necessary due for the multi-arch support. See > https://wiki.debian.org/Multiarch/Implementation > > Ok, just a last nitpick I missed earlier. > your debian/*.dirs are not needed (refer to > https://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs > I think you can remove them :) Done, thanks for spotting this. > > So, let me know when you uploaded your new version to mentors... The new version has been uploaded to mentors. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811073158.gc19...@blackstar.cs.put.poznan.pl
Bug#757669: RFS: libstrophe/0.8.6-1 [ITP]
> Hi Dariusz,
>
> reviewing.. As usual here an (unordered) list:
Thank you.
>
> -> please read d/README.source and act accordingly :)
Done. Deleted, since not needed anymore.
>
> -> d/copyright
> The source is dual-licensed. Please correct the license.
> The line
> Copyright (c) 2005-2009 Collecta, Inc.
> is misplaced (I think you wanted to put it two lines earlier)
> as this is not part of the license.
I always act according to the rule "when in doubt, copy the whole
license from upstream". Their MIT-LICENSE.txt is with this Copyright
line.
https://github.com/strophe/libstrophe/blob/master/MIT-LICENSE.txt
I deleted the line from there.
>
> Same below with the debian/* files.
>
> Regarding License.txt... They say
> "This program is dual licensed under the MIT *and* GPLv3 licenses."
> (emphasis by me) Do upstream mean "or" here? (I'm not sure if you can
> comply to both licenses at the same time; better ask debian-legal if the
> "and" is ok or if a sentence like "on your choice" is missing.) It would
> be anyway great if upstream could add a license header NOT refering to
> LICENSE.txt in every file ... as this could create problems if a file is
> to be used outside of libstrophe. It would be much clearer, also
I already created an issue in github to clean this. As for dual
license thing, I did ask for opinion on that months ago and got an
answer from Russ Albery, claiming that I could just "pick" a license.
Here is the relevan post:
https://lists.debian.org/debian-mentors/2014/05/msg00055.html
I will also write to Debian legal to look at this.
>
> (As they link against openssl, they probably need the openssl exception
> when applying the GPL. Refer also to
> https://lists.debian.org/debian-legal/2002/10/msg00113.html) Shouldn't
> be a problem for MIT, but IANAL.)
>
> -> d/docs has the license text files and you exclude them in again in
> d/rules...This program is dual licensed under the MIT and GPLv3
> licenses.
I cleaned this now, thanks.
>
> -> why no symbols file?
Added symbols file with the help of dpkg-gensymbols. Already in git.
>
> -> d/rules
> you should call bootstrap in override_dh_autoreconf, not in
> override_dh_auto_configure:
>
> override_dh_autoreconf:
> dh_autoreconf ./bootstrap.sh
>
> Then you also won't need to override autoclean.
> (I any prefer a clean file over overriding debhelper targets)
Super thanks for that !
>
> (Also please unset DH_VERBOSE when uploading...)
Yes, deleted now.
>
> "unused substitution variable ${misc:Pre-Depends}"
> Pre-Depend is missing in d/control (multi-arch support...)
>
According to policy 7.2, putting Pre-Depends should be first discussed
on dd@, or am I missing something ?
--
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
signature.asc
Description: Digital signature
Bug#757669: RFS: libstrophe/0.8.6-1 [ITP]
> Hi Dariusz,
>
> reviewing.. As usual here an (unordered) list:
Thank you.
>
> -> please read d/README.source and act accordingly :)
Done. Deleted, since not needed anymore.
>
> -> d/copyright
> The source is dual-licensed. Please correct the license.
> The line
> Copyright (c) 2005-2009 Collecta, Inc.
> is misplaced (I think you wanted to put it two lines earlier)
> as this is not part of the license.
I always act according to the rule "when in doubt, copy the whole
license from upstream". Their MIT-LICENSE.txt is with this Copyright
line.
https://github.com/strophe/libstrophe/blob/master/MIT-LICENSE.txt
I deleted the line from there.
>
> Same below with the debian/* files.
>
> Regarding License.txt... They say
> "This program is dual licensed under the MIT *and* GPLv3 licenses."
> (emphasis by me) Do upstream mean "or" here? (I'm not sure if you can
> comply to both licenses at the same time; better ask debian-legal if the
> "and" is ok or if a sentence like "on your choice" is missing.) It would
> be anyway great if upstream could add a license header NOT refering to
> LICENSE.txt in every file ... as this could create problems if a file is
> to be used outside of libstrophe. It would be much clearer, also
I already created an issue in github to clean this. As for dual
license thing, I did ask for opinion on that months ago and got an
answer from Russ Albery, claiming that I could just "pick" a license.
Here is the relevan post:
https://lists.debian.org/debian-mentors/2014/05/msg00055.html
I will also write to Debian legal to look at this.
>
> (As they link against openssl, they probably need the openssl exception
> when applying the GPL. Refer also to
> https://lists.debian.org/debian-legal/2002/10/msg00113.html) Shouldn't
> be a problem for MIT, but IANAL.)
>
> -> d/docs has the license text files and you exclude them in again in
> d/rules...This program is dual licensed under the MIT and GPLv3
> licenses.
I cleaned this now, thanks.
>
> -> why no symbols file?
Added symbols file with the help of dpkg-gensymbols. Already in git.
>
> -> d/rules
> you should call bootstrap in override_dh_autoreconf, not in
> override_dh_auto_configure:
>
> override_dh_autoreconf:
> dh_autoreconf ./bootstrap.sh
>
> Then you also won't need to override autoclean.
> (I any prefer a clean file over overriding debhelper targets)
Super thanks for that !
>
> (Also please unset DH_VERBOSE when uploading...)
Yes, deleted now.
>
> "unused substitution variable ${misc:Pre-Depends}"
> Pre-Depend is missing in d/control (multi-arch support...)
>
According to policy 7.2, putting Pre-Depends should be first discussed
on dd@, or am I missing something ?
--
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
signature.asc
Description: Digital signature
Bug#757669: RFS: libstrophe/0.8.6-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "libstrophe" * Package name: libstrophe Version : 0.8.6-1 Upstream Author : Jack Moffit * URL : http://strophe.im/libstrophe/ * License : MIT Section : libdevel It builds those binary packages: libstrophe-dev - Library for writing XMPP clients - development files libstrophe0 - Library for writing XMPP clients - shared library libstrophe is a minimal XMPP library written in C. It has almost no external dependencies, only an XML parsing library (expat or libxml are both supported). It is designed for both POSIX and Windows systems. I worked with libstrophe upstream past months to make it suitable for Debian. I helped them with autotools, so that shared library is built along the static one. Encouraged them to tag relases in github, and together we closed some pull requests. Libstrophe is used by profanity.im, a console XMPP client inspired by IRSSI, which I intend to pack too, this week. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libstrophe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libs/libstrophe/libstrophe_0.8.6-1.dsc Or go directly to the VCS at Alioth git: http://anonscm.debian.org/cgit/collab-maint/libstrophe.git More information about *libstrophe* can be obtained from http://strophe.im/libstrophe/. Changes since the last upload: * Initial release (Closes: #511341) Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810100401.ga25...@blackstar.cs.put.poznan.pl
Re: Problems with ftp and checksums
On 04.08.14 13:52:52, Ansgar Burchardt wrote: > On 08/04/2014 08:15, Dariusz Dwornikowski wrote: > > I tried to upload viewnior to ftp-eu but it seems unoperable. Then I > > tried to upload to master, and have a problem. Since this is -2 point > > release, ftp already knows the orig source tarball but it has > > different size and checksum from .dsc. Probably someday was uploaded > > partially. I cannot delete orig with dcut, what can I do ? > > Is a version of the package in question already in the archive? If yes, > are you sure you are using the same upstream tarball as already present > in the archive? I am trying to upload 1.4-2, some time ago I uploaded 1.4-1. I checked the .dcs for 1.4-1 and the orig has the same size and checksum as in -2 dsc. In -2 I deleted some files (config.sub and so on) from the source in git (I am using gdb). But -2 point release does not upload orig again so this should not be an issue (and the new dsc has the same size and checksum) > > It would also help if you included the actual error messages you got. > I can only provide an error from ftp: === viewnior_1.4-2.dsc: Invalid size hash for viewnior_1.4.orig.tar.gz: According to the control file the size hash should be 566470, but viewnior_1.4.orig.tar.gz has 560284. If you did not include viewnior_1.4.orig.tar.gz in you upload, a different version might already be known to the archive software. === -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140805081733.ga4...@blackstar.cs.put.poznan.pl
Problems with ftp and checksums
Hi, I tried to upload viewnior to ftp-eu but it seems unoperable. Then I tried to upload to master, and have a problem. Since this is -2 point release, ftp already knows the orig source tarball but it has different size and checksum from .dsc. Probably someday was uploaded partially. I cannot delete orig with dcut, what can I do ? -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140804061539.gh27...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
>
> Oh. I read “Forwarded: no” as “it should be forwarded, but it's not been
> done yet”. In this case “Forwarded: not-needed” would be more adequate; or
> even better, use “Origin: upstream”, and then you don't need Forwarded at
> all.
Thank you for that.
>
> >>I didn't get answer to my question about mprotect(2):
> >>>Shouldn't we run this code also on non-Linux architectures? At least
> >>>on kfreebsd-amd64, heap is not executable by default, which is what
> >>>this code is trying to work around.
> >
> >Yes, forgot to clear this. I am not sure I fully undestand. Crashme is
> >built on all archs but this is probably not what you meant.
> >
> >Won't this conditional catch for kfreebsd-amd64 (defined(__FreeBSD__)
> >compiler macro will catch it ?
>
> Nope, __FreeBSD__ is not defined on GNU/kFreeBSD, only on “true” FreeBSD
> systems.
>
> Here's useful piece of documentation about porting to kFreeBSD:
> http://glibc-bsd.alioth.debian.org/porting/PORTING
> (the relvant section is “Add our system name to checks here and there”)
>
> Another problem on kFreeBSD is that I get this warning:
>
> crashme.c:758:17: warning: incompatible implicit declaration of built-in
> function 'execlp' [enabled by default]
> {status = execlp(cmd,cmd,nb,arg2,nt,arg4,arg5,subprocess_ind,NULL);
> ^
It appears that package has been sponsored by Laszlo today, I will
tackle porting problem when preparing 2.8.2 upstream release,
meanwhile I will install kfreebsd vm.
You mentioned earlier that 2.7 should be also uploaded to stable
because of [1]. Could you please tell me, or point out a source of
information, how this should be done ? Should I create a debian-stable
branch and prepare a package release stable there (in changelog it
should be stable instead of unstable). Or should I just use
backporting procedures and upload to backports?
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749816
--
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140601112518.ga15...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
> >>>If my supposition is correct, then this is a grave bug, and after it's > >>>fixed in unstable, it should be also fixed in stable and oldstable. > > I've filed it as #749816. Thanks. > > * Paul Wise , 2014-05-27, 08:43: > >On Tue, May 27, 2014 at 1:07 AM, Dariusz Dwornikowski wrote: > >>I can fix this when I am given DM rights to crashme. > >Nothing about stable/oldstable updates requires DM rights, you can do that > >through your normal sponsors. > > Hear, hear. Just to be clear: I am absolutely not giving anyone DM > permissions after a single upload. :-) > Ack. > > Anyway, let's get back to work: > > Possible typos in the code and in the documentation: > ntrys -> ntries > NTRYS -> NTRIES > > Typo in the changelog: > canonincal -> canonical I fixed this by updating fix-spelling.patch. > > >+Description: tool to test kernel stability > > I think s/to test/for testing/ sounds better. > > >- them. Used to test kernel stability. > >+ them. It is used to test kernel's stability. > > I don't think this use of 's is correct. > As a data point, according to Google, “kernel stability” is 40 times more > popular than “kernel's stability”. > > But I'm not a native speaker of English, so I might be saying nonsense here. > If you want professional advice about your description, please ask at > debian-l10n-english@ldo. I followed here Don'ssuggestion. > > >* Added patch fixing memset transposed arguments > > Good catch. Please don't forget to forward the patch upstream. Laszlo caught this but the patch was backported from 2.8.2 of crashme. So technically upstream forwarded it to me. > > The following changes are not documented: > - Upstream-Contact update in d/copyright; > - d/crashme.install addition; > - dropping d/crashme.lintian-overrides; > - debian/watch update; > - most of changes to d/rules; > - package description updates; > - README.debian update. I documented it. > > It should be s/debian/Debian/, BTW. (Although it's not a big deal, as > debhelper conveniently renames the file for you, so you correct correct name > in the binary package.) Renamed it so debhelper does not have to do it. Let's give it some rest. > > I didn't get answer to my question about mprotect(2): > > >Shouldn't we run this code also on non-Linux architectures? At least on > >kfreebsd-amd64, heap is not executable by default, which is what this code > >is trying to work around. Yes, forgot to clear this. I am not sure I fully undestand. Crashme is built on all archs but this is probably not what you meant. Won't this conditional catch for kfreebsd-amd64 ( defined(__FreeBSD__) compiler macro will catch it ? -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140530113249.ga27...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
On 26.05.14 18:25:25, Jakub Wilk wrote:
> * Dariusz Dwornikowski , 2014-05-26,
> 17:19:
> >>What happened to debian/patch/legacy.patch?
> >As upstream informed me legacy.patch is in 2.7 already, which I try to
> >push into Debian, that is why I have deleted it.
>
> Then this should be documented in the changelog. But at least this part
>
> - {status = execl(cmd,cmd,nb,arg2,nt,arg4,arg5,subprocess_ind,0);
> + {status = execlp(cmd,cmd,nb,arg2,nt,arg4,arg5,subprocess_ind,NULL);
>
> hasn't been merged. And it is really needed; see bug #37304, which your
> version of crashme reintroduces.
I have updated the git, added the changelog entry, and also a patch
fixing this.
> >>
> >>2.7 4-APR-2014 __APPLE__ port, fix linux 64 bit port.
> >>
> >>I wonder how badly broken is the package in the archive (2.4). My
> >>understanding is that it's completely useless on some architectures,
> >>because it doesn't actually stress-test anything; but I might be wrong.
>
> If my supposition is correct, then this is a grave bug, and after it's fixed
> in unstable, it should be also fixed in stable and oldstable.
>
I can fix this when I am given DM rights to crashme.
--
Dariusz Dwornikowski,
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140526170722.gc4...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
On 24.05.14 23:38:38, Jakub Wilk wrote: > * Dariusz Dwornikowski , 2014-05-21, > 13:48: > >>If you listed files to remove in debian/clean, you could avoid the > >>override in debian/rules. > >Yes, fixed that too. Settled for d/rules. > > Well, now I can't build the source package: > > rm -f *.o > rm -f pddet > rm debian/upstream > rm: cannot remove ‘debian/upstream’: No such file or directory > debian/rules:13: recipe for target 'override_dh_auto_clean' failed I forgot to push sorry, now it will build. > > > What happened to debian/patch/legacy.patch? > > Upstream writes: > > 2.7 4-APR-2014 __APPLE__ port, fix linux 64 bit port. > > I wonder how badly broken is the package in the archive (2.4). My > understanding is that it's completely useless on some architectures, because > it doesn't actually stress-test anything; but I might be wrong. > As upstream informed me legacy.patch is in 2.7 already, which I try to push into Debian, that is why I have deleted it. -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140526151901.gf13...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
> > * Copyright changed to DEP-5 > > This is not an accurate description of changes to the copyright file. The > original copyright file was already in the DEP-5 format. Fixed that. > > > * New maintainer (Closes: #739083) > > Did you get any reply from George? Yes, we talked that is why I took over the package. We have been working on crashme (he is upstream) past few weeks. > > > * Hardening added > > That's not an accurate description of the change you did either. (Although > enabled hardening might be a side effect of this change.) > > Why is override_dh_auto_build commented in debian/rules? If this code is not > supposed to be run, then remove it. > > Why do you set CFLAGS in debian/rules? Fixed. Removed. > > > * Spelling patch refreshed > > Please forward the patch upstream. There's more typos that you might want to > fix: > > $ codespell --skip '*.patch' > ./crashme.txt:26: seperate ==> separate > ./crashme.txt:77: enviroment ==> environment > ./crashme.html:147: exersize ==> exercise > ./crashme.html:272: seperate ==> separate Did that and forwarded to codeplex issue tracker. > > > * Bump standards to 3.9.5 > > Did it require any changes to packaging? Nope, fixed. > > > * Created manpage for pddet binary > > I'm sorry to say that, but this manpage is not helpful. I read it twice, and > still have no idea what is this program supposed to do. I found a better piece of text to put there, by upstream too. > > > * d/rules updated to clean cleanly > > If you listed files to remove in debian/clean, you could avoid the override > in debian/rules. Yes, fixed that too. Settled for d/rules. > The package is in VCS: http://anonscm.debian.org/gitweb/?p=collab-maint/crashme.git -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140521114808.gc9...@blackstar.cs.put.poznan.pl
Bug#748831: RFS: crashme/2.7-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "crashme" * Package name: crashme Version : 2.7-1 Upstream Author : George Carrette * URL : http://people.delphiforums.com/gjc/crashme.html * License : crashme Section : devel It builds those binary packages: crashme- Stress tests operating system stability To access further information about this package, please visit the following URL: http://mentors.debian.net/package/crashme Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/crashme/crashme_2.7-1.dsc More information about *crashme* can be obtained from http://people.delphiforums.com/gjc/crashme.html. Changes since the last upload: * Imported Upstream version 2.7 * Copyright changed to DEP-5 * New maintainer (Closes: #739083) * Hardening added * Spelling patch refreshed * VCS fields in canonincal format * Bump standards to 3.9.5 * Created manpage for pddet binary * d/rules updated to clean cleanly Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140521060628.ga...@blackstar.cs.put.poznan.pl
Older release and git-buildpackage
Hi I need some help with a scenario with gbp. Say I have imported a new upstream version but would like to release a -2 to an older release. Is there a simple way to do this ? -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140510135642.ga3...@blackstar.cs.put.poznan.pl
Dual licence + linking openssl
Hi, I know that OpenSSL licence is incompatible with GPL but what when a package linking to openssl is dual licenced under GPL and MIT. Can I just "choose" MIT and say, hey they are compatible ? Is such a package suitable for Debian ? -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507045204.gb12...@blackstar.cs.put.poznan.pl
Bug#746964: RFS: tanglet/1.2.2-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "tanglet" * Package name: tanglet Version : 1.2.2-1 Upstream Author : Graeme Gott * URL : http://gottcode.org/tanglet/ * License : GPL-2+ Section : games It builds those binary packages: tanglet- single player word finding game based on Boggle tanglet-data - single player word finding game based on Boggle - data files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tanglet Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tanglet/tanglet_1.2.2-1.dsc More information about *tanglet* can be obtained from http://gottcode.org/tanglet/. Changes since the last upload: * Imported Upstream version 1.2.2 * Added keywords to desktop file and menu entry (Closes: #738038) * Updated copyright to DEP-5 * Added VCS fields to d/control * Watch file fixed * Migrated to dh * Compat changed to 9, bump standards to 3.9.5 * Updated manpage (Closes: #617539) * New maintainer (Closes: #746458) * Split packages to tanglet-data and tanglet Regards, Dariusz Dwornikowski -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140504112726.ga21...@blackstar.cs.put.poznan.pl
Bug#746763: RFS: connectagram/1.1.2-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "connectagram" * Package name: connectagram Version : 1.1.2-1 Upstream Author : Graeme Gott * URL : http://gottcode.org/connectagram/ * License : GPL-2+ Section : games It builds those binary packages: connectagram - word unscrambling game connectagram-data - word unscrambling game - data files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/connectagram Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/connectagram/connectagram_1.1.2-1.dsc More information about connectagram can be obtained from http://gottcode.org/connectagram/. Changes since the last upload: * Imported Upstream version 1.1.2 * Bump standards to 3.9.5 and compat to 9 * New maintainer (Closes: #746459) * Split packages to connectagram and connectagram-data, containing word list files * Removed unneeded patch * Migrated to dh * debian/copyright formatted according to DEP-5 * Fixed watch file Regards, Dariusz Dwornikowski -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140503112829.ga24...@blackstar.cs.put.poznan.pl
Bug#745777: RFS: ipad-charge/0~20131118.c82b032-1 [ITP] -- USB charging control utility to charge an Apple device
Hi Benny, I am not a DD, I cannot sponsor your package but here are some comments: Since it is your initial upload, the version should be -1, you bump the number only when you *release* a new package. Merge all the changes into 1.1-1 release. Other things to fix: - set homepage field in d/control to github project page - standards should be 3.9.5 - make the package depend on debhelper >= 9 in d/control - when upstream releases on github, you can prepere a watch file, something like that should be sufficient: version=3 https://github.com/mkorenkov/ipad_charge/releases .*/archive/v(\d[\d\.]+)\.tar\.gz - in d/copyright you did not add years to Files: * - patches are not described according to DEP-3 [1] - what about udev rules ? are they installed ? - did you check your package with pbuilder and/or piuparts ? We can review the package once more, when you fix. [1] http://dep.debian.net/deps/dep3/ -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140429064420.ga2...@blackstar.cs.put.poznan.pl
Re: Library packaging and missing .a file
>On 24.04.14 10:23:23, Christian Kastner wrote: > > It is sufficient to change these to eg: > >usr/lib/*/lib*.a Thanks for this. I have got another problem. Libstrophe only provides .a file, no .so, so basically it should provide only a -dev package. Is it ok to package only -dev, or is it agains policies? -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140425055829.gb28...@blackstar.cs.put.poznan.pl
Re: No upstream versioning
On 24.04.14 20:12:12, Benjamin Donald-Wilson wrote: > Hello, > > I'm wishing to package ipad-charge[0] for Debian.[1] The only problem I > appear to be having is that the upstream don't version their uploads. I've > emailed the developer a few days ago but haven't received a response so far. > I'm wondering what I should version it as if I do not receive a reply from > the upstream developer? Create an issue on github to tag his releases. > > Thanks, > Ben Donald-WIlson > > [0]: https://github.com/mkorenkov/ipad_charge > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743798 -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424104509.ga25...@blackstar.cs.put.poznan.pl
Library packaging and missing .a file
Hi, I am packaging libstrophe XMPP library in order to introduce www.profanity.im to Debian. make[2]: Entering directory `/home/tdi/dev/libstrophe-0.8.4' /bin/mkdir -p '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu' /usr/bin/install -c -m 644 libstrophe.a '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu' ( cd '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/lib/x86_64-linux-gnu' && ranlib libstrophe.a ) /bin/mkdir -p '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/include' /usr/bin/install -c -m 644 strophe.h '/home/tdi/dev/libstrophe-0.8.4/debian/tmp/usr/include' make[2]: Leaving directory `/home/tdi/dev/libstrophe-0.8.4' make[1]: Leaving directory `/home/tdi/dev/libstrophe-0.8.4' dh_install dh_install: libstrophe-dev missing files (usr/lib/lib*.a), aborting The libstrophe.a file is installed into /usr/lib/x86_64-linux-gnu, instead of /usr/lib. When should the .a file be installed into /usr/lib and when into x86... ? My .install file looks like this, however dh_auto_install still installs files into x86... because it runs before dh_install. Should I override dh_auto_install and depend only on d/install file ? usr/include/* usr/lib/lib*.a usr/lib/lib*.so usr/lib/pkgconfig/* usr/share/pkgconfig/* -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140424061634.ga28...@blackstar.cs.put.poznan.pl
Bug#741287: RFS: zmap/1.2.0-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zmap". As always checked with cowbuilder and puiparts. Vincent, Clint please sponsor if you can. * Package name: zmap Version : 1.2.0-1 Upstream Author : Zakir Durumeric , J. Alex Halderman , Eric Wustrow , David Adrian , HD Moore * URL : https://zmap.io/ * License : Apache 2.0 Section : net It builds those binary packages: zmap - network scanner for researchers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/zmap Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/z/zmap/zmap_1.2.0-1.dsc More information about *zmap* can be obtained from http://zmap.io/ Changes since the last upload: * Imported Upstream version 1.2.0 Regards, Dariusz Dwornikowski -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#741249: RFS: maradns/2.0.09-2 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "maradns". As always I checked with cowbuilder and piuparts. * Package name: maradns Version : 2.0.09-2 Upstream Author : Sam Trenholme * URL : http://maradns.samiam.org/ * License : BSD Section : net It builds those binary packages: duende - logging daemonizer maradns- simple security-focused authoritative Domain Name Service server maradns-deadwood - simple security-focused recursive Domain Name Service server maradns-docs - upstream documentation for the MaraDNS Domain Name Service server maradns-zoneserver - complementary server process to TCP functions for MaraDNS To access further information about this package, please visit the following URL: http://mentors.debian.net/package/maradns Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/maradns/maradns_2.0.09-2.dsc More information about *maradns* can be obtained from http://maradns.samiam.org/ Changes since the last upload: * updated watchfile to check pgp signature (Closes: #740046) * patches updates, thanks to Tobias Frost - simplified the deadwood_makefile.patch (Closes: #740049) - added patch to generate DwRandPrime.h from PRNG when /dev/urandom missing * pgp singnature saved as d/upstream-singning-key.pgp * fixed postinst not to violate policy 10.7.3 (Closes: #740332) - added preinst for reverting to upstream's mararc - added stopping old maradns where init script is wrong * patch added to update mararc manpage Regards, Dariusz Dwornikowski -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Weird conffile case
On 04.03.14 08:58:58, Dominique Dumont wrote: > On Monday 03 March 2014 17:56:38 Dariusz Dwornikowski wrote: > > The part "undo damage" I do not understand. From what I understand > > dpkg compares the new config with the existing one. So to upgrade from > > stable properly I would have to replace my new config with the > > identical to the existing one, i.e. preprocess it in postinst, just as > > the stable package preprocesses it. > > Yes, the idea is to restore the original values of maradns_uid and > maradns_gid. But do no more, otherwise you may alter modifications done by > user. > > This needs to be done *with* Russ's suggestions regarding patching maradns. > > > But then I violate 10.7.3 again. > > Is that right? > > I believe it's ok if you restore only maradns_uid and maradns_gid and leave > all other modifications alone. > > More seasoned DDs will correct me if I'm wrong. > Ok so I have been sitting in this for past few hours. It appears that I cannot undo the damege in posting because it is called after dpkg compares configs. So I migrated checking to preinst, where I check if the upgraded version in 1.4.X and reverse the damage. However this breaks the upgrade in postinst, in which debhelper injects code to start/stop maradns. It cannot stop previous maradns because the config in different (different user and group). Is it ok to manually kill process in preinst in such situation ? -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#740934: RFS: zmap/1.1.2-2
On 06.03.14 09:46:46, Vincent Cheng wrote: > On Thu, Mar 6, 2014 at 4:06 AM, Dariusz Dwornikowski > wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "zmap" > > > > * Package name: zmap > >Version : 1.1.2-2 > >Upstream Author : Zakir Durumeric , J. Alex Halderman > > , Eric Wustrow , David Adrian > > , HD Moore > > * URL : https://zmap.io/ > > * License : Apache 2.0 > >Section : net > > > > It builds those binary packages: > > > > zmap - network scanner for researchers > > > > To access further information about this package, please visit the > > following URL: > > > > http://mentors.debian.net/package/zmap > > > > Alternatively, one can download the package with dget using this command: > > > > dget -x > > http://mentors.debian.net/debian/pool/main/z/zmap/zmap_1.1.2-2.dsc > > > > More information about *zmap* can be obtained from http://zmap.io/ > > > > Changes since the last upload: > > > > * Added json support > > * Added patch to fix spelling error in redis.c > > * Added redis support > > Build-depends: s/libjson0-dev/libjson-c-dev/ since the former is just > an empty transitional package. Please also consider running > 'wrap-and-sort -s' (from devscripts) to make it easier to review > changes to your build-deps (or other metadata in d/control). I think this is another way round. apt-cache show libjson-c-dev says: " This is a transition package that can be safely removed once no package depend on it." The package does not build with libjson-c-dev. I always check with cowbuilder and piuparts. > > Also, if you're going to cc me, please cc my @debian.org email instead > of my old gmail account. :) Sorry, I used email shown on my QA page. You signed my last zmap upload with gmail account. > > Regards, > Vincent -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#740934: RFS: zmap/1.1.2-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zmap" * Package name: zmap Version : 1.1.2-2 Upstream Author : Zakir Durumeric , J. Alex Halderman , Eric Wustrow , David Adrian , HD Moore * URL : https://zmap.io/ * License : Apache 2.0 Section : net It builds those binary packages: zmap - network scanner for researchers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/zmap Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/z/zmap/zmap_1.1.2-2.dsc More information about *zmap* can be obtained from http://zmap.io/ Changes since the last upload: * Added json support * Added patch to fix spelling error in redis.c * Added redis support -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Compiling features to a package
Dear Mentors, So I maintain zmap package. It can be compiled with json and redis support. What is the policy to handle this ? Should I compile all possible (reasonable) extensions to a package? Should I create a second binary package, say: zmap-redis with redis support compiled in ? For now I think that it is reasonable to create zmap with json support, and a second one zmap-redis with redis support. -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Weird conffile case
On 3 March 2014 16:41, Dominique Dumont wrote: > On Monday 03 March 2014 16:23:28 Dariusz Dwornikowski wrote: >> I agree this is a nice solution with a patch, I will integrate it for sure. >> However what should be done in such situation with bug 740332 ? >> Should I close it with the new release? > > ok, I did not realize that the upgrade test is done from maradns 1.4.12-5 > (from stable). > > In #740332, Andreas suggests to undo the damage done in maradns_1.4.12-5 > postinst script. I guess that this may be done in new maradns preinst. > > But your preinst will have to handle differently an upgrade starting from > stable (undo damage) and upgrade from testing (may not need to undo damage). > The part "undo damage" I do not understand. From what I understand dpkg compares the new config with the existing one. So to upgrade from stable properly I would have to replace my new config with the identical to the existing one, i.e. preprocess it in postinst, just as the stable package preprocesses it. But then I violate 10.7.3 again. Is that right? PS: Mind that this violation (#740332) only occurs when upgrading package that was not touched by the user at all. > Hope this helps > Yes thank you. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cagnkune3uk9+kb7-81yhuh168nt7sh0eknru49hr2bugaz8...@mail.gmail.com
Re: Weird conffile case
On 3 March 2014 13:51, Dominique Dumont wrote: > On Monday 03 March 2014 08:59:01 Dariusz Dwornikowski wrote: >> It is upstream's choice. But I will include such a patch, it is quite >> trivial. But this is not the case here. >> The problem is that installing the package asks for users' decision >> (keep config, replace with maintainer, etc). >> Applying the patch won't, unfortunately, solve my problem here. Thank >> you for the suggestion anyway. > > It won't solve the problem for the *next* release. But the problem should be > solved after. So I guess that's a fair solution (even if not ideal). I agree this is a nice solution with a patch, I will integrate it for sure. However what should be done in such situation with bug 740332 ? Should I close it with the new release? > > If you really want to solve this problem for next release, you will have to: > * stop delivering mararc in /etc/maradns/ (i.e. no more conffile problem) > * manage mararc file in postinst, i.e. update mararc on package upgrade and > create a fresh marac on new installation. > > The last point is not easy to get right. > > For what it's worth, I'm trying to handle lcdproc configuration this way > (while providing automatic configuration upgrade). [1] > > That said, Russ's proposal is probably the most simple. > > HTH > > [1] https://wiki.debian.org/PackageConfigUpgrade > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cagnkunfp8pu-y3zqpv9fgdadmthtz7uunfaq74opc6_e_79...@mail.gmail.com
Re: Weird conffile case
On 2 March 2014 21:45, Russ Allbery wrote: > Dariusz Dwornikowski writes: > >> The previous maintainer of maradns modified conffiles in postinst >> (dynamically checked for the maradns user id and filled >> /etc/maradns/mararc with this info). This obviously rendered RC bug of >> violation of policy 10.7.3 [2]. I closed the bug in a new release by not >> modifying the config and leaving the user to do it, informing her/him >> with a appropriate message with a user id to fill in. > > Does maradns require that the user ID be specified as a UID? Why doesn't > it support specifying the ID as a name (which it would then turn into a > UID via getpwnam)? Then you wouldn't have to modify the configuration > file. > > If it doesn't support names now, could that be added? It might be a > fairly simple patch, a few lines at most. > It is upstream's choice. But I will include such a patch, it is quite trivial. But this is not the case here. The problem is that installing the package asks for users' decision (keep config, replace with maintainer, etc). Applying the patch won't, unfortunately, solve my problem here. Thank you for the suggestion anyway. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cagnkunewgx5d919revgvxmg1zrwtzvmyolrkax5mkdr4tdc...@mail.gmail.com
Weird conffile case
hi, I would like to request some advice on a case I need to resolve with maradns package [1]. The previous maintainer of maradns modified conffiles in postinst (dynamically checked for the maradns user id and filled /etc/maradns/mararc with this info). This obviously rendered RC bug of violation of policy 10.7.3 [2]. I closed the bug in a new release by not modifying the config and leaving the user to do it, informing her/him with a appropriate message with a user id to fill in. Then I get another violation of 10.7.3 [3][4] because now when package is uprgraded with a not modified config, Debian thinks that conffile is *modified* because the one that user has was in fact generated in postinst before. So dpkg prompts for a user action how to handle config file replacement... I am a little bit stuck here. I can see that I have to treat /etc/maradns/mararc as conffile because it resides in /etc/. If I go back to modifying the conffile to be compatible with the previous one, I will be again violating 10.7.3. I am quite stuck here, and I request some advice how to tackle the problem. [1] http://packages.qa.debian.org/m/maradns.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=710903 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740332 [4] https://www.debian.org/doc/debian-policy/ch-files.html#s10.7.3 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAGnkuncYBo01zxU7Hw1KfF70g=uh0o6rg6lbf-u2qrqfxau...@mail.gmail.com
Re: gengetopt - Is this a +dfsg case?
On 22 February 2014 12:42, Bart Martens wrote: > On Sat, Feb 22, 2014 at 11:58:39AM +0100, Dariusz Dwornikowski wrote: >> Hi, >> >> I am maintaining a great package - zmap. It depends, for building >> only, on gengetopt [1] to generate main.c stub for command line >> arguments handling. However gengetopt was removed from testing due to >> [2], it is only in unstable for now. This blocks new zmap versions >> going to testing. I already contacted the maintainer some time ago >> asking whether it would be fixed or he needs some help but he has not >> responded yet. >> [1] http://packages.qa.debian.org/g/gengetopt.html >> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708880 >> >> My question is, how this situation should be handled, should these >> manuals be removed and package uploaded as dfsg ? > > I suggest to add a well-tested patch to the bug, and tag the bug "patch". Sorry, quite new to this. Patch what ? A source package, an orig tarball ? Along with the debian/ directory ? Should the patch remove the files and change the changelog to add dfsg tag ? > >> Or the best is to wait for upstream to change the licence. > > Waiting is usually not the best approach. Heh ok. > >> >> I am asking out of curiosity, and to know how to handle such >> situations in the future, I do not want hijack the package from >> Alessio. > > How to handle such situations in the future depends on the situations. :-) In > this case I suggest ... see above. > > Regards, > > Bart Martens -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGnkundPLgMUyyim=9=ubwqdxqtbsjfc_3440kye2__rlrd...@mail.gmail.com
Re: Working with gbp and older releases
On sob, lut 22, 2014 at 11:02:12 +0100, Tobias Frost wrote:
> Am Mittwoch, den 19.02.2014, 20:00 +0100 schrieb Dariusz Dwornikowski
> > I uploaded my version to mentors. Would you be so nice to review it ?
> > http://mentors.debian.net/package/maradns
>
> Hi Dariusz,
>
> Sure, I'll take a look. (I'm not a DD, so I cannot sponsor.)
>
> A suggestion: You should the RFS Bug to get a broader audience, maybe
> someone who can indeed sponsor.
Yes, I thought it would be better to share first with you, since you
seemed interesed.
> Ok, lets jump into the package: (Note that I do not sort the items, I
> just write as I see them; so no ordering, severity, ... implied. And
> don't get shocked by the length of the remarks, thats normal for the
> first shot.)
>
> -> Please file a bug for your changelog entry "Several security bugs" to
> document in the BTS that the current version in xxx has problems.
> (One bug is enough, just quote your 5-lines in the changelog as bug
> report)
Did that, thank you.
>
> -> For the old changelogs, where you added for example
>
> [ Dariusz Dwornikowski ]
> * Security bugfix for CVE-2012-1570
>
> This is somehow misleading as it implies that you actively did smth on
> the pckageing, but leave it unclear "what has been done". I think you
> should not add your name here and hadd the "CVE-" to the (existing)
> changelog entry. In this special case I would just update the first line
> to
I was not sure about it either. Now I know that [] indicate job done,
not the author of particular changelog entry.
>
> maradns (2.0.06-1) experimental; urgency=low
>
> * New upstream release, fixes CVE-2012-1570
>
> (And then document the change in d/changelog for the to-be-uploaded
> version, for example
>
> * Updated old d/changelog entries: Added information when the CVEs
> where fixed: (adding Debian-Versions which where changed=
>
Done. Thank you.
> If you bump the SV, you should not if there have been any changes
> necessary and if not document that too.
>
> Generally, d/changelog entries should reflect *what* have been changed
> on not focus on the *why* something has changed. For example, you write
> "We no longer modify the config (Closes: #710903)":
> I would write "updated d/postinst to no longer modifiy conffiles.
> (Closes: #...)
> (and in the patch for it, do not just comment out the lines, remove them
> to be clear that this is not acciedentially commented out)
Done. Thank you.
>
> -> Regarding the usage of your repository. I would suggest to have "one
> change - one commit" and also have the commit messages speak for the
> changes (ideally, they are identical to the d/changelog entry); There
> were at least some commit which changed more than the git log says.
> (the commit for the conffile fix is a examples - it also changes
> d/control but does not mention it)
Seems reasonable. I will stick to this from now on.
> (BTW, in this commit you change the dependency of duende to an *older*
> version? As this looks weird, I *suppose* this is wrong... Maybe you
> wanted to enforce the current version, then use ${binary:Version})
Fixed that. Thank you.
>
> I see also that there are sometimes undocumented changes, please
> document them. For example you updated the watchfile, add gpg signatures
> but this is not documented in the d/changelog. But this is just an
> example, there are more than this one.
I got rid of that because it did not work.
>
> d/control:
> Why is the Breaks / Replaces necessary for maradns-zoneserver and other
> packages? Why does the docs breaks an older version of maradns?
This
Breaks/Replaces was some technique of the old maintainer. I removed it
and it works fine without it. I think it was because of him updating
conffiles in d/postinst, which got the package to violate the policy.
>
> In Debian there is a file DwRandPrime.h which seems somehow
> autogenerated. What is its purpose?
This is a weirdo. While building maradns generated a random prime
number and writes it to DwRandPrime.h, I keep the upstream original in
the debian repository to avoid "upstream changed" problems. After
every build the DwRandPrime.h would be changed and gbp and debuild
would complain. This assures reproductible builds.
>
>
> ((note, I had to stop the review here due to time constraints)
Thank you. It helped a lot.
>
>
> Best regards,
> Tobias
>
--
Pozdrawiam,
Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań
University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20140222112113.ga26...@blackstar.cs.put.poznan.pl
gengetopt - Is this a +dfsg case?
Hi, I am maintaining a great package - zmap. It depends, for building only, on gengetopt [1] to generate main.c stub for command line arguments handling. However gengetopt was removed from testing due to [2], it is only in unstable for now. This blocks new zmap versions going to testing. I already contacted the maintainer some time ago asking whether it would be fixed or he needs some help but he has not responded yet. My question is, how this situation should be handled, should these manuals be removed and package uploaded as dfsg ? Or the best is to wait for upstream to change the licence. I am asking out of curiosity, and to know how to handle such situations in the future, I do not want hijack the package from Alessio. [1] http://packages.qa.debian.org/g/gengetopt.html [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708880 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagnkund+q2swd_dxq_1prqz9y-ewstgyc2yr2qqah8xttrr...@mail.gmail.com
Re: Is there a place for ndjbdns in Debian
On 20 February 2014 19:48, Andreas Metzler wrote: > Dariusz Dwornikowski wrote: >> I am working on a MaraDNS package, the upstream Author, Sam Trenholme >> suggested that maybe it could also worth packaging ndjbdns, a djbdns >> fork but with GPL licence and all bugs fixed. Also the upstream of >> ndjbdns is quite responsive and active. > [...] > > Hello, > > from a users point of view I would love to see a tiny performing DNS > cache in Debian which is maintained upstream. However judging from the > respective descriptions on the web I guess that deadwood should work > as well as a djbdns fork. > > OTOH I wonder what would keep you as maintainer interested in taking > care of two different packages doing basically the same job. You will > soon find out that you like one better and will only use this one. You > might then have a hard time motivating yourself to invest time in the > other one. > Thank you. I think ill just stick to maintaining maraDNS then. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagnkunf0xen1swlddttpeu2v_dvb81cvx99o1xc1cr3t-b6...@mail.gmail.com
Re: Is there a place for ndjbdns in Debian
On Thu, Feb 20, 2014 at 06:56:40PM +0100, Dariusz Dwornikowski wrote: > Dear Mentors, > > I am working on a MaraDNS package, the upstream Author, Sam Trenholme > suggested that maybe it could also worth packaging ndjbdns, a djbdns > fork but with GPL licence and all bugs fixed. Also the upstream of > ndjbdns is quite responsive and active. > > The status of djbdns in Debian is that it is has many bugs [1]. I guess I > could ask the djbdns maintainer what he thinks, hence CC to Gerrit > Pape. > > My question is, would you think there would be a place for djbdns fork > in Debian, given the cirumstances? > > > [1] http://packages.qa.debian.org/d/djbdns.html Sorry for replying to my own email, I forgot to give you the url for the ndjbdns : http://pjp.dgplug.org/ndjbdns/index.html. -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Is there a place for ndjbdns in Debian
Dear Mentors, I am working on a MaraDNS package, the upstream Author, Sam Trenholme suggested that maybe it could also worth packaging ndjbdns, a djbdns fork but with GPL licence and all bugs fixed. Also the upstream of ndjbdns is quite responsive and active. The status of djbdns in Debian is that it is has many bugs [1]. I guess I could ask the djbdns maintainer what he thinks, hence CC to Gerrit Pape. My question is, would you think there would be a place for djbdns fork in Debian, given the cirumstances? [1] http://packages.qa.debian.org/d/djbdns.html -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Working with gbp and older releases
On wto, lut 18, 2014 at 02:08:09 -0800, Russ Allbery wrote: > Dariusz Dwornikowski writes: > > On wto, lut 18, 2014 at 01:29:06 -0800, Russ Allbery wrote: > > >> I think you were also saying this, but just to be very clear: please > >> also include the CVE numbers directly in debian/changelog in the entry > >> for whatever release they were fixed in, not just in the bug text. The > >> security team's tracking of open security vulnerabilities relies on > >> being able to analyze the debian/changelog file to determine when CVEs > >> were closed in the Debian packaging. > > > Do I need to take experimental under consideration, i.e. modify > > changelog for experimental releases ? > > I don't believe it's particularly important whether CVEs show up as fixed > in the experimental version in which they were actually fixed or in the > first unstable version in which the fix appears. The former is more > pedantically correct, but I believe the security team primarily cares > about having a complete picture of open security bugs in unstable, > testing, and stable releases. Experimental doesn't receive the same type > of security support and is therefore less important for tracking purposes. > > -- hi, I uploaded my version to mentors. Would you be so nice to review it ? http://mentors.debian.net/package/maradns -- Pozdrawiam, Dariusz Dwornikowski, Assistant at Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219190041.gb19...@blackstar.cs.put.poznan.pl
Bug#739522: RFS: zmap/1.1.2-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "zmap". * Package name: zmap Version : 1.1.2-1 Upstream Author : Zakir Durumeric , J. Alex Halderman , Eric Wustrow , David Adrian , HD Moore * URL : https://zmap.io/ * License : Apache 2.0 Section : net It builds those binary packages: zmap - network scanner for researchers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/zmap Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/z/zmap/zmap_1.1.2-1.dsc More information about *zmap* can be obtained from https://zmap.io/. Changes since the last upload: * New maintainer (Closes: #738468) * Added watch file * debian/copyright added new maintainer * debian/control - spelling fix - fixed Vcs fields to be canonical * debian/patches/02-fix-hyphenation-in-man - fixes hyphen-used-as-minus-sign in zmap.1 * New upstream version -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140219164312.ga14...@blackstar.cs.put.poznan.pl
Re: Working with gbp and older releases
On wto, lut 18, 2014 at 01:29:06 -0800, Russ Allbery wrote: > Tobias Frost writes: > > > Never had a CVE myself, but I think this is the way to go: > > technically you don't need a debian bug, you could just write (random > > example here [1]) > > > maradns (version-1) unstable; urgency=high > > > * new upstream release > > - fixes CVE--, CVE-- ... > > > but I would file one "cover" bugs smth like "Serveral security bugs" and > > listing alls CVE's in the bug's text and just add a Closes: # to the new > > upstream release line. > > I think you were also saying this, but just to be very clear: please also > include the CVE numbers directly in debian/changelog in the entry for > whatever release they were fixed in, not just in the bug text. The > security team's tracking of open security vulnerabilities relies on being > able to analyze the debian/changelog file to determine when CVEs were > closed in the Debian packaging. Do I need to take experimental under consideration, i.e. modify changelog for experimental releases ? > > > For the CVE's already fixed by a older version than 1.4.12, it is > > allowed to modify the old changelog entries, when the fix was actually > > added. > > Yup. I am currently working on a package, testing it etc. I will upload to mentors for a review tomorrow. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218215249.ga32...@blackstar.cs.put.poznan.pl
Re: Working with gbp and older releases
> > > > ACK. (Reading the upstreams' homepage, you should definitly go for the > > latest version. The latest upstream fixes a local DoS. > > As a side, please add all CVE-# which closes the new version into the > > changelog, please follow the procedure as in [1])) > > Thank you, I will do it. Ok the last time I responded I lied that I understood :). I just want to confirm, when I release I will close CVE bugs I found here [1] ? Correct ? But they do not have a corresponding bugs.d.o bug, so I just do: Closes CVE-foo-bar in a changelog, as written in your link ? > > > > > You should also to file a bug against maradns to document that the > > current version has secuirty problemss with the CVE's > > http://maradns.samiam.org/security.html has the list. > > Ok. I can see that they are documented there. Or I miss something. Number 19 is the CVE-None that is fixed in the most current version. Or again I did not understand. [1] https://security-tracker.debian.org/tracker/source-package/maradns -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218201218.gb19...@blackstar.cs.put.poznan.pl
Re: Working with gbp and older releases
On wto, lut 18, 2014 at 07:46:53 +0100, Tobias Frost wrote: > Hallo Darius, > > Am Montag, den 17.02.2014, 20:52 +0100 schrieb Dariusz Dwornikowski: > > > > I am trying to work on an orphaned package maradns. It uses quite a > > > > lot of patches managed with quilt. I created a repo on alioth [1] to > > > > manage different versions. I imported all the versions (debsnap and > > > > git-import-dscs). Now I am stuck with two problems: > > > > > > Thanks for adopting and your contribution to Debian! > > > > Frankly I am still thinking about adopting. It is a great software, I > > use it quite often but while adopting I came to a few disturbing facts. > > > > The first is the fact that upstream stated on [1] as follows: > > > > "It would require some large company or government agency paying me a > > full-time living wage to add significant new features to MaraDNS. > > Since this is unlikely to happen, especially in today's economy, I am > > declaring MaraDNS finished: While I will still fix important security > > bugs in MaraDNS, and will probably still fix other critical bugs, I > > currently have no plans to add new features to MaraDNS." > > > > Additionally, his mail signature gives makes me doubt that his > > commitment to his open source project is full, as in [2]. > > > > "Note: I do not answer MaraDNS (including Deadwood) support requests > > sent by private email without being compensated for my time. A MaraDNS > > support request is any and all discussion you may wish to have about > > MaraDNS in private email; if you want to email me to talk about > > MaraDNS then, yes, that is a support request. I will discuss rates if > > you want this kind of support. Thank you for your understanding." > > > > Also I can see that the package has plenty of patches that could be > > forwarded to the upstream but for some reason were not forwarded or > > accepted. I will try to contact the former mainatainer and upstream to > > be 100% clear on that. > > > > I have little experience what should be done in such a case, maybe I > > have too high expectations on upstream. > > Well, IMHO it's legitimate for upstream to call a program "feature > complete" and mature. I think also it is not against the sprit of open > source to only add features if being paid, its basically a business > model decision one has to make (and not everyone does coding just as a > hobby). One still have all freedoms opens source gives you, also to fork > if desired. Ok. > > Of course, declaring a software "mature" marks a distinct point in the > life cycle of the software toward its end, and eventually it might be > wise at some point in the future to depreciate the package and call for > its removal. But at a popcorn of around 100, and with the statement that > upstream does at least care so much to handle security issues, I think > this is needs not to be now, especially if the package is actively > maintained (soon). and sd upstream just released a new version, their > statement to fix security updates seems not to be empty. I think that maybe when we upgrade to latest branch, more people will use it. Maybe that is the reason for a low popcon value. > > If the patches are not Debian-specific, I would not hesitate to forward > them to upstream and leave it up to upstream to include them or not, > even despite the statement. Some upstreams will be happy to include, > from others you won't even hear any feedback... But at least you should > try. I have already contacted upstream, he is willing to accept patches that have "spelling fix" character. Any other patch he puts in a "patches/3rd-party" directory, so he did with our Debian patches. > > > > > > > > 1. Should I keep the source unpatched in git or patched. If I keep it > > > > unpatched, after patching (dquilt push -a) gbp complains that I have > > > > uncommited changes. What should be done here? > > > > > > The patches should not be applied. > > > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.PATCH > > > should give you hints. > > > > Thank you. > > > > > > > 2. I can see the newest maradns 2.X branch was installed only for > > > > experimental. The latest in unstable/testing was 1.4.12-5. It is now > > > > unusable, due to [2] and procpidfile change. I think the first release > > > > I would make is fixing this, so people can use it again (now it does > > >
Re: Working with gbp and older releases
> > I am trying to work on an orphaned package maradns. It uses quite a > > lot of patches managed with quilt. I created a repo on alioth [1] to > > manage different versions. I imported all the versions (debsnap and > > git-import-dscs). Now I am stuck with two problems: > > Thanks for adopting and your contribution to Debian! Frankly I am still thinking about adopting. It is a great software, I use it quite often but while adopting I came to a few disturbing facts. The first is the fact that upstream stated on [1] as follows: "It would require some large company or government agency paying me a full-time living wage to add significant new features to MaraDNS. Since this is unlikely to happen, especially in today's economy, I am declaring MaraDNS finished: While I will still fix important security bugs in MaraDNS, and will probably still fix other critical bugs, I currently have no plans to add new features to MaraDNS." Additionally, his mail signature gives makes me doubt that his commitment to his open source project is full, as in [2]. "Note: I do not answer MaraDNS (including Deadwood) support requests sent by private email without being compensated for my time. A MaraDNS support request is any and all discussion you may wish to have about MaraDNS in private email; if you want to email me to talk about MaraDNS then, yes, that is a support request. I will discuss rates if you want this kind of support. Thank you for your understanding." Also I can see that the package has plenty of patches that could be forwarded to the upstream but for some reason were not forwarded or accepted. I will try to contact the former mainatainer and upstream to be 100% clear on that. I have little experience what should be done in such a case, maybe I have too high expectations on upstream. > > > 1. Should I keep the source unpatched in git or patched. If I keep it > > unpatched, after patching (dquilt push -a) gbp complains that I have > > uncommited changes. What should be done here? > > The patches should not be applied. > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.PATCH > should give you hints. Thank you. > > > 2. I can see the newest maradns 2.X branch was installed only for > > experimental. The latest in unstable/testing was 1.4.12-5. It is now > > unusable, due to [2] and procpidfile change. I think the first release > > I would make is fixing this, so people can use it again (now it does > > not start). Is this git workflow correct ? > > If you want to adopt you're free to do so. But you can also start with > the new upstream version if you think it is ready for primetime. > I think I will start. The former maintainer had builds of the new branch in experimental, I already prepared a package with the newest upstream version. > > > I will checkout debian/1.4.15-5 tag, bump the changelog to 1.4.15-6, > > make changes in d/* and release with a new tag. Now, say I want to > > release the new 2.X version. I go back to master, add the changelog > > entry for 1.4.15-6 and work on the new release? > > Otherwise please explain your intentions... > For now, let's forget about it. Releasing the newest upstream is the proper solution as you said. > > PS: You should change bug's title #739084 to ITA: and set yourself as > owner of it I sent the email changing O to ITA, it has not been yet processed I think. > > > > > > > [1] http://anonscm.debian.org/gitweb/?p=collab-maint/maradns.git > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709826 > > [1] https://github.com/samboy/MaraDNS#maradns-future [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573970#10 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140217195248.ga11...@blackstar.cs.put.poznan.pl
Working with gbp and older releases
Hi, I am trying to work on an orphaned package maradns. It uses quite a lot of patches managed with quilt. I created a repo on alioth [1] to manage different versions. I imported all the versions (debsnap and git-import-dscs). Now I am stuck with two problems: 1. Should I keep the source unpatched in git or patched. If I keep it unpatched, after patching (dquilt push -a) gbp complains that I have uncommited changes. What should be done here? 2. I can see the newest maradns 2.X branch was installed only for experimental. The latest in unstable/testing was 1.4.12-5. It is now unusable, due to [2] and procpidfile change. I think the first release I would make is fixing this, so people can use it again (now it does not start). Is this git workflow correct ? I will checkout debian/1.4.15-5 tag, bump the changelog to 1.4.15-6, make changes in d/* and release with a new tag. Now, say I want to release the new 2.X version. I go back to master, add the changelog entry for 1.4.15-6 and work on the new release? [1] http://anonscm.debian.org/gitweb/?p=collab-maint/maradns.git [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709826 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagnkuneexbsh+yftex2g_t9dxjv5wsfbx7ggyb4ntvo_8sj...@mail.gmail.com
Re: Do not want recieve mails from bugs.debian .
On 15 February 2014 13:43, Roelof Wobben wrote: > Hello, > > How can I take care that I do not recieve mails from bugs.debian. > > Roelof > This is your package, so you should orphan it officially. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cagnkundbs-dkpcvpplduapfpyd8z7-3oodeqfymfrzhknhv...@mail.gmail.com
Re: RFS: read-edid/3.0.1-2
Thank You. This is what I came up with: override_dh_auto_configure: ifeq ($(DEB_HOST_ARCH_OS), $(filter $(DEB_HOST_ARCH_OS), linux)) ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH), amd64 i386 x32)) # amd64, i386, x32 and linux dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES else # not amd64, i386, x32 but linux dh_auto_configure -- -DCLASSICBUILD=NO -DI2CBUILD=YES endif else #not linux: kfree, hurd ... ifeq ($(DEB_HOST_ARCH_CPU), $(filter $(DEB_HOST_ARCH_CPU), amd64 i386)) #kfree-amd64, kfree-i386, hurd-i386, 3 dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES endif endif Just out of curiousity, is there a place where I can see what dpkg-architecture returns for every architecture?t 2 On 14 February 2014 17:35, Sven Joachim wrote: > On 2014-02-14 13:52 +0100, Dariusz Dwornikowski wrote: > > > After some inquiry, I can see that it can build only on amd64, i386, > > kfreebsd-i386, kfreebsd-amd64 and hud-i386, because the lib it depends on > > (libx86) is only present there. On other architectures I could build only > > one of the binaries -- parse-edid, because it does not depend on anything > > else. > > I meant that you could build read-edid on other Linux architectures as > well (with I2C only). > > > So my new idea is: > > > > on amd64, i386 I build both binaries CLASSIC and I2C > > Probably on x32 as well, although this failed with 3.0.1-1 for some > unknown reason (there is no build log :-(). > > > on kfreebsd-i386, kfreebsd-amd64 and hurd-i386 I build both binaries > CLASSIC > > So, as a summary you want to build CLASSIC if DEB_HOST_ARCH_CPU is amd64 > or i386. > > > on the rest I build only parse-edid (only get-edid uses build options). > > I'd say you should try to build read-edid with I2C if > DEB_HOST_ARCH_OS=linux. > > Cheers, >Sven > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: RFS: read-edid/3.0.1-2
After some inquiry, I can see that it can build only on amd64, i386, kfreebsd-i386, kfreebsd-amd64 and hud-i386, because the lib it depends on (libx86) is only present there. On other architectures I could build only one of the binaries -- parse-edid, because it does not depend on anything else. So my new idea is: on amd64, i386 I build both binaries CLASSIC and I2C on kfreebsd-i386, kfreebsd-amd64 and hurd-i386 I build both binaries CLASSIC on the rest I build only parse-edid (only get-edid uses build options). On 14 February 2014 13:24, Mathieu Malaterre wrote: > Hi, > > Okay I did not read your code carefully. You need to handle a matrix > of 4 cases, where only 2 were shown in your code. The actual counter > example was: -DCLASSICBUILD=YES and powerpc. Please handle powerpc > (any non-x86 actually) in your if statement. sorry for the confusion > with kfreebsd-* > > Thanks. > > On Fri, Feb 14, 2014 at 1:20 PM, Dariusz Dwornikowski > wrote: > > And I think it is set. It is the "else" clause. ksfreebsd-amd64 will be > > caught there and -DI2CBUILD=NO -DCLASSICBUILD=YES will be set. > > > > I think I am a little confused now. > > > > > > On 14 February 2014 13:12, Mathieu Malaterre < > mathieu.malate...@gmail.com> > > wrote: > >> > >> In which case you would need to have -DCLASSICBUILD=ON on > >> ksfreebsd-amd64 if I understand the previous exchange correctly. > >> > >> On Fri, Feb 14, 2014 at 1:07 PM, Dariusz Dwornikowski > >> wrote: > >> > I did not include the line, I take DEB_HOST_ARCH from: > >> > DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) > >> > > >> > So on ksfreebsd-amd64 it will give me: ksfreebsd-amd64, so DI2CBUILD > >> > would > >> > be set to NO. Or is it not ? > >> > > >> > > >> > On 14 February 2014 12:59, Mathieu Malaterre > >> > > >> > wrote: > >> >> > >> >> On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski > >> >> wrote: > >> >> > Ok I created such code in rules: > >> >> > > >> >> > override_dh_auto_configure: > >> >> > ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386)) > >> >> > dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES > >> >> > else > >> >> > dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES > >> >> > endif > >> >> > > >> >> > Can somebody review it for me ? I checked and it works on amd64 and > >> >> > i386. > >> >> > >> >> I don't think this works for -say- kfreebsd-amd64, which would > require > >> >> -DI2CBUILD=OFF > >> >> You need to handle each option independantly, depending on arch > >> >> > >> >> 2cts > >> > > >> > > >> > > >> > > >> > -- > >> > Pozdrawiam, > >> > Dariusz Dwornikowski, Assistant > >> > Institute of Computing Science, Poznań University of Technology > >> > www.cs.put.poznan.pl/ddwornikowski/ > >> > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > >> > > >> > >> > >> > >> -- > >> Mathieu > > > > > > > > > > -- > > Pozdrawiam, > > Dariusz Dwornikowski, Assistant > > Institute of Computing Science, Poznań University of Technology > > www.cs.put.poznan.pl/ddwornikowski/ > > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > > > > > > -- > Mathieu > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: RFS: read-edid/3.0.1-2
And I think it is set. It is the "else" clause. ksfreebsd-amd64 will be caught there and -DI2CBUILD=NO -DCLASSICBUILD=YES will be set. I think I am a little confused now. On 14 February 2014 13:12, Mathieu Malaterre wrote: > In which case you would need to have -DCLASSICBUILD=ON on > ksfreebsd-amd64 if I understand the previous exchange correctly. > > On Fri, Feb 14, 2014 at 1:07 PM, Dariusz Dwornikowski > wrote: > > I did not include the line, I take DEB_HOST_ARCH from: > > DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) > > > > So on ksfreebsd-amd64 it will give me: ksfreebsd-amd64, so DI2CBUILD > would > > be set to NO. Or is it not ? > > > > > > On 14 February 2014 12:59, Mathieu Malaterre < > mathieu.malate...@gmail.com> > > wrote: > >> > >> On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski > >> wrote: > >> > Ok I created such code in rules: > >> > > >> > override_dh_auto_configure: > >> > ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386)) > >> > dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES > >> > else > >> > dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES > >> > endif > >> > > >> > Can somebody review it for me ? I checked and it works on amd64 and > >> > i386. > >> > >> I don't think this works for -say- kfreebsd-amd64, which would require > >> -DI2CBUILD=OFF > >> You need to handle each option independantly, depending on arch > >> > >> 2cts > > > > > > > > > > -- > > Pozdrawiam, > > Dariusz Dwornikowski, Assistant > > Institute of Computing Science, Poznań University of Technology > > www.cs.put.poznan.pl/ddwornikowski/ > > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > > > > > > -- > Mathieu > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: RFS: read-edid/3.0.1-2
I did not include the line, I take DEB_HOST_ARCH from: DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) So on ksfreebsd-amd64 it will give me: ksfreebsd-amd64, so DI2CBUILD would be set to NO. Or is it not ? On 14 February 2014 12:59, Mathieu Malaterre wrote: > On Fri, Feb 14, 2014 at 12:55 PM, Dariusz Dwornikowski > wrote: > > Ok I created such code in rules: > > > > override_dh_auto_configure: > > ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386)) > > dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES > > else > > dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES > > endif > > > > Can somebody review it for me ? I checked and it works on amd64 and i386. > > I don't think this works for -say- kfreebsd-amd64, which would require > -DI2CBUILD=OFF > You need to handle each option independantly, depending on arch > > 2cts > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: RFS: read-edid/3.0.1-2
Ok I created such code in rules: override_dh_auto_configure: ifeq ($(DEB_HOST_ARCH), $(filter $(DEB_HOST_ARCH),amd64 i386)) dh_auto_configure -- -DCLASSICBUILD=YES -DI2CBUILD=YES else dh_auto_configure -- -DI2CBUILD=NO -DCLASSICBUILD=YES endif Can somebody review it for me ? I checked and it works on amd64 and i386. On 14 February 2014 11:56, Dariusz Dwornikowski < dariusz.dwornikow...@cs.put.poznan.pl> wrote: > Ok, > > So is it a good practice then to check the arch in rules and change -D... > accordingly ? > > > On 14 February 2014 11:34, Sven Joachim wrote: > >> On 2014-02-14 09:38 +0100, Dariusz Dwornikowski wrote: >> >> > Package: sponsorship-requests >> > Severity: normal >> > >> > Dear mentors, >> > >> > I am looking for a sponsor for my package "read-edid" >> >> Have you tried to contact the DD who sponsored the 3.0.1-1 upload yet? >> >> > Changes since the last upload: >> > >> > * Architecture set to i386 and amd64 >> >> I find that rather unfortunate. IIUC read-edid supports a VBE interface >> and an I2C interface, the former apparently being tied to x86 and the >> latter to Linux. So it should be possible to build read-edid with >> -DCLASSICBUILD=OFF on non-x86 and with -DI2CBUILD=OFF on non-Linux >> architectures. >> >> Cheers, >>Sven >> >> >> -- >> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org >> with a subject of "unsubscribe". Trouble? Contact >> listmas...@lists.debian.org >> Archive: http://lists.debian.org/87r476yoce....@turtle.gmx.de >> >> > > > -- > Pozdrawiam, > Dariusz Dwornikowski, Assistant > Institute of Computing Science, Poznań University of Technology > www.cs.put.poznan.pl/ddwornikowski/ > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: RFS: read-edid/3.0.1-2
Ok, So is it a good practice then to check the arch in rules and change -D... accordingly ? On 14 February 2014 11:34, Sven Joachim wrote: > On 2014-02-14 09:38 +0100, Dariusz Dwornikowski wrote: > > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "read-edid" > > Have you tried to contact the DD who sponsored the 3.0.1-1 upload yet? > > > Changes since the last upload: > > > > * Architecture set to i386 and amd64 > > I find that rather unfortunate. IIUC read-edid supports a VBE interface > and an I2C interface, the former apparently being tied to x86 and the > latter to Linux. So it should be possible to build read-edid with > -DCLASSICBUILD=OFF on non-x86 and with -DI2CBUILD=OFF on non-Linux > architectures. > > Cheers, >Sven > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/87r476yoce@turtle.gmx.de > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
RFS: read-edid/3.0.1-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "read-edid" * Package name: read-edid Version : 3.0.1-2 Upstream Author : Matthew Kern * URL : http://www.polypux.org/projects/read-edid/ * License : GPL-2+ Section : utils It builds those binary packages: read-edid - hardware information-gathering tool for VESA PnP monitors To access further information about this package, please visit the following URL: http://mentors.debian.net/package/read-edid Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/read-edid/read-edid_3.0.1-2.dsc More information about read-edid can be obtained from http://www.polypux.org/projects/read-edid/ . Changes since the last upload: * Architecture set to i386 and amd64 * Set Vcs-Git and Vcs-Browser in control -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: unable to upload on mentors after dput failure
I had the same problem. You need to upload via FTP, as described on
mentors.d.o. After that dput uploading will work again.
On 13 February 2014 01:23, bilibop project wrote:
> Hi,
>
> I wanted to upload a new version of my package on mentors.debian.nettoday.
> Unfortunately, the dput process has been interrupted, due to a bad
> connection on my side. Only the .dsc, and ~ half of the .tar.xz have been
> uploaded. Now, when I try to dput again the same source package, I get an
> error ("Uploading bilibop_0.4.21.dsc: Upload failed: 403 Forbidden").
> Obviously, my page shows no package, and I have tried dput --force. Is
> there a way to solve this issue?
>
> Thanks
> quidame
>
>
> --
> To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: http://lists.debian.org/n1r-p31oa5r...@safe-mail.net
>
>
--
Pozdrawiam,
Dariusz Dwornikowski, Assistant
Institute of Computing Science, Poznań University of Technology
www.cs.put.poznan.pl/ddwornikowski/
room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Rules for packaging forked software
On Sun, Feb 09, 2014 at 10:33:19PM +1100, Craig Small wrote: > On Sat, Feb 08, 2014 at 11:31:20PM +0800, Paul Wise wrote: > > Upstreams continue to disappoint me :( > I tend ending up as my own upstream a lot of the time, so I provide my > own disappointment. > > Forks are a pain, but they often can be in the long run a benefit. This > is especially so if the parent project has gone dormant, which it sounds > like it for at least one of the cases. I think viewnior's case is not so bad. Upstream did give good reasons for embedding the library (and changing it), he also was, and still is, willing to incorporate his changes into the official library. The problem is that I and upstream have no response from the official library Authors. It has been dormant for 3 years now. Additionally viewnior will drop the support for their fork around April. I think it is worth uploading viewnior now anyway. If you somebody could sponsor the upload I would be grateful. All distros have this great image browser but we. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Bug#738193: RFS: viewnior/1.4-1 [ITP]
Sorry for wrong version, ofc it is about 1.4 not 1.3 which is also in mentors. Guy released today. On 8 February 2014 15:34, Dariusz Dwornikowski < dariusz.dwornikow...@cs.put.poznan.pl> wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "viewnior" > > * Package name: viewnior >Version : 1.3-1 >Upstream Author : Siyan Panayotov > * URL : http://xsisqox.github.io/Viewnior/ > * License : GPL-3 >Section : graphics > > It builds those binary packages: > > viewnior - simple, fast and elegant image viewer > > To access further information about this package, please visit the > following URL: > > http://mentors.debian.net/package/viewnior > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/v/viewnior/viewnior_1.3-1.dsc > > More information about viewnior can be obtained from > http://xsisqox.github.io/Viewnior/. > > Changes since the last upload: > > * Initial release (Closes: #582090) > > Regards, >Dariusz Dwornikowski > > -- > Pozdrawiam, > Dariusz Dwornikowski, Assistant > Institute of Computing Science, Poznań University of Technology > www.cs.put.poznan.pl/ddwornikowski/ > room 2.7.2 BTiCW | tel. +48 61 665 29 41 > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/20140208143444.gc20...@blackstar.cs.put.poznan.pl > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#738193: RFS: viewnior/1.4-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "viewnior" * Package name: viewnior Version : 1.3-1 Upstream Author : Siyan Panayotov * URL : http://xsisqox.github.io/Viewnior/ * License : GPL-3 Section : graphics It builds those binary packages: viewnior - simple, fast and elegant image viewer To access further information about this package, please visit the following URL: http://mentors.debian.net/package/viewnior Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/v/viewnior/viewnior_1.3-1.dsc More information about viewnior can be obtained from http://xsisqox.github.io/Viewnior/. Changes since the last upload: * Initial release (Closes: #582090) Regards, Dariusz Dwornikowski -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208143444.gc20...@blackstar.cs.put.poznan.pl
Re: Rules for packaging forked software
Ok, I contacted viewnior Author. His response is : "First off, gtkimageview was not active when I started working on Viewnior, that is why I decided to embed it. I contains a lot of bugs and obsolete code, so stripping viewnior and using vanila gtkimageview is out of the question. If there is an option to merge my fixes to gtkimageview and release a new version of the library, I am more than willing to." Also he plans to release a gtk3 version without gtkimageview dependency around April, so the problem will disappear. My idea is to upload viewnior anyway. Around April I will just repackage for gtk3. PS: We made it to twitter: [1] [1] https://twitter.com/xsisqox/status/432135573994999808 -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Rules for packaging forked software
On Sat, Feb 08, 2014 at 06:08:43PM +0800, Paul Wise wrote: > I expect the GNOME community would at the very least be willing to let > viewnior folks have commit access to the git repository at > git.gnome.org. If that fails they could create a proper fork at a new > location but I guess viewnior folks aren't interested in that either > though? I will contact the viewnior developer, asking one more time to include these patches in gtkimageview. I will CC gtkimageview developer too. > > Another option is to ask the Debian maintainer of gtkimageview to > include the patches. I think this is too much hassle, I think we do not have means of testing this self made integration fully. If it fails with the step 1 I will do this. Thank you. > > If viewnior gets packaged with the embedded code copy, please notify > the security team about this: If all fails, I will do this. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140208122133.ga20...@blackstar.cs.put.poznan.pl
Bug#738168: RFS: equalx/0.6.0-1 [ITP]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "equalx" * Package name: equalx Version : 0.6.0-1 Upstream Author : Mihai Niculescu * URL : http://equalx.sourceforge.net/index.html * License : GPL-3 Section : tex It builds those binary packages: equalx - LaTeX equations graphical editor To access further information about this package, please visit the following URL: http://mentors.debian.net/package/equalx Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/e/equalx/equalx_0.6.0-1.dsc More information about hello can be obtained from http://equalx.sourceforge.net/index.html. Changes since the last upload: * Initial release (Closes: #714051) -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 signature.asc Description: Digital signature
Re: Rules for packaging forked software
> > > For gtkimageview I'm not familiar with the situation but I expect that > is more like the typical embedded code copies situation; viewnior > upstream probably didn't bother sending their few patches to > gtkimageview upstream. The right thing to do in that case is to get > the two upstreams talking about the patches so they can be included. > > Yes, exactly. The Author of viewnior took some parts of gtkimageview and embedded it in viewnior, cutting some code out and changing names of functions and some variables. I think this is the reason for his reluctance to patch original gtkimageview. Also gtkimageview, from what I can see on their github [1] have not been active in 3 years. During the last ITP [2] Julien Lavergne and Yao Wei managed to create diff and they came to the same conclusions. Also they contacted viewnior Author and asked to strip the library out of viewnior but he refused. I can see two ways out now. One is to just package viewnior. If gtkimageview is not active anymore and viewnior is, then we can assume that their ways went apart much and really this is a new version of the library. Also I think that if viewnior Author would not explicitly tell that he used gtkimageview, we probably would not have this hassle. The second way is to contact both sides and get their responds. Here I suspect they both would not want to participate. Anyway, the package is ready [3]. [1] https://github.com/GNOME/gtkimageview [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582090 [3] https://mentors.debian.net/package/viewnior -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737791: RFS: vimhelp-de/7.4.130818-3 [ITA]
Hi, I cannot be your sponsor but here are some advices. On [1] you can see lintian warning and errors. You should fix them. For example: Package uploaded for the unreleased distribution means that you need to change your changelog entry so the distribution is unstable not UNRELEASED. Also you should have Build-Depends: debhelper (>= 9.0), in control file, as lintian suggests. A good practice is to make lintian checks locally with the same level of details as on mentors, in ~/.config/lintian/lintianrc: pedantic=yes display-info=yes [1] http://mentors.debian.net/package/vimhelp-de On 6 February 2014 00:59, Julian Goestl wrote: > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "vimhelp-de" > > Package name: vimhelp-de > Version : 7.4.130818-3 > Upstream Author : Florian 'eix' Rehnisch > > < > /span> > URL : http://www.florianrehnisch.de/vimhelp/ > License : Open Publication License without any options v1.0, 8 June > 1999 > Section : doc > > It builds those binary packages: > > vimhelp-de - Vi IMproved - Documentation files (German translation) > > To access further information about this package, please visit the following > URL: > > http://mentors.debian.net/package/vimhelp-de > > > Alternatively, one can download the package with dget using this command: > > dget -x > http://mentors.debian.net/debian/pool/main/v/vimhelp-de/vimhelp-de_7.4.130818-3.dsc > > > Changes since the last upload: > > Clean up and update Standards version to 3.9.5 > > > Regards, > Julian Goestl > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737751: RFS: read-edid/3.0.1-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "read-edid" * Package name: read-edid Version : 3.0.1-1 Upstream Author : Matthew Kern * URL : http://www.polypux.org/projects/read-edid/ * License : GPL-2+ Section : utils It builds those binary packages: read-edid - hardware information-gathering tool for VESA PnP monitors To access further information about this package, please visit the following URL: http://mentors.debian.net/package/read-edid Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/read-edid/read-edid_3.0.1-1.dsc More information about hello can be obtained from http://www.polypux.org/projects/read-edid/ . Changes since the last upload: * Migrated to dh * Bump standard to 3.9.5 * Migrated to 3.0 quilt format * New maintainer (closes: #733145) * New upstream version * Quilt patch system - remove additional licence file from CMakeLists * debian/copyright - migrated to DEP5 format Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Need help signing and uploading
Hi, 1. You have to create a key according to [1] 2. You need to create your package, place your email and name in changelog. 3. Run debuild and debuild will sign your package, taking the key for the email you have in your changelog. 4. As for mentors, here you have the instructions [2], section 4. You have to get an account there first. [1] http://keyring.debian.org/creating-key.html [2] https://mentors.debian.net/intro-maintainers On 5 February 2014 14:39, Julian Göstl wrote: > Hi, > > can anybody explain step-by-step how correctly sign and upload a package > to mentors.debian.net? > > Greetings > Julian Goestl > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/52f23f03.9010...@t-online.de > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737710: RFS: linuxlogo/5.11-4 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am still looking for a sponsor for my package "linuxlogo". I have fixed problems with the package that have been shown to me during the last RFS request. * Package name: linuxlogo Version : 5.11-4 Upstream Author : Vince Weaver * URL : http://www.deater.net/weave/vmwprod/linux_logo/ * License : GPL-2 Section : misc It builds those binary packages: linuxlogo - Color ANSI System Logo To access further information about this package, please visit the following URL: http://mentors.debian.net/package/linuxlogo Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/linuxlogo/linuxlogo_5.11-4.dsc More information about hello can be obtained from http://www.deater.net/weave/vmwprod/linux_logo/ Changes since the last upload: * Migrated to dh * New maintainer (Closes: #726550) * Bump standards to 3.9.5 * New logos added (Raspberry PI and OpenBSD) * Migrated to quilt 3.0 format * Quilt used as a patch system -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Upstream changes destination from sbin to bin
Yes I followed the upstream. I will soon upload new version. The previous package should not be credited to me, it is the work of Liu Qi and Stefano Zacchiroli. On 3 February 2014 21:12, Jonathan Dowland wrote: > On Mon, Feb 03, 2014 at 02:34:43PM +0100, Dariusz Dwornikowski wrote: > > I am working on read-edid package which ships two binaries: get-edid and > > parse-edid. > > By coincidence I just used these programs yesterday. Thanks for your > work! > > I'd just follow upstream and move the binary. I wouldn't bother with > a compatibility symlink; it's very unlikely to be encoded into any > scripts and you will have problems if people have symlinked /usr/sbin > -> /usr/bin or future transitions, merges, whatever. > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20140203201222.gc10...@bryant.redmars.org > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737390: RFS: kerneltop/0.91-1 [ITA]
Hey, Thank You very much for your suggestions !! Here is a link [1] to the package fixed according to your suggestions. [1] https://mentors.debian.net/package/kerneltop On 4 February 2014 03:42, Liang Guo wrote: > Interesting package, this is my review: > > 1 upstream ships manpage, so please remove debian/kerneltop.1 > 2 3.0 (quilt) always use quilt to manage patches, so README.source is > meaningless, please remove > 3 Upstream makefile don't use CFLAGS environmen which includes build > harden flags. I advice you pach "CCFLAGS=-g/-s" in makefile with > "CCFLAGS=-g/-s $(CFLAGS)" to include build harden flags and remove > debian/source/lintian-overrides > 4 Please update debian/copyright with DEP5 format[2]. > > Thanks for your working on debian. > > > [1] https://wiki.debian.org/Hardening > [2] http://dep.debian.net/deps/dep5/ > > -- > Liang Guo > http://guoliang.me > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Upstream changes destination from sbin to bin
In fact I have binary in /usr/sbin in the current version, the new version will just switch to /usr/bin. Thank You for your response. On 3 February 2014 14:47, Arturo Borrero Gonzalez < arturo.borrero.g...@gmail.com> wrote: > On 3 February 2014 14:34, Dariusz Dwornikowski > wrote: > > Hi, > > > > I am working on read-edid package which ships two binaries: get-edid and > > parse-edid. In current Debian package get-edid is installed into > /usr/sbin > > and parse-edid to /usr/bin. Upstream Author changed build system from > plain > > makefiles to cmake, and also in the new version (3.0.0) both binaries > > install into /usr/bin. > > > > What should be done in such a situation? Should I follow Author's > intentions > > or patch CMakeLists.txt (I patch it anyway to set proper man paths). > > > > What about linking? so you have the binary in both /usr/bin and > /usr/sbin. But you should assure this doesn't conflict with FHS or > other Debian standar. > > Anyway, I don't see any problem in changing the path. I guess users > are using $PATH to invoke the program, or `which' in a shell script. > -- > Arturo Borrero González > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Upstream changes destination from sbin to bin
Hi, I am working on read-edid package which ships two binaries: get-edid and parse-edid. In current Debian package get-edid is installed into /usr/sbin and parse-edid to /usr/bin. Upstream Author changed build system from plain makefiles to cmake, and also in the new version (3.0.0) both binaries install into /usr/bin. What should be done in such a situation? Should I follow Author's intentions or patch CMakeLists.txt (I patch it anyway to set proper man paths). -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737208: RFS: linuxlogo/5.11-4
I do not want to close old bugs. Just asking, what will happen with bugs for older versions that e.g. are not used anywhere no more? Will these bugs hang forever or is there a cleaning policy ? On 2 February 2014 22:23, Jakub Wilk wrote: > * Dariusz Dwornikowski , > 2014-01-31, 21:02: > > Should these bugs be then closed manually ? >> > > Which bugs, and why do you want to close them? > > > -- > Jakub Wilk > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20140202212348.ga13...@jwilk.net > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737390: RFS: kerneltop/0.91-1 [ITA]
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "kerneltop" * Package name: kerneltop Version : 0.91-1 Upstream Author : Randy Dunlap * URL : http://www.infradead.org/~rdunlap/src/ * License : GPL-2+ Section : devel It builds those binary packages: kerneltop - shows Linux kernel function usage in a style like top To access further information about this package, please visit the following URL: http://mentors.debian.net/package/kerneltop Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/k/kerneltop/kerneltop_0.91-1.dsc Changes since the last upload: * Closes orphaned bug (closes: #729381) * Migration to dh * Updated copyright and FSF address * Migration to format 3.0 * Restored proper versioning * New upstream version * Updated project homepage -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Bug#737208: RFS: linuxlogo/5.11-4
Ok thank You, I will fix these asap. Should these bugs be then closed manually ? On 31 January 2014 20:17, Jakub Wilk wrote: > I don't intend to sponsor this package, sorry! > > It would have been better if you hadn't explicitly CC debian-mentors@ldowhen > subitting the RFS bug. The mailing list receives all the bugreports > anyway; but if you CC it, it gets a copy without the bug number assigned. > > * Dariusz Dwornikowski , > 2014-01-31, 12:27: > >> http://mentors.debian.net/debian/pool/main/l/linuxlogo/ >> linuxlogo_5.11-4.dsc >> >> More information about hello can be obtained from http://www.example.com >> . >> > > Oh really, example.com? :) > > * Closes: #187655, upstream won't fix >> * Closes: #187655, not relevant anymore >> > > Why close the same bug twice? > Anyway, Developer's Reference §5.8.4 reads: “Do not close bugs in the > changelog entry of a version if the changes in that version of the package > don't have any bearing on the bug.” > > -- > Jakub Wilk > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: http://lists.debian.org/20140131191716.ga6...@jwilk.net > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
RFS: linuxlogo/5.11-4
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "linuxlogo" * Package name: linuxlogo Version : 5.11-4 Upstream Author : Vince Weaver * URL : http://www.deater.net/weave/vmwprod/linux_logo/ * License : GPL-2 Section : misc It builds those binary packages: linuxlogo - Color ANSI System Logo To access further information about this package, please visit the following URL: http://mentors.debian.net/package/linuxlogo Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/linuxlogo/linuxlogo_5.11-4.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Migrated to dh * ITA (Closes: #726550) * Closes: #187655, upstream won't fix * Closes: #187655, not relevant anymore * Bump standards to 3.9.5 * New logos added (Raspberry PI and OpenBSD) * Migrated to quilt 3.0 format Regards, Dariusz Dwornikowski -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Dead upstream - github mirror
Ok Ill ask on LKLM thanks. On 29 January 2014 11:40, Paul Wise wrote: > On Wed, Jan 29, 2014 at 5:18 PM, Dariusz Dwornikowski wrote: > > > I am taking over kerneltop package, I use it a lot in various systems. > The > > upstream webpage does not exist, also upstream authors do not respond > > (contacted them 3 weeks ago). The effect is that the upstream package > does > > not have a webpage or any vcs. Is it good idea to mirror the package in > my > > github to give it "some" place in the world? Of course I will clearly > state > > original Authors and this way any patches can be easily forwarded to > "new" > > upstream. > > Maybe try asking on LKML? > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/CAKTje6EYYEUtww3wzpdBg1qLvvw-9qdPbAuc+YBkh=nkctd...@mail.gmail.com > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Dead upstream - github mirror
HI I am taking over kerneltop package, I use it a lot in various systems. The upstream webpage does not exist, also upstream authors do not respond (contacted them 3 weeks ago). The effect is that the upstream package does not have a webpage or any vcs. Is it good idea to mirror the package in my github to give it "some" place in the world? Of course I will clearly state original Authors and this way any patches can be easily forwarded to "new" upstream. -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Problem with unusual upstream source directory
One question Gabriele, If I add -iop and upload the package to mentors and my package will be uploaded to Debian, will Debian build servers know they should also add -iop option when building ? On 4 January 2014 01:08, Gabriele Giacone <1o5g4...@gmail.com> wrote: > On Fri, Jan 3, 2014 at 6:09 PM, Игорь Пашев wrote: > > 2014/1/3 Gabriele Giacone <1o5g4...@gmail.com>: > >> Teach clean target how to remove them. > > > > No-no-no :-) > > > > *.po files are handwritten [1] > > $ debuild -ipo > > -- > G..e > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/cabcawc2ldbuzcoo9wvggsrjvwab9xsg04xf_-4z4oyewedc...@mail.gmail.com > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
Re: Problem with unusual upstream source directory
@Gabriele thank you. When I add -i to debuild will Debian build servers do the same ? @Paul good idea but I'll contact upstream, however they are not so responsive. On 4 January 2014 06:52, Paul Wise wrote: > On Sat, Jan 4, 2014 at 12:18 AM, Dariusz Dwornikowski wrote: > > > So I have got a problem, upstream has localization files in po/ > directory. > > When make is called, it traverses to po/ and also calls make, then .po > files > > change (they are updated with the current date) like in the example > below. > > Unfortunately, debuild when using quilt 3.0 format crashes with message > that > > upstream has changed. Is there a way to somehow ignore these files in > > debuild. I cannot do dpkg-source --commit because these file would be > > updated anyway in every build. > > I think you can avoid this by asking upstream to run make -C po > update-po before every release. > > -- > bye, > pabs > > http://wiki.debian.org/PaulWise > > > -- > To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact > listmas...@lists.debian.org > Archive: > http://lists.debian.org/CAKTje6GyB3Kn-X_AfWXV3byoF0US9-_k=e9SH_4=asmgbbx...@mail.gmail.com > > -- Pozdrawiam, Dariusz Dwornikowski, Assistant Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41
