Re: doc-base for more than one document
Le Fri, Jun 19, 2015 at 04:26:58PM +0200, Ole Streicher a écrit : > > I am a bit confused on how I can register more than one document for one > package. Hi Ole, one file per document; see the emboss package for instance. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- 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/20150620062414.gc19...@falafel.plessy.net
Re: packaging Advanced Gtk+ Sequencer - automatic debian build
On Fri, Jun 19, 2015 at 09:30:25PM +0200, Joël Krähemann wrote: > https://mentors.debian.net/package/ags Even mentors shows a lot of lintian-detected problems. -- WBR, wRAR signature.asc Description: Digital signature
Re: packaging Advanced Gtk+ Sequencer - automatic debian build
Hi all Related to: https://mentors.debian.net/package/ags http://anonscm.debian.org/cgit/pkg-multimedia/gsequencer.git What I'm basically doing to upload to debian, please give any advice to improve. joel@debain:~/gsequencer.github$ make distcheck joel@debain:~/gsequencer.github$ cp ags-0.4.2-69.tar.gz ../ags_0.4.2-69.orig.tar.gz joel@debain:~/gsequencer.github$ cd ../gsequencer.alioth joel@debain:~/gsequencer.alioth$ gbp import-orig ../ags_0.4.2-69.orig.tar.gz joel@debain:~/gsequencer.github$ git checkout pristine-tar joel@debain:~/gsequencer.github$ pristine-tar commit ../ags_0.4.2-69.orig.tar.gz joel@debain:~/gsequencer.github$ git checkout master joel@debain:~/gsequencer.github$ emacs -nw debian/changelog joel@debain:~/gsequencer.github$ git add debian/changelog joel@debain:~/gsequencer.github$ git commit -m "updated changelog" joel@debain:~/gsequencer.github$ gbp buildpack joel@debain:~/gsequencer.github$ lintian ../gsequencer_0.4.2-69-1_amd64.deb joel@debain:~/gsequencer.github$ git clean -d -x -f joel@debain:~/gsequencer.github$ gbp buildpackage --git-pristine-tar joel@debain:~/gsequencer.github$ git clean -d -x -f joel@debain:~/gsequencer.github$ git push --all joel@debain:~/gsequencer.github$ git push --tags joel@debain:~/gsequencer.github$ dput mentors ../ags_0.4.2-69-1_amd64.changes cheers, Joël Krähemann On Thu, Jun 18, 2015 at 5:24 PM, Ross Gammon wrote: > Hi Joël, > > On 06/16/2015 04:28 PM, Joël Krähemann wrote: > > Hi, could someone please take a look at my repository: > > > > http://anonscm.debian.org/cgit/pkg-multimedia/gsequencer.git > > I am also a member of the multimedia team and have seen your commits > rolling in. You are getting close to having something ready for > sponsorship. But on a quick (not complete check) there is still some > work to do (see below). > > > Please tell me what I have to do that it gets processed by the automatic > > debian build system. Further what is still left to do so. > > Coming to the mentors list was a very good idea. There are many > experienced guys here that can help out. > The best thing to do next is to prove you can build your package by > uploading the built package to the mentors website. The website will > also tell any reviewer whether you have fixed all the relevant lintian > errors. See here for information: > https://mentors.debian.net/intro-maintainers > > > Note there aren't any signed tags, yet. Should I rebase and add tags for > > old commits? > > Normal practise is to sign a tag when you import the upstream release. > Then when the package is uploaded to the debian archive, there should be > a signed tag for the last commit before the upload. > There is information on tagging specific to the multimedia team here: > https://wiki.debian.org/DebianMultimedia/DevelopPackaging > > > best regards > > Joël Krähemann > > > > Now for some comments: > debian/changelog - Your changelog entry looks a little unfinished. It > should close your ITP bug, and as it is a new package it really only > needs one entry which is something like: > * Initial release (Closes: #) > > debian/copyright - You only list the copyright for files in the debian > directory. You should also list the copyright for the upstream source code. > > debian/debhelper.log - This file is the resulting log from a previous > build of the package to help with troubleshooting. It should be deleted. > > debian/rules - You should remove all the unnecessary commenting. It is > normally okay to leave the "verbose" option commented out so that it can > be quickly added in when you are troubleshooting. > > Some references that you might want to read (again?): > https://www.debian.org/doc/manuals/maint-guide/index.en.html > https://wiki.debian.org/UpstreamGuide (* as I know you are also upstream). > > Keep going! > > Cheers, > > Ross > >
Bug#788583: RFS: blktool -- tune low-level block device parameters [ITA]
On Sat, Jun 13, 2015 at 10:22:31AM +0300, Azat Khuzhin wrote: > On Sat, Jun 13, 2015 at 10:52:02AM +0800, Paul Wise wrote: > Hi Paul, > > Thanks for pointing out, fixed and uploaded to mentors. > > See https://mentors.debian.net/package/blktool > > Changes since he last upload: > > * Drop "QA upload" from changelog Any news on this one? Thanks, Azat. -- 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/20150619184909.GK21004@azat
Re: BOOST_WAVE_SUPPORT_MS_EXTENSIONS flag troubles for vera++
* Vincent Hobeïka , 2015-06-19, 16:20: I am facing some troubles regarding boost wave and my package vera++. It has been decided upstream to recompile boost wave with vera++ in order to activate the BOOST_WAVE_SUPPORT_MS_EXTENSIONS cxx flag so vera++ would be able to parse specific windows identifiers (__stdcall, __declspec, …). See issue #58¹. [...] I have checked the bts if any demands regarding the BOOST_WAVE_SUPPORT_MS_EXTENSIONS compilation flag for boost wave have been asked in the past and could not find anything. Is there anything in Debian which could prevent the activation of this flag? Maybe this question should be directly asked in a bug report to libboostwave-dev? Yeah, just file a wishlist bug and see what happens. :-) -- Jakub Wilk -- 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/20150619143932.ga5...@jwilk.net
doc-base for more than one document
Hi, I am a bit confused on how I can register more than one document for one package. If I just append the whole content of the second document, lintian complains that "Document:" should be the first line. Also the documentation of the doc-base mentiones that there should be exactly one main section. In my case upstream has decided to write several PDF documents -- is there any way to get them registered? Best regards Ole -- 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/87si9nai4t@debian.org
BOOST_WAVE_SUPPORT_MS_EXTENSIONS flag troubles for vera++
Dear mentors, I am facing some troubles regarding boost wave and my package vera++. It has been decided upstream to recompile boost wave with vera++ in order to activate the BOOST_WAVE_SUPPORT_MS_EXTENSIONS cxx flag so vera++ would be able to parse specific windows identifiers (__stdcall, __declspec, …). See issue #58¹. It is indeed nice for vera++ to be able to parse those identifiers correctly so a Debian server checking source files from windows developers would correctly report errors related to these tokens. For instance there are users of vera++ who runs a svn hook which refuses commits of source files with bad coding style. Now I have two choices. Either I remove the ability for vera++ to deal with these tokens on Debian and tell vera++ to use boost wave as shipped by Debian, or I ask the boost maintainers to add the BOOST_WAVE_SUPPORT_MS_EXTENSIONS flag for the compilation of boost wave. In the case I remove the functionality from vera++, maybe I could add a specific README.Debian file to tell users about this known issue. Yet shipping a degraded version of vera++ is kind of sad for Debian. What would be the best practice here? I have checked the bts if any demands regarding the BOOST_WAVE_SUPPORT_MS_EXTENSIONS compilation flag for boost wave have been asked in the past and could not find anything. Is there anything in Debian which could prevent the activation of this flag? Maybe this question should be directly asked in a bug report to libboostwave-dev? Thanks in advance for your kind help regarding this issue. Best regards, [1]: https://bitbucket.org/verateam/vera/issue/58/msext-token-with-different-type-between -- Vincent Hobeïka signature.asc Description: PGP signature
Re: blocked migration from unstable to testing: old binaries left
Hi Again: On 19/06/15 14:52, Jerome BENOIT wrote: > Hi: > > On 19/06/15 08:07, Niels Thykier wrote: >> On 2015-06-19 02:48, Jerome BENOIT wrote: >>> Hello, >>> >>> thanks for your prompt reply. >>> >>> On 18/06/15 14:55, Paul Wise wrote: On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: > what am I supposed to do for unblocking ? You started a (minor) transition without involving the release team, please read this: https://wiki.debian.org/Teams/ReleaseTeam/Transitions According to the cruft report, the old binaries can't be removed because ovito build-depends on libtachyon-dev. You'll need to convince the ovito maintainers to switch to the new tachyon dev packages. https://ftp-master.debian.org/cruft-report-daily.txt >>> >>> Will a dummy libtachyon-dev package solve the problem ? >>> >>> Thanks, >>> Jerome >>> >>> >> >> Yes, provided it depends on the correct -dev packages. Though it might >> have to go through NEW at this point. >> >> At this junction, it /may/ be easier to just update ovito as it is the >> only affected reverse dependency. > > I have just sent an email to the maintainer in this sense. He is on his way to do so. Thanks, Jerome > > Best wishes, > Jerome > >> >> ~Niels >> >> >> > > -- 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/55841744.4070...@rezozer.net
Re: blocked migration from unstable to testing: old binaries left
Hi: On 19/06/15 08:07, Niels Thykier wrote: > On 2015-06-19 02:48, Jerome BENOIT wrote: >> Hello, >> >> thanks for your prompt reply. >> >> On 18/06/15 14:55, Paul Wise wrote: >>> On Thu, Jun 18, 2015 at 8:22 PM, Jerome BENOIT wrote: >>> what am I supposed to do for unblocking ? >>> >>> You started a (minor) transition without involving the release team, >>> please read this: >>> >>> https://wiki.debian.org/Teams/ReleaseTeam/Transitions >>> >>> According to the cruft report, the old binaries can't be removed >>> because ovito build-depends on libtachyon-dev. You'll need to convince >>> the ovito maintainers to switch to the new tachyon dev packages. >>> >>> https://ftp-master.debian.org/cruft-report-daily.txt >>> >> >> Will a dummy libtachyon-dev package solve the problem ? >> >> Thanks, >> Jerome >> >> > > Yes, provided it depends on the correct -dev packages. Though it might > have to go through NEW at this point. > > At this junction, it /may/ be easier to just update ovito as it is the > only affected reverse dependency. I have just sent an email to the maintainer in this sense. Best wishes, Jerome > > ~Niels > > > -- 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/558410a9.4090...@rezozer.net
Bug#775532: RFS: citeproc-py/0.3.0-1 [ITP] -- Python library for CSL based bibliography processing
The state of the package is: I'm not sure if it's o.k. for it to get accepted into the archive when a DFSG compliant change of the license is declared for the project but the actual file headers state something different. For that I've added a patch which disables the style check over by default for the +dfsg package w/o the RELAX NG schemes which would do it until the files get updated. With that the citeproc just does not warn for faulty custom styles, which is great to have but could be dispensed for a while [1]. I would like to discuss this option with the sponsor, maybe it's possible to push it non +dfsg already which a Comment link to the declaration of the new licensing. Anyway, I've uploaded the latest package to mentors [2]. DS [1] The other citeproc in Debian, the Haskell pandoc-citeproc does not feature the schemes at all: https://packages.debian.org/stretch/all/libghc-pandoc-citeproc-data/filelist [2] http://mentors.debian.net/debian/pool/main/c/citeproc-py/citeproc-py_0.3.0+dfsg-1.dsc -- http://qa.debian.org/developer.php?login=debian%40danielstender.com 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 -- 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/5583d683.2090...@danielstender.com
