debian/bug-control fields
Hi, where can I find a list and description of all valid fields that can be used in debian/bug-control or debian/foobar.bug-control ? I know only three of them: Submit-As: Report-With: Package-Status: What I understand is that for 'package-status', the status of the listed packages (and their dependencies/recommendations/suggestions) are included in the body of the report; and so, there is no need to add something as 'dpkg-query -l foobar' in debian/bug-script if foobar is listed in the 'Package-Status:' field. But I've found nothing in Debian Policy or dh_bugfiles(1) or reportbug(1) manpages to know all valid fields and how they are handled. 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-b34nwei...@safe-mail.net
Re: debian/bug-control fields
On Mon, Oct 15, 2012 at 6:44 PM, bilibop project wrote: where can I find a list and description of all valid fields that can be used in debian/bug-control or debian/foobar.bug-control ? ... But I've found nothing in Debian Policy or dh_bugfiles(1) or reportbug(1) manpages to know all valid fields and how they are handled. The dh_bugfiles manual page directs you to look at this: /usr/share/doc/reportbug/README.developers.gz -- 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/CAKTje6Fo1aM0wOcj+HC5--7QSzQsLWSa3Mn=f42hL5CE=rt...@mail.gmail.com
Bug#683184: RFS: suckless-tools/39-1 [ITA]
On 22:28 Sun 14 Oct , Jakub Wilk wrote:
* Vasudev Kamath kamathvasu...@gmail.com, 2012-10-14, 16:09:
W: suckless-tools source: native-package-with-dash-version
Yeah I saw these but I think changing the version number will
cause lot of problem right?
It's not the version that is wrong. -1 was a non-native package, and
so should be -2. Quoting the tag description:
Native source packages are sometimes created by accident. In most
cases the reason is the location of the original source tarball. For
version 1.0 source packages, dpkg-source determines whether they're
non-native by looking for a file named
package_upversion.orig.tar.gz in the parent directory, where
upversion is the upstream version from the most recent
debian/changelog entry.
Now understood the issue correctly. I was using pdebuild and I don't
know how it started considering 38-2 as the orig tarball! Well now I
used the git-buildpackage and it looks fine.
Also now as intregeri said I've moved the package on separate branch
called in Wheezy. Master branch tracks only 39 version. Please review
and let me know if any more things needs to be fixed
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Bug#683184: RFS: suckless-tools/39-1 [ITA]
On 14:53 Sun 14 Oct , intrigeri wrote:
Hi,
(meta: I'm Vasudev's AM ;)
Vasudev Kamath wrote (12 Oct 2012 03:31:39 GMT) :
On Fri, Oct 12, 2012 at 12:28 AM, Jakub Wilk jw...@debian.org wrote:
New repository for the squeeze branch feels wrong to me
FWIW it feels wrong to me to. That's what branches are for.
Note that branches in the same repository don't necessarily have to
share common ancestors: e.g. the pristine-tar branch, when using gbp +
pristine-tar, does not share its history with the upstream and
packaging branches.
Well it is actually wrong but I can't see other altenative but
I think I will try it on -mentors and see if others have any
good idea.
One thing I can think is just remove existing suckless-tools
repository (I any how have my local copy) then rename
suckless-tools-38 to suckless-tools and on top of this import my 39
work so 38 history and 39 both can leave together. Let me see
Rewriting already published branches' history is a no-go.
What I would suggest is:
* create a squeeze branch in the existing repository (from scratch,
no shared ancestors)
* import the needed and missing (older) version into the squeeze
branch
Done the package now resides under wheezy branch. To be frank every
problem has simple solution :) I was overly complicating it thanks for
heads up ;)
* git checkout master git merge -s ours squeeze
Well *wheezy* branch will go independent of master. If you think it
can be merged please let me know your thoughts :-)
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Bug#683184: RFS: suckless-tools/39-1 [ITA]
Hi, Vasudev Kamath wrote (15 Oct 2012 03:43:55 GMT) : * git checkout master git merge -s ours squeeze Well I don't really think I can merge it back to master! I think you should read the documentation about -s ours, before concluding you can't merge it back to master. Well unfortunately that repository no more exists! I don't know what happened but I guess either domain moved or something else happened. Have you tried asking the previous maintainer to provide you with their old repository's history? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- 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/85y5j7d5na@boum.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
On 19:08 Mon 15 Oct , intrigeri wrote:
Hi,
Vasudev Kamath wrote (15 Oct 2012 03:43:55 GMT) :
* git checkout master git merge -s ours squeeze
Well I don't really think I can merge it back to master!
I think you should read the documentation about -s ours,
before concluding you can't merge it back to master.
Tried that but what here happens is wheezy branch is based on master
which doesn't have any 38 related history at all. So merging will
overwrite my 39 work. (I tried this)
Well unfortunately that repository no more exists! I don't know what
happened but I guess either domain moved or something else happened.
Have you tried asking the previous maintainer to provide you with
their old repository's history?
No I didn't take over directly, it was a bit of mess again one more
guy wanted to take over but since he didn't had much time I took over
from his work.
Best Regards
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyninja@{frndk.de | vasudev.homelinux.net}
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: Digital signature
Processed: your mail
Processing commands for cont...@bugs.debian.org: retitle 663916 RFS: phonetisaurus/0.6-1 [ITP] -- Grapheme to Phoneme conversion tool Bug #663916 [sponsorship-requests] RFS: phonetisaurus/0.5-1 [ITP] -- Grapheme to Phoneme conversion tool Changed Bug title to 'RFS: phonetisaurus/0.6-1 [ITP] -- Grapheme to Phoneme conversion tool' from 'RFS: phonetisaurus/0.5-1 [ITP] -- Grapheme to Phoneme conversion tool' stop Stopping processing here. Please contact me if you need assistance. -- 663916: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663916 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13503298109312.transcr...@bugs.debian.org
Bug#663916: New phonetisaurus package available
Hi! There has been a new phonetisaurus release (0.6). All the patches have been applied upstream, the backup file in sparsehash has been removed, FstPathFinder.* have been rewritten from scratch. I updated the Debian package files accordingly. All the phonetisaurus files have a BSD-2-clause header, but the README.txt reports BSD-3-clause. I will ask upstream about this. Bests, Giulio. Il 13/10/2012 15:54, Giulio Paci ha scritto: Hi! Thank you for your review. Il 13/10/2012 00:02, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2012-10-11, 03:52: git://git.debian.org/git/collab-maint/phonetisaurus.git. Last but not least, why do you need to recover this file? It looks like it shouldn't have been included in the upstream tarball in the first place. Just because it was in the original tarball and I want that a debian/rules clean results in the same content of the original tarball. Now I seem to recall that you told me that your workflow depends on such restoration. Sorry for the noise. No problem. Oh, and Google sparse hash implemented is already packaged in Debian. Please build-depend on libsparsehash-dev and make sure that the system-wide copy is used, not the bundled one. Packaging the UTF-8 library (currently in src/3rdparty/utf8/) might be also worth considering, in order to comply with Policy §4.13. As we are not talking about shared libraries, but about a few headers files, I do not understand the benefits of doing so. The main benefit is the same: you can fix bugs in one place, instead of doing it N places (where N is usually 1). Yes, I understand the goal, but I am worried that using external source code would make it harder to replicate possible issues (I will need the exact version of the libsparsehash-dev binary package that was used to compile the library). However this is probably true for many other C++ libraries. It is just more evident here, where the libraries are just simple header files. I see only disadvantages: 1) using system wide files will prevent me to easily know the source code used to compile the phonetisaurus debian package; (Sometimes we need to keep exact source for license reasons; that's what Built-Using field is for.) How can I set Built-Using field? Should I set it by hand? Is it possible to set it automatically? 2) fixes in sparsehash will not be available to phonetisaurus unless phonetisaurus is recompiled; That's not worse than status quo. Also: binNMUs are cheap. Maybe I am missing something in the upload process (well, I am missing almost everything to be honest). Can you point some reference that will help me understanding what will happen when new releases of libsparsehash-dev will be released (and phonetisaurus will need recompilation)? 3) I will need to maintain patches to use the system-wide copy; Created, applied and forwarded a patch for this. 4) an additional dependency is introduced; Again, convince upstream to drop the embedded copy, and these problems will go away. :) Additional dependency introduced. :-) If the patch will be accepted upstream, the patch will let upstream to compile embedded copy of the libraries and us to compile using the system-wide dependency. 5) If I will package UTF-8 I will need to invest time maintaining a new package that I do not care about and that contains just 4 headers files. I checked that there are at least 14 source packages in Debian that bundle UTF8-CPP: drizzle fife gdcm gource librime libvoikko love md5deep megaglest mkvtoolnix paraview ruby-passenger supertuxkart vtk Hopefully one of their maintainers would be interested in packaging it separately. Maybe file an RFP, CCing them all? If you think it is useful, I will do this. However I would like to understand how I am supposed to deal with this kind of libraries before doing this. With the patch above, it will be very easy to use the system-wide utfcpp library once it is packaged. Do you think that policy §4.13 apply in this case? I seems to me that it is more related to shared libraries than static ones and headers. No, §4.13 it's not only about shared library. It does apply here. Ok, using libsparsehash-dev then. Moreover I think that the last part of the following sentence applies: Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. Do you have any evidence that this is the case (e.g. links to upstream documentation saying this is the preferred way of using the libraries)? No, I have no evidence about it, but the documentation is scarce in this sense. Both libraries report something like: You just need to put the .h files somewhere your compiler can see this. I just thought that sparsehash and utf8 are similar enough to gnulib that people would use them in the same way. FWIW, I'm
Bug#663916: New phonetisaurus package available
Hi! There has been a new phonetisaurus release (0.6). All the patches have been applied upstream, the backup file in sparsehash has been removed, FstPathFinder.* have been rewritten from scratch. I updated the Debian package files accordingly. All the phonetisaurus files have a BSD-2-clause header, but the README.txt reports BSD-3-clause. I will ask upstream about this. Bests, Giulio. Il 13/10/2012 15:54, Giulio Paci ha scritto: Hi! Thank you for your review. Il 13/10/2012 00:02, Jakub Wilk ha scritto: * Giulio Paci giuliop...@gmail.com, 2012-10-11, 03:52: git://git.debian.org/git/collab-maint/phonetisaurus.git. Last but not least, why do you need to recover this file? It looks like it shouldn't have been included in the upstream tarball in the first place. Just because it was in the original tarball and I want that a debian/rules clean results in the same content of the original tarball. Now I seem to recall that you told me that your workflow depends on such restoration. Sorry for the noise. No problem. Oh, and Google sparse hash implemented is already packaged in Debian. Please build-depend on libsparsehash-dev and make sure that the system-wide copy is used, not the bundled one. Packaging the UTF-8 library (currently in src/3rdparty/utf8/) might be also worth considering, in order to comply with Policy §4.13. As we are not talking about shared libraries, but about a few headers files, I do not understand the benefits of doing so. The main benefit is the same: you can fix bugs in one place, instead of doing it N places (where N is usually 1). Yes, I understand the goal, but I am worried that using external source code would make it harder to replicate possible issues (I will need the exact version of the libsparsehash-dev binary package that was used to compile the library). However this is probably true for many other C++ libraries. It is just more evident here, where the libraries are just simple header files. I see only disadvantages: 1) using system wide files will prevent me to easily know the source code used to compile the phonetisaurus debian package; (Sometimes we need to keep exact source for license reasons; that's what Built-Using field is for.) How can I set Built-Using field? Should I set it by hand? Is it possible to set it automatically? 2) fixes in sparsehash will not be available to phonetisaurus unless phonetisaurus is recompiled; That's not worse than status quo. Also: binNMUs are cheap. Maybe I am missing something in the upload process (well, I am missing almost everything to be honest). Can you point some reference that will help me understanding what will happen when new releases of libsparsehash-dev will be released (and phonetisaurus will need recompilation)? 3) I will need to maintain patches to use the system-wide copy; Created, applied and forwarded a patch for this. 4) an additional dependency is introduced; Again, convince upstream to drop the embedded copy, and these problems will go away. :) Additional dependency introduced. :-) If the patch will be accepted upstream, the patch will let upstream to compile embedded copy of the libraries and us to compile using the system-wide dependency. 5) If I will package UTF-8 I will need to invest time maintaining a new package that I do not care about and that contains just 4 headers files. I checked that there are at least 14 source packages in Debian that bundle UTF8-CPP: drizzle fife gdcm gource librime libvoikko love md5deep megaglest mkvtoolnix paraview ruby-passenger supertuxkart vtk Hopefully one of their maintainers would be interested in packaging it separately. Maybe file an RFP, CCing them all? If you think it is useful, I will do this. However I would like to understand how I am supposed to deal with this kind of libraries before doing this. With the patch above, it will be very easy to use the system-wide utfcpp library once it is packaged. Do you think that policy §4.13 apply in this case? I seems to me that it is more related to shared libraries than static ones and headers. No, §4.13 it's not only about shared library. It does apply here. Ok, using libsparsehash-dev then. Moreover I think that the last part of the following sentence applies: Debian packages should not make use of these convenience copies unless the included package is explicitly intended to be used in this way. Do you have any evidence that this is the case (e.g. links to upstream documentation saying this is the preferred way of using the libraries)? No, I have no evidence about it, but the documentation is scarce in this sense. Both libraries report something like: You just need to put the .h files somewhere your compiler can see this. I just thought that sparsehash and utf8 are similar enough to gnulib that people would use them in the same way. FWIW, I'm
Bug#690589: RFS: libdigest-md6-perl/0.11-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package libdigest-md6-perl * Package name: libdigest-md6-perl Version : 0.11-1 Upstream Author : Andy Armstrong a...@hexten.net * URL : http://search.cpan.org/~andya/Digest-MD6/ * License : Perl (Artistic and GPL) Section : perl It builds those binary packages: libdigest-md6-perl - Digest::MD6 - Perl interface to the MD6 Algorithm To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libdigest-md6-perl Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libd/libdigest-md6-perl/libdigest-md6-perl_0.11-1.dsc Changes since the last upload: * New upstream release. Regards, Oleg Gashev -- 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/ca+0auqh7hkdhhsugvgh2k6g_7bjx58hwsu-6_nxho6w0wf-...@mail.gmail.com
Bug#683184: RFS: suckless-tools/39-1 [ITA]
* Vasudev Kamath kamathvasu...@gmail.com, 2012-10-15, 20:13: Now understood the issue correctly. I was using pdebuild and I don't know how it started considering 38-2 as the orig tarball! Well now I used the git-buildpackage and it looks fine. Indeed, it looks okay now. Why are there 2 newlines between the paragraphs in debian/control? It's not clear to me whether this is compliant with Policy §5.1 (though admittedly both dpkg and debhelper parsers are happy about it). Could you remove the extra newline? -- 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/20121015212825.ga...@jwilk.net
Bug#690589: RFS: libdigest-md6-perl/0.11-1
Hi, Oleg Gashev gas...@gmail.com writes: libdigest-md6-perl - Digest::MD6 - Perl interface to the MD6 Algorithm dget -x http://mentors.debian.net/debian/pool/main/libd/libdigest-md6-perl/libdigest-md6-perl_0.11-1.dsc You might want to join the Debian Perl Group you already list as the maintainer for this package ;) See [1] for more details. [1] http://wiki.debian.org/Teams/DebianPerlGroup/Welcome Besides that: - The two entries in debian/changelog should probably be collapsed into one. - The (build-)dependencies on hardening-wrapper, perl-base and perl-modules look wrong. Why are they there? - I would use just Perl interface to the MD6 algorithm as the short description. Most Perl modules use that scheme. - debian/copyright is wrong. Some parts are distributed under the same terms as perl, ie. Artistic or GPL-1+; other parts use BSD-like licenses. There are also additional copyright holders. See [2] for an example how to document the Artistic or GPL-1+ part. [2] http://packages.debian.org/changelogs/pool/main/libc/libcatalyst-action-rest-perl/current/copyright - README should not be installed as documentation as it contains only installation information that is of no use when you installed the Debian package. Ansgar -- 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/87hapvpg3n@deep-thought.43-1.org
Processed: Re: Bug#670176 closed by Bart Martens ba...@debian.org (closing RFS: kismet/2011.03.R2-1 [ITA])
Processing commands for cont...@bugs.debian.org:
package sponsorship-requests
Limiting to bugs with field 'package' containing at least one of
'sponsorship-requests'
Limit currently set to 'package':'sponsorship-requests'
unarchive 670176
Bug #670176 {Done: Bart Martens ba...@debian.org} [sponsorship-requests] RFS:
kismet/2011.03.R2-1 [ITA]
Unarchived Bug 670176
reopen 670176
Bug #670176 {Done: Bart Martens ba...@debian.org} [sponsorship-requests] RFS:
kismet/2011.03.R2-1 [ITA]
Bug reopened
Ignoring request to alter fixed versions of bug #670176 to the same values
previously set
thanks
Stopping processing here.
Please contact me if you need assistance.
--
670176: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670176
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--
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/handler.s.c.13503524936230.transcr...@bugs.debian.org
Processed: libdigest-md6-perl: block ITP 602929 by RFS 690589
Processing commands for cont...@bugs.debian.org: block 602929 by 690589 Bug #602929 [wnpp] ITP: libdigest-md6-perl -- Perl interface to the MD6 Algorithm 602929 was not blocked by any bugs. 602929 was not blocking any bugs. Added blocking bug(s) of 602929: 690589 stop Stopping processing here. Please contact me if you need assistance. -- 602929: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=602929 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135036121228742.transcr...@bugs.debian.org
Processed: RFS: libdigest-md6-perl/0.11-1 [ITP]
Processing commands for cont...@bugs.debian.org: retitle 690589 RFS: libdigest-md6-perl/0.11-1 [ITP] Bug #690589 [sponsorship-requests] RFS: libdigest-md6-perl/0.11-1 Changed Bug title to 'RFS: libdigest-md6-perl/0.11-1 [ITP]' from 'RFS: libdigest-md6-perl/0.11-1' stop Stopping processing here. Please contact me if you need assistance. -- 690589: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690589 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135036121328788.transcr...@bugs.debian.org
Bug#674445: marked as done (RFS: ruby-juicer/1.0.16-1 [ITP])
Your message dated Tue, 16 Oct 2012 04:20:12 + with message-id e1tnydy-0008m7...@quantz.debian.org and subject line closing RFS: ruby-juicer/1.0.16-1 [ITP] has caused the Debian Bug report #674445, regarding RFS: ruby-juicer/1.0.16-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 674445: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674445 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package ruby-juicer * Package name: ruby-juicer Version : 1.0.16-1 Upstream Author : Christian Johansen * URL : http://github.com/cjohansen/juicer/tree/master * License : MIT (Expat) Section : ruby It builds those binary packages: ruby-juicer - Command line tool for CSS and JavaScript developers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/ruby-juicer Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/ruby-juicer/ruby-juicer_1.0.16-1.dsc More information about hello can be obtained from http://www.example.com. Changes since the last upload: * Initial release (Closes: #641973) Regards, Jean Parpaillon signature.asc Description: This is a digitally signed message part ---End Message--- ---BeginMessage--- Package ruby-juicer has been removed from mentors.---End Message---
Processed: RFS: libdigest-md6-perl/0.11-1 [ITP]
Processing commands for cont...@bugs.debian.org: severity 690589 wishlist Bug #690589 [sponsorship-requests] RFS: libdigest-md6-perl/0.11-1 [ITP] Severity set to 'wishlist' from 'normal' End of message, stopping processing here. Please contact me if you need assistance. -- 690589: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690589 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.135036121328791.transcr...@bugs.debian.org
Bug#683184: RFS: suckless-tools/39-1 [ITA]
On Tue, Oct 16, 2012 at 2:58 AM, Jakub Wilk jw...@debian.org wrote:
Indeed, it looks okay now.
Why are there 2 newlines between the paragraphs in debian/control? It's not
clear to me whether this is compliant with Policy §5.1 (though admittedly
both dpkg and debhelper parsers are happy about it). Could you remove the
extra newline?
Well I guess I introduced it while patching from my already finished
work! Let me fix it tonight
--
Vasudev Kamath
http://copyninja.info
copyninja@{frndk.de|vasudev.homelinux.net}
--
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/cak+nopumyhhdkyagi-qbw75xrcjws7p48h2autdnatkmboa...@mail.gmail.com
