Bug#948260: RFS: golang-github-russellhaering-gosaml2/0.3.1-1 [ITP] -- Pure Go implementation of SAML 2.0 (library)
On Thursday, 9 January 2020 3:10:11 AM AEDT Christian Barcenas wrote: > I think the default branch for some reason is set to 'upstream' rather > than 'debian/sid', would it be possible to change that? Gitlab says I > don't have the right permissions: > https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gosa > ml2/-/settings/repository I've changed the default branch and elevated your permissions to "Maintainer" in case you need to make similar changes in the future. I much prefer "master" as a default branch (I'm strongly against DEP-14). > Did you see there is a LICENSE file in the root of the upstream Github > repository? For projects whose only website is a Github repo with a LICENSE > file, is it necessary to add this a comment like this to d/copyright? License is not the same as copyright. Upstream did not include the full text of the license. If you read the full text [1], in the APPENDIX where it explains how to apply the license it says to add a copyright statement that upstream neglected to do. I recommend to follow-up with upstream regarding explicit copyright statement (which is currently missing). [1]: https://opensource.org/licenses/Apache-2.0 -- Regards, Dmitry Smirnov. --- Good luck happens when preparedness meets opportunity. signature.asc Description: This is a digitally signed message part.
Bug#948260: RFS: golang-github-russellhaering-gosaml2/0.3.1-1 [ITP] -- Pure Go implementation of SAML 2.0 (library)
On Monday, 6 January 2020 5:37:16 PM AEDT Christian Barcenas wrote: > Additionally, I need the sponsor to push the packaging from my personal > repo > > https://salsa.debian.org/cb-guest/golang-github-russellhaering-gosaml2 > > to the official go-team repository > > https://salsa.debian.org/go-team/packages/golang-github-russellhaering-gos > aml2 I gave you "developer" access to the team repository. Could you please try to push there? Everything looks good but it would be great if you could add comment (to "copyright" file) regarding source of information about upstream copyright as I could not find copyright statement anywhere. Thanks. -- Regards, Dmitry Smirnov. --- No person, no idea, and no religion deserves to be illegal to insult, not even the Church of Emacs. -- Richard Stallman signature.asc Description: This is a digitally signed message part.
Bug#847350: RFS: golang-github-minio-minio-go/2.0.2+dfsg-1
On Monday, 12 December 2016 11:09:56 AM AEDT Félix Sipma wrote: > From gbp-dch(1): > >--id-length=N > Include N digits of the commit id in the > changelog entry. Default is to not include > any commit ids at all. > > So, that's already the default, right? It could be modified by the user's > global gbp.conf, and it affects the changelog entries, so I set it back to > this. Yes, I don't want commit IDs in changelog so I explicitly state that. I've started doing so after few cases when uploaders introduced needless commit ID noise to changelog. > > Basically it instructs GBP to generate/use tarball and it might be useful > > for "debian"-only master repository layout. > > I thinks that these should be set by the user's global gbp.conf. I also think so. Personally I don't build packages with GBP so I shouldn't care much but this fragment may be important for thouse who don't know how to build package without upstream sources in master. This fragment was introduced after earlier discussion in mail list when someone suggested that repository layout should be compatible with GBP either through "standard" layout or with gbp.conf to allow package build out of the box. > If he > wants to use "export-dir = ../debian-build-area" or anything else, we > shouldn't override this. I agree this is ugly but "export-dir" is important because one can't build package with default settings. It is always easier to change existing settings than try to find which parameter should be added. > Does this address your concerns? Nope. :) But those concerns wasn't really mine as it is all about helping those who build packages with GBP... -- Regards, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Bug#847350: RFS: golang-github-minio-minio-go/2.0.2+dfsg-1
On Wednesday, 7 December 2016 6:52:04 PM AEDT Gianfranco Costamagna wrote: > ...in this case there is no license/copyright issue, at least I can't > see it So we are not discussing a generic issue? This particular package did not have DFSG-repackaging to begin with nor does it need one... :) Fortunately minio-go do not bundle anything... > it is fine now, the whole point was > "please don't repack the tarball as dfsg just to exclude two tests (already > there in the current upload and excluded by debian/clean" I see... All good. I had a glimpse at the package and it looks good except removed content of "gbp.conf" that I'll leave for Félix to fix (if he thinks it necessary). Félix, in "gbp.conf" [dch] id-length= 0 is occasionally useful for "gbp dch". The following fragment is to help building the package with GBP when upstream sources are not merged in "master": overlay = True export-dir = ../build-area/ tarball-dir = ../ Basically it instructs GBP to generate/use tarball and it might be useful for "debian"-only master repository layout. Thanks. -- All the best, Dmitry Smirnov. --- The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#847350: RFS: golang-github-minio-minio-go/2.0.2+dfsg-1
On Wednesday, 7 December 2016 6:02:33 PM AEDT Gianfranco Costamagna wrote: > repacking to drop bundled dependencies is sometimes called ds (Debian > Source) repack, non dfsg (even if nobody ever wrote some documentation for > this). I think "ds" is quite confusing let alone that it matches my initials. ;) IMHO DFSG-repacking fits all cases even when we throw away useless files to avoid documenting their copyrights. Often you just don't know whether excluded content is DFSG compliant or not. And since removing bundled libraries is policy compliance I believe DFSG is the appropriate suffix to use in repacked tarballs. > If you prefer a dfsg tarball, it is fine for me, > but I don't get why you > used debian/clean to remove such files, I thought "debian/clean" is an unrelated issue... What about "debian/clean"? I sometimes remove 3rd party dependencies from "debian/clean" as well (not in this package as I recall). You may say it is redundant but actually it is useful if/when you re-build from non-repacked tarball or checkout of upstream repository. Here I think "debian/clean" was used merely to drop some tests (instead of patching 'em which would be more difficult). > and now you want a source repack. Only if there are bundled 3rd party libraries. Repacking is very common for Golang packages -- even dh-make-golang does that by default and it does not indicate that something was thrown away neither by adding "ds" nor "dfsg" to version... > Not sure if I got it correctly, but the removal of the tests has nothing > to do with bundled dependencies, but more a "remove tests that we can't > run on Debian infrastructure". Correct. > Can you please explain again your point? > I admit I worked only a little on golang-* packages, and I would like to > learn something more :) I'm sorry I think I've lost the context... Could you please ask your question again and I'll do my best to explain. > (btw feel free to cancel/reschedule, or tell me what to do with this > upload) Thank for your help, Gianfranco. I did not have a chance to look at the current state of the package yet. I'll see if I can have a look later today. -- All the best, Dmitry Smirnov. --- Good luck happens when preparedness meets opportunity. signature.asc Description: This is a digitally signed message part.
Bug#847350: RFS: golang-github-minio-minio-go/2.0.2+dfsg-1
On Wednesday, 7 December 2016 2:13:08 PM AEDT Gianfranco Costamagna wrote: > what is the reason for the repack? non-dfsg files? > if it is just to skip some tests, I really prefer a debian/clean target, > and not a repack of the whole source tarball. > diverging from upstream tarballs has a lot of useless complications that > should be avoided whenever possible > > as a general rule I like repacks when: > 1) non-dfsg files might be left out > 2) heavy and useless files are kept in the tarball (e.g. binaries, windows > files, or prebuilt stuff) > > in the other cases, I never found a good reason for a repack. > > Other people might disagree, just I found none documentation about the > reasons for this repack. I believe that should be fairly obvious that we repack to drop all bundled dependencies. That's Golang for you where it is common to incorporate all dependency libraries into tarball. Throwing away private copies of those libraries is important to avoid using 'em accidentally, reduce burden and also to avoid tedious copyright review and documentation. -- Cheers, Dmitry Smirnov. --- The more false we destroy the more room there will be for the true. -- Robert G. Ingersoll, 1902 signature.asc Description: This is a digitally signed message part.
Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system
On Monday, 23 May 2016 9:08:20 AM AEST Mattia Rizzolo wrote: > Did anything happened here in the past 4+ months? Not much from packaging prospective. Upstream however show some signs of improvement as they've started using GitHub: https://github.com/moosefs/moosefs > Dmitry setted the moreinfo tag (as this indeed need(ed) work), but I > anyway can't understand if he is an available sponsor for this. I'm still busy so I can't make any promises regarding sponsorship. However I am probably the best person to review packaging... As far as I'm aware they've never attempted to improve packaging so I doubt they can maintain it properly... Last time I checked upstream packaging was too sloppy for upload. I still have some concerns regarding inferior licensing [1] and I believe that MooseFS is redundant when we already have LizardFS. I'm not against having alternative storage system which may have benefits like availability of different MySQL/MariaDB flavours... [1]: https://github.com/moosefs/moosefs/issues/5 -- Cheers, Dmitry Smirnov. --- Journalism is printing what someone else does not want printed: everything else is public relations. -- George Orwell signature.asc Description: This is a digitally signed message part.
Bug#817281: closed by Dmitry Smirnov <only...@debian.org> (Re: [pkg-go] Bug#817281: RFS: golang-gopkg-hlandau-easyconfig.v1/1.0.13 [ITP] -- Go package with easy bindings for configurable)
On Saturday, 2 April 2016 11:37:47 PM AEST Peter Colberg wrote: > Could you push the release tag to the git repository? Did I forget to push? It should be OK now. -- Best wishes, Dmitry Smirnov. --- The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought. -- John F Kennedy signature.asc Description: This is a digitally signed message part.
Bug#817283: RFS: golang-gopkg-hlandau-service.v2/2.0.15 [ITP] -- Go package for writing services
On Monday, 28 March 2016 10:38:48 PM AEDT Peter Colberg wrote: > I pushed commit be569f2, which adds a Comment linking to the license text. Thanks, this is helpful. I'll upload when all dependencies will become available. Also I prefer "unstable" instead of "UNRELEASED" in changelogs of packages seeking sponsorship -- one little thing less to do for your sponsor. ;) -- Best wishes, Dmitry Smirnov. --- "All government, of course, is against liberty. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#817218: [pkg-go] Bug#817218: RFS: golang-github-hlandau-xlog/0.0~git20160208.0.c18de57 -- logging library for Go
On Wednesday, 9 March 2016 12:39:27 AM AEDT Peter Colberg wrote: > I am looking for a sponsor for the package "golang-github-hlandau-xlog": Uploaded, thank you. :) -- Cheers, Dmitry Smirnov. --- If any remedy is tested under controlled scientific conditions and proved to be effective, it will cease to be alternative and will simply become medicine. So-called alternative medicine either hasn't been tested or it has failed its tests. -- Richard Dawkins, 2007 signature.asc Description: This is a digitally signed message part.
Bug#817215: [pkg-go] Bug#817215: RFS: golang-github-alecthomas-template/0.0~git20151201.0.14fd436 -- text templates with newline elision for Go
On Sunday, 27 March 2016 11:20:45 PM AEDT Peter Colberg wrote: > Unless you suggest otherwise, I can package a preliminary version of > gopkg.in/alecthomas/kingpin.v3 and patch acmetool to use the Go 1.6 > template syntax. I think it seems reasonable as it would let us to drop obsolete dependency. Though I'd really like to convince upstream to tag/release v3. > Please see the Comment in debian/copyright, which links to the source > of the template package that is licensed under a BSD-3-clause license: > > https://golang.org/LICENSE I've noticed that and thanks for leaving a comment. :) However I believe this is still insufficient as you are not getting this package directly from Go Authors and author of changes did not confirm the license... It would be reasonable to assume that he did not change the license but we need to know for sure and there is nothing in the modified package that refer to text of BSD-3-Clause license... -- Regards, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Bug#817215: [pkg-go] Bug#817215: RFS: golang-github-alecthomas-template/0.0~git20151201.0.14fd436 -- text templates with newline elision for Go
Hi Peter, On Wednesday, 9 March 2016 12:24:19 AM AEDT Peter Colberg wrote: > I am looking for a sponsor for the package > "golang-github-alecthomas-template": Upstream does not have a license and commented the following: "as Go 1.6 now supports whitespace elision [1], I won't be making any further changes to this package and will probably delete it soon." [2] Is this package really needed? Please investigate. Meanwhile I'm tagging this bug as "wontfix" for now. Also please note that "BSD-style license" is not necessary the same as "BSD-3-clause". You can't make such assumption because there are too many "BSD style" licenses so techically speaking it can be any of them (and not limited to the list): https://fedoraproject.org/wiki/Licensing:BSD [1]: https://golang.org/pkg/text/template/#hdr-Text_and_spaces [2]: https://github.com/alecthomas/template/issues/3#issuecomment-188537775 -- Cheers, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Bug#817829: [pkg-go] Bug#817829: RFS: golang-github-cheggaaa-pb/0.0~git20160304.0.a75ad33 [ITP] -- simple console progress bar for Go
On Saturday, 19 March 2016 12:54:06 AM AEDT Peter Colberg wrote: > Could you revert Debian commit 5699dec to restore the empty watch file > and upload a second version? Otherwise the above tag would permanently > show on tracker.debian.org, despite the package being up to date. Don't you worry about that. Upstream kindly tagged new releases https://github.com/cheggaaa/pb/releases so "watch" file is useful now. -- Regards, Dmitry Smirnov. --- A casual stroll through the lunatic asylum shows that faith does not prove anything. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#817226: [pkg-go] Bug#817226: RFS: golang-gopkg-hlandau-svcutils.v1/1.0.7 -- utilities for writing services in Go
On Wednesday, 9 March 2016 1:10:27 AM AEDT Peter Colberg wrote: > I am looking for a sponsor for the package > "golang-gopkg-hlandau-svcutils.v1": Very good work, Peter. :) I'd like upstream to clarify licensing before we upload: https://github.com/hlandau/svcutils/issues/1 -- All the best, Dmitry Smirnov. --- It is time that we admitted that faith is nothing more than the license religious people give one another to keep believing when reasons fail. -- Sam Harris signature.asc Description: This is a digitally signed message part.
Bug#817865: RFS: acmetool/0.0.49 [ITP] -- automatic certificate acquisition tool for Let's Encrypt
On Thursday, 17 March 2016 5:07:39 PM AEDT Peter Colberg wrote: > Seeing that you have sponsored an impressive number of golang-* > packages, would you be willing to sponsor the initial upload of > acmetool [1] and its dependencies? I'd love to but I have to prioritise so unfortunately I won't be able to allocate time to look into this for a while... I'll keep that in mind and I might come back to you eventually but please don't count on my help as I simply have no time now... Sorry. I think you are working on important software and it would be great to introduce it to Debian. Thank you for your help and hard work. -- Cheers, Dmitry Smirnov. --- Reality is that which, when you stop believing in it, doesn't go away. -- Philip K. Dick signature.asc Description: This is a digitally signed message part.
Bug#817829: [pkg-go] Bug#817829: RFS: golang-github-cheggaaa-pb/0.0~git20160304.0.a75ad33 [ITP] -- simple console progress bar for Go
On Saturday, 19 March 2016 12:54:06 AM AEDT Peter Colberg wrote: > Now this stray tag shows up in uscan: > > uscan: Newest version of golang-github-cheggaaa-pb on remote site is 1.0, > local version is 0.0~git20160304.0.a75ad33 uscan:=> Newer package > available from > https://github.com/cheggaaa/pb/archive/go1.0.tar.gz > > Could you revert Debian commit 5699dec to restore the empty watch file > and upload a second version? Otherwise the above tag would permanently > show on tracker.debian.org, despite the package being up to date. I'll leave this with you. Please remember that package is already uploaded with this change. Perhaps we could give upstream some time to respond to bug before deciding whether to keep this change or not. -- All the best, Dmitry Smirnov. --- All that is necessary for the triumph of evil is that good men do nothing. signature.asc Description: This is a digitally signed message part.
Bug#817829: [pkg-go] Bug#817829: RFS: golang-github-cheggaaa-pb/0.0~git20160304.0.a75ad33 [ITP] -- simple console progress bar for Go
On Saturday, 19 March 2016 12:47:12 AM AEDT Peter Colberg wrote: > The tag in question is 'go1.0', which points to commit e8c7cc5 from > Dec 2, 2014. This does not look like a proper release tag, rather > an internal tag for an old commit that works with Go version 1.0. > > I added a watch file only for Go packages that are published on > gopkg.in/, which is a good indication that the author is familiar > with proper versioning and regularly tags new versions. > > For other Go packages I used git snapshots. I did see the occasional > single tag for these, but again outdated and not indicative of regular > releases. Therefore I think it’s best to ignore these stray tags. I see, thank you. Alternatively we can bug upstream in order to convince him to tag properly... Please feel free to disable my watch file if you think it is not useful... -- Best wishes, Dmitry Smirnov. --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Bug#817829: [pkg-go] Bug#817829: RFS: golang-github-cheggaaa-pb/0.0~git20160304.0.a75ad33 [ITP] -- simple console progress bar for Go
Hi Peter, On Thursday, 10 March 2016 12:58:32 PM AEDT Peter Colberg wrote: > I am looking for a sponsor for the package "golang-github-cheggaaa-pb": I've uploaded with only one correction: I've added "watch" file to check for upstream releases. Apparently there is one new tag/release made 10 days ago. Tagged version is quite different from yours -- please check with upstream if necessary. I've also reported the following bug: https://github.com/cheggaaa/pb/issues/73 Thank you for your work. -- Cheers, Dmitry Smirnov. --- Faith: not wanting to know what the truth is. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system
On Mon, 18 Jan 2016 07:23:30 AM Jakub Kruszona-Zawadzki wrote: > On 15 Jan, 2016, at 15:10, Dmitry Smirnov <only...@debian.org> wrote: > > I had a glimpse at the packaging in the source archive 3.0.69 and I think > > it needs much more work before it could be uploaded (let alone my > > objections against introducing MooseFS to Debian). There are too many > > issues to list... > Could you enlight me? 'debian' folder looks almost the same in MooseFS and > LizardFS. What issues are you talking about? Some examples? Please note that official Debian packaging is quite different from what you can find in upstream repository. LizardFS team is not competent with packaging and they barely touched it as far as I recall. Obvious way to improve packaging would be to address Lintian warnings, introduce support for Systemd etc. Sorry I don't have time for in-depth review and at the moment I have no intention to sponsor MooseFS... > Believe me or not, but we are very open to change some things in MooseFS. > As you maybe know we change licence of open source version to GPL and made > it freely available, so we always try to adapt to community necessities. That is very nice indeed. Thank you. -- Regards, Dmitry Smirnov. --- Success consists of going from failure to failure without loss of enthusiasm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system
On Tue, 12 Jan 2016 09:52:21 PM Piotr Robert Konopelko wrote: > I am looking for a sponsor for our team's package - MooseFS I had a glimpse at the packaging in the source archive 3.0.69 and I think it needs much more work before it could be uploaded (let alone my objections against introducing MooseFS to Debian). There are too many issues to list... -- All the best, Dmitry Smirnov. --- However beautiful the strategy, you should occasionally look at the results. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system
On Tue, 12 Jan 2016 11:52:17 PM Piotr Robert Konopelko wrote: > Of course I think MooseFS is better, I'd much appreciate if you could elaborate on details how MooseFS is better. I could not find anything to support that claim. > Apart this I don't think, that LizardFS maintainer would "replace" > LizardFS with MooseFS. That is correct. However I would replace MooseFS with LizardFS without hesitation. -- Best wishes, Dmitry Smirnov. --- You have to start with the truth. The truth is the only way that we can get anywhere. Because any decision-making that is based upon lies or ignorance can't lead to a good conclusion. -- Julian Assange, 2010 signature.asc Description: This is a digitally signed message part.
Re: Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system
On Tue, 12 Jan 2016 10:44:16 PM Marco d'Itri wrote: > On Jan 12, Piotr Robert Konopelko <piotr.konope...@moosefs.com> wrote: > > If you loose Master Server, user action is needed: he can run another > > Master Server e.g. basing on medatada collected on Metalogger (sometadata > > is *not* lost) or "repair" broken Master Server. > > In other words, the system is not highly available. In LizardFS master (i.e. metadata) server is not shipped with built-in HA. However master daemons are ready for failover -- in case of master server failure one just needs to take over master's IP address and reload shadow master configuration to promote it to authoritative master. Failover takes only few seconds at most. It can be implemented with ucarp, corosync, etc. using trivial (or not so trivial) scripts. Proper built-in HA is on the LizardFS roadmap. I suppose MooseFS might be using similar failover mechanism which leaves particularities of HA implementation to sysadmin. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Truth — Something somehow discreditable to someone. -- H. L. Mencken, 1949 signature.asc Description: This is a digitally signed message part.
Re: Bug#810822: ITP: MooseFS
On Tue, 12 Jan 2016 04:27:06 PM Piotr Robert Konopelko wrote: > We're already publishing own packages repository > (https://moosefs.com/download/ubuntudebian.html > <https://moosefs.com/download/ubuntudebian.html>). We would like to make > MooseFS available directly in Debian! :) In November 2014 when I was working on introducing LizardFS (a fork of MooseFS) to Debian, there were no publicly available source code for MooseFS -- no tarballs or source code repository. Later it became possible to request MooseFS sources by filling web form and hoping that sources will be sent over email. Even though now MooseFS sources can be freely downloaded there are no public bug tracker and no public VCS. Lack of VCS means one can not isolate (and backport) fixes without great difficulties. Moreover only crippled "community edition" of MooseFS is free software as MooseFS developers apparently focused on proprietary "PRO" edition. Debian already have MooseFS' fork -- LizardFS. To my knowledge at the moment MooseFS do not offer noticeable advantages over LizardFS while the latter seems to have slightly more features. For quite a while LizardFS is developed with community using public VCS and bug tracker (GitHub) as well as Gerrit code review system and continuous integration system. LizardFS have more development transparency than MooseFS ever had. I believe that poor governance of MooseFS motivated forking and it appears that MooseFS developers still did not learn their lesson. *** Based on the above I recommend to refrain from introducing MooseFS to Debian. *** Please note that IMHO MooseFS versus LizardFS situation have many similarities with MySQL vs. MariaDB situation where poor Oracle's governance and focus on proprietary addons discourage community from working with them. (MySQL is not as bad as MooseFS because MySQL have public bug tracker). As I object to introduction of MooseFS to Debian I would object to introduction of MySQL if MariaDB were already available. Having both is a burden and non-negligible overhead. With all due respect to MooseFS's former innovations and legacy I think for now it would be best to refrain from debianising MooseFS and re-evaluate situation in the future if there will be any development. -- Cheers, Dmitry Smirnov. --- We often refuse to accept an idea merely because the way in which it has been expressed is unsympathetic to us. -- Friedrich Nietzsche signature.asc Description: This is a digitally signed message part.
Bug#789712: RFS: pylint-celery/0.3-1 [ITP]
Hi Daniel, On Tue, 23 Jun 2015 20:20:34 Daniel Stender wrote: I'm seeking for an uploader resp. sponsor of my package of pylint-celery I'm not sure if I'll be able to sponsor your package but I had a quick look and spotted a problem in packaging: it is incorrect to override DEB_BUILD_OPTIONS from debian/rules. DEB_BUILD_OPTIONS should be available to whoever builds your package to override default behaviour (for example disable tests, etc.). Correct way to disable tests is by using override_dh_auto_test where you can invoke -dh_auto_test (that's right, with minus character) to run tests but continue on their failures. If some tests are meaningful it might be useful to run them in order to capture tests output in build logs. Also I believe the correct name of the license is GPL-2 instead of GPL-2.0. Finally I have some doubts whether this tiny plugin is worth exposing system- wide -- if it is only used by Pylint then perhaps it could be installed privately? Isn't that what Python team policy says? -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- Continuous effort - not strength or intelligence - is the key to unlocking our potential. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#784854: MIA for Karolina Kalic karol...@resenje.org
Hi Karolina, On Mon, 18 May 2015 10:58:08 Karolina Kalic wrote: As I can remember, MIA team contacted me a while ago. And I explained that I can not continue my work for Debian at the moment. The packages should have been orphaned properly after that. I don't know what happened. I'm glad that someone wants to continue the work on unico. I don't have any objections. Thanks for your reply. I hope one day you will be able to contribute to Debian again. -- Best wishes, Dmitry Smirnov. --- The more false we destroy the more room there will be for the true. -- Robert G. Ingersoll, 1902 signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi Vincent, On Sun, 17 May 2015 21:36:22 Vincent Cheng wrote: I'd argue that the right approach is still to contact the MIA team and ask them to investigate and reach out to the supposedly missing maintainer. The thing is, either way (MIA team involved, or not) you'd usually want to wait an indeterminate amount of time for the old maintainer to reply before giving up anyways, so you may as well just follow the devref guidelines. The MIA team is fairly active AFAIK, and it's just a matter of sending a brief email to m...@qa.debian.org to get the ball rolling. No objections from me. :) I just wanted to mention another approach to friendly takeover for unmaintained packages... As I recall it was discussed in debian-devel (and/or debian-qa) a while ago and I've seen it in practice. Of course contacting MIA team won't hurt. Thanks for reminding about it. -- Regards, Dmitry Smirnov. --- Success consists of going from failure to failure without loss of enthusiasm. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
Hi James, I'm unable to review your packaging at this time. On Sun, 17 May 2015 17:13:34 James Lu wrote: As for the package truly being orphaned, I assume that the people who filed the report already knew what was going on. No he did not know. #717044 was filed by person who is not a Debian Developer and not even Debian Maintainer. Clearly he is not familiar with orphaning procedure... The LDAP database didn't find anything for Karolina Kalic or karol...@resenje.org, This is expected as she is also not a Debian Developer. Database is only for official members of Debian project and it does not list all contributors. However there is some scarce information here: https://contributors.debian.org/contributor/karolina-guest%40alioth and the package has been orphaned for almost 2 years now. Two of their packages appear to have new maintainers already https://qa.debian.org/developer.php?login=karolina%40resenje.org (curtain and spotlighter). It looks like she did not do anything about critical bug #706330 since 2013-07-17 which IMHO justifies takeover because she is obviously not active or at least appears to be not on top of her maintainer's duties... I would assign ITA bug to the package, express my intention to take over to the bug and to current maintainer, wait for some time and eventually proceed with upload (provided that everything is OK with packaging and there are no objections from maintainer). Either way, I'll Cc them on this conversation now. I'm not sure what has been done already, and what still has to be done. Good. -- Cheers, Dmitry Smirnov. --- Every decent man is ashamed of the government he lives under. -- H. L. Mencken signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
On Sat, 9 May 2015 09:04:39 James Lu wrote: One small note: the tarball was repacked in order to remove the INSTALL symlink, which quilt didn't seem to handle properly (it just reported no files changed). Did you try removing symlink from debian/clean file? Wouldn't it be easier than repacking? What does it have to do with quilt? Thanks. -- Best wishes, Dmitry Smirnov signature.asc Description: This is a digitally signed message part.
Bug#784854: RFS: gtk3-engines-unico/1.0.3+14.04.20140109+repack1-1 [ITA] [RC]
On Sat, 9 May 2015 19:19:22 James Lu wrote: Hi, Did you try removing symlink from debian/clean file? debian/clean? I don't see that mentioned anywhere in the New Maintainers guide https://www.debian.org/doc/manuals/maint-guide/index.en.html. It is a part of debhelper suite. See dh_clean(1). What does it have to do with quilt? I was trying to use a quilt patch to replace the symlink with a copy of the regular file, but that didn't work. I don't know what the regular practice is for situations like this. I did not look into your packaging but why not just ignore symlink and install original file? Or replace symlink from override_dh_install? Repacking orig.tar to drop symlink in unnecessary... -- Cheers, Dmitry Smirnov. --- Not a lack of belief, but adherence to false knowledge is the enemy of progress. And certain that we have found everything worth searching for, we see no point in further search and inquiry. Believing what is unworthy of belief, believing falsehood as if it were incontrovertible truth, and sure that we know everything we will ever need to know, we are worse than ignorant. -- Chester Dolan, Blind Faith signature.asc Description: This is a digitally signed message part.
Bug#781927: RFS: qemuctl - control gui for qemu / 0.3.1-4 [ITA]
Hi Antti, On Sun, 5 Apr 2015 03:05:23 Antti Järvinen wrote: I am looking for a sponsor for package qemuctl Ideally to adopt package you need to change more than just declare yourself as maintainer for first upload. Fix a bug maybe or improve something. Also if you have access to collab-maint it may be better to put packaging repository to our infrastructure. -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B --- The persistence of erroneous beliefs exacerbates the widespread anachronistic failure to recognize the urgent problems that face humanity on this planet. -- Murray Gell-Mann, Quark and the Jaguar signature.asc Description: This is a digitally signed message part.
Bug#781622: RFS: opentyrian/2.1.20130907-1 [ITP]
On Thu, 2 Apr 2015 09:05:50 Etienne Millon wrote: Nice. But I meant to use all those headers (except for Applied-Upstream which I use ocassionally). Oh, I see. I added them. Thanks. Thanks for the heads-up on the new way of repacking. Files-Excluded makes it real easy indeed. If you ever need more advanced repacking (e.g. not just removing files but changing something in the archive) or generating orig.tag from checkout there is a wiki page with samples of how to do that: https://wiki.debian.org/onlyjob/get-orig-source Done, repushed, reuploaded! Awesome, I'll have a look soon. Thanks. -- Best wishes, Dmitry Smirnov. --- Continuous effort - not strength or intelligence - is the key to unlocking our potential. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#781622: RFS: opentyrian/2.1.20130907-1 [ITP]
On Wed, 1 Apr 2015 20:38:30 Dmitry Smirnov wrote: Hmm, how about doing it gnu-make-style? Just kidding, your way is OK, just please pass --mode=644 --preserve-timestamps to install (taking care of reproducible build etc.). Also you can replace `mkdir` with `-D` option to `install`. -- Cheers, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#781622: RFS: opentyrian/2.1.20130907-1 [ITP]
On Wed, 1 Apr 2015 10:19:15 Alexandre Detiste wrote:
I fixed the icon location.
for size in 22 24 32 48 128 ; do \
- mkdir -p usr/share/icons/hicolor/$${size}x$${size}/apps ;\
- install linux/icons/tyrian-$${size}.png
usr/share/icons/hicolor/$${size}x$${size}/apps/opentyrian.png ;\
+ mkdir -p debian/opentyrian/usr/share/icons/hicolor/$${size}x$${size}/apps
;\ + install linux/icons/tyrian-$${size}.png
debian/opentyrian/usr/share/icons/hicolor/$${size}x$${size}/apps/opentyrian.
png ;\
done
Hmm, how about doing it gnu-make-style?
override_dh_auto_build:
$(MAKE) release
ICONS=22 24 32 48 128
.PHONY=$(ICONS)
$(ICONS):
install --verbose --mode=644 --preserve-timestamps -D \
$(CURDIR)/linux/icons/tyrian-$@.png \
$(CURDIR)/debian/opentyrian/usr/share/icons/hicolor/$@x$@/apps/opentyrian.png
override_dh_install: $(ICONS)
dh_install
Please note that in make files make is usually spelled as $(MAKE).
--
Regards,
Dmitry Smirnov.
---
Perhaps is is better to be irresponsible and right, than to be responsible
and wrong.
-- Winston Churchill
signature.asc
Description: This is a digitally signed message part.
Re: Self-maintained Debian packages best practice
On Mon, 1 Dec 2014 10:27:52 Paul Wise wrote: Personally I prefer to separate packaging from upstream development because they are two different things. When I use a VCS for packaging it contains only the debian/ directory. This is how I like to handle Debian packaging in git as well. -- Cheers, Dmitry Smirnov. --- If you travel the earth, you will find it is largely divided into two classes of people - people who say I wonder why such and such is not done and people who say Now who is going to prevent me from doing that thing? -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#781622: RFS: opentyrian/2.1.20130907-1 [ITP]
On Wed, 1 Apr 2015 09:20:34 Etienne Millon wrote:
I refreshed this, forwarded two patches and picked the upstream
version of one.
Nice. But I meant to use all those headers (except for Applied-Upstream which
I use ocassionally).
I'm not too familiar with how icons work, so I've installed them as
/usr/share/icons/hicolor/NxN/apps/opentyrian.png. Is that correct?
Yes it is correct. Thanks for installing all icons nicely.
* Re-distribution of pre-built binary macosx/tyrian.icns in
source archive may be a bit of concern.
It's being removed in the next release:
That's good but let's repack orig.tar to remove this file unless you want to
wait till next release. Ftp-masterd do not like blobs and I'm not sure if they
will be willing to tolerate this particular one. Better not take chances and
not waste their time.
Repacking is easy:
* changelog: change version to 2.1.20130907+dfsg-1
* copyright: add Files-Excluded: macosx/tyrian.icns to top section (under
Source).
* watch: add
opts=repacksuffix=+dfsg,dversionmangle=s{\+dfsg\d*}{} \
before URL.
and get repacked orig.tar using `uscan`.
Speaking about watch file I recommend to extend regex to match other types of
archives, something like
opentyrian-(.*)-src\.tar\.(?:gz|bz2|xz)
Too many times I've seen new releases not noticed because upstream changed tar
compression...
* There is a comma , which is not present in the original copyright
statement after copyright year in
Files: ./src/video_scale_hqNx.c
Copyright: 2003, MaxSt ( ma...@hiend3d.com )
IMHO it should be just 2003, not 2003,.
Other than this debian/copyright looks good.
Indeed, fixed that.
Thanks. I think same issue exists in copyright of Andrea Mazzoleni.
Could you fix it too please?
I'll have a look again once those changes are done and hopefully we'll upload
it.
--
Cheers,
Dmitry Smirnov.
signature.asc
Description: This is a digitally signed message part.
Bug#781622: RFS: opentyrian/2.1.20130907-1 [ITP]
On Tue, 31 Mar 2015 19:35:12 Etienne Millon wrote: I am looking for a sponsor for my package opentyrian That is very nice. I was looking forward to see opentyrian in Debian for a while. Thanks for packaging. I'm happy to hear your remarks about this package. First thing to improve is to add more DEP-3 [1] headers to patches. Specifically the following (missing) headers would be useful: Forwarded Last-Update Origin Applied-Upstream Working with upstream is important part of package maintenance. From looking at patch headers I need to see whether it was Forwarded, when Last-Update happened, where patch was taken from (Origin, if it was borrowed from upstream or from another distro) and sometimes Applied-Upstream status. If you did not forward patches yet I'd recommend to wait no further and document progress as described. Also there are some remarks about packaging: * There should be versioned Depends on game-data-packager which actually support tyrian-data (i.e. tyrian-data | game-data-packager (= 40)). * Package should install icon (there are some in linux/icons). Icon is referenced from installed .desktop file. * Repository do not match package uploaded to Mentors. There are differences in control (Standards-Version) and in README.Debian. * Why not enable full hardening? (e.g. export DEB_BUILD_MAINT_OPTIONS = hardening=+all) * Re-distribution of pre-built binary macosx/tyrian.icns in source archive may be a bit of concern. * There is a comma , which is not present in the original copyright statement after copyright year in Files: ./src/video_scale_hqNx.c Copyright: 2003, MaxSt ( ma...@hiend3d.com ) IMHO it should be just 2003, not 2003,. Other than this debian/copyright looks good. Also, please note that I'm a Debian Maintainer, so once this clears NEW I'm interested in uploading the next revisions myself. Thanks! Great attitude. :) [1]: http://dep.debian.net/deps/dep3/ -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end; there it is. -- Winston Churchill signature.asc Description: This is a digitally signed message part.
Bug#754202: Gamera/3.4.1-1
On Tue, 15 Jul 2014 19:21:35 Jakub Wilk wrote: As the bug says, there is no wxPython 3.0 in Debian yet... True, but the following bug was just filed: transition: wxpython3.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755757 -- Regards, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#754202: Gamera/3.4.1-1
Hi Daniel, I'm not sure if I have enough time to familiarise myself with the package to sponsor it but I had a quick look so here is my feedback and improvement ideas: Although debian/copyright is almost comprehensive it still misses some organisations, notably 2007 INRIA (AKA Dolphin?), 2006 LIFL (AKA OPAC?). Worth to clarify. Besides copyright file feels not very human-readable and therefore it is hard to review. I understand the effort that will be necessary but I still hope that eventually (when convenient) the following improvements can be made: * Sorting (please alphabetise copyright holders) * Padding with spaces (to make lists appears more like tables i.e. add spaces between copyright year and name if necessary to make all names begin from the same column). This will increase readability. * Ideally it will be nice to have contact emails listed as well. Many of them can be harvested from source files. * I prefer to be more precise regarding years of copyright so I would remove trailing commas after copyright years. When year of copyright written like 2007, it may create wrong impression that person is still actively contributing which is not true on many occasions. I believe it is better to write 2007-2011 and never use ambiguous trailing commas. I've noticed that package is not using dh_python2. I do not have enough experience with Python to say whether it is a good or bad thing. I also think that package could use more debhelper functionality. This is not a problem but I'd prefer someone (other than me) who have more Python experience to review and upload. Hopefully someone from Python team could help? Gamera_gui exposes its modules globally which may be unnecessary. I understand that according to Python policy it is desirable to install application's modules privately. In that sense python-gamera obviously should be exposed in global name space but gamera-gui may be better to hide its modules. `cme check dpkg-control` (from libconfig-model-dpkg-perl) reported unnecessary versioned dependencies. This is the opportunity to clean debian/control. Finally my biggest concern is new dependency on wxwidgets2.8. There is on-going transition to wxwidgets3.0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748169 So if I understand situation properly your package will be blocking this transition (if uploaded as is) and therefore it will be affected by yet-to-be- filed serious bug. IMHO it will be ideal to migrate to wxwidgets3.0 before upload. -- Regards, Dmitry Smirnov. signature.asc Description: This is a digitally signed message part.
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
Hi Neutron, On Sat, 14 Dec 2013 05:30:51 Neutron Soutmun wrote: I am looking for a sponsor for my package slowhttptest Nice, thank you for your work. :) I hope you'll forgive me for pedantic nitpicking but let's fix the following minor issues before we upload: * Standards 3.9.4 (expected current version 3.9.5). * Needless versioned Build-Depends on debhelper (this exact version is in stable). Besides is there are any features of this particular version is in use? * Short package description starts with capital letter (lowercase would be better). Thanks. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B signature.asc Description: This is a digitally signed message part.
Bug#732084: RFS: slowhttptest/1.6-1 [ITP] -- Application layer Denial of Service attacks simulation tool
On Sun, 15 Dec 2013 14:38:48 Prach Pongpanich wrote: It's missing '/gitweb' in Vcs-Browser field. Yeah, well spotted, it is a broken URL indeed. It should be Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/slowhttptest.git -- All the best, Dmitry Smirnov. -- 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/201312151525.54198.only...@debian.org
Re: Gitorious and debian/watch file
On Tue, 26 Nov 2013 07:38:22 Bart Martens wrote: I suggest to use this : | version=3 | opts=filenamemangle=s/\S*download=//g \ | http://qa.debian.org/cgi-bin/fakeupstream.cgi?upstream=gitorious/osm-c-tools/osmctools \ | .*=osmctools(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz) Thanks Bart, it works perfectly. I owe you for this advise. -- Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- 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/201311272113.34714.only...@debian.org
Bug#714947: RFS: djvusmooth/0.2.14-1 -- graphical editor for DjVu
On Fri, 5 Jul 2013 21:02:40 Daniel Stender wrote: Removed the unecessary deps. Great pointer to cme! Thanks. :) Sorry but I have to ask you to correct corresponding changelog entry: + removed unnecessary deps (python-all, djvulibre-bin, python-djvu). Clearly it says that you dropped three packages from depends while you merely removed obsolete versioning... Could you re-phrase it please? That's my only concern -- otherwise I'm ready to upload. Also latest changes not yet committed to repository, right? All the best, Dmitry Smirnov GPG key : 4096R/53968D1B -- 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/201307052337.34265.only...@member.fsf.org
Bug#714947: RFS: djvusmooth/0.2.14-1 -- graphical editor for DjVu
Hi Daniel, I found only few pedantic issues... :) `cme check dpkg-control` report the following unnecessary versioned dependencies: * python-all (= 2.6.6-3~) Debian has squeeze - 2.6.6-3+squeeze7; wheezy - 2.7.3-4; jessie - 2.7.5-2; sid - 2.7.5-2; * djvulibre-bin (= 3.5.20-5~) Debian has squeeze - 3.5.23-3; wheezy - 3.5.25.3-1; jessie - 3.5.25.3-3; sid - 3.5.25.4-1; * python-djvu (= 0.1.15) Debian has squeeze - 0.1.18-2; wheezy - 0.3.9-1; jessie - 0.3.9-1; sid - 0.3.9-1; sid - 0.3.9-1+b1; This time let's remove them before upload please. On Fri, 5 Jul 2013 01:08:20 Daniel Stender wrote: * Bumped Debhelper level to 8 (deb/control and compat). Why only to level 8? Current recommended level is 9 and even if you're backporting to squeeze-backports debhelper 9 is there. Any particular reason to stay on compat=8? I know Arch:all packages benefit little from upgrade from dh-8 to dh-9 but personally I would upgrade for the sake of staying up-to-date. IMHO there are less caveats if you maintain all/most of your packages in same DH compatibility level... Another improvement idea might be to use upstream .desktop file from extra/. There are few differences from .desktop file in debian/ and perhaps they could be merged with patch. Usually it is better to use upstream files when possible as it help to track changes and share our improvements as well as reduce duplication. Please advise if you want to address any of the above issues before upload. Thanks. Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B -- 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/201307050806.30878.only...@member.fsf.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
Hi Daniel, One more thing: please install desktop icon. At the moment it is mentioned in .desktop file but not yet shipped by the package. Regards, Dmitry. -- 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/201306202004.26028.only...@member.fsf.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
On Tue, 18 Jun 2013 23:15:23 Mathieu Malaterre wrote: Technically RelWithDebInfo should not be used anymore with cmake from sid: http://lists.debian.org/debian-devel/2013/06/msg00278.html It now appends -DNDEBUG ... see #701231 for more info Interesting, thanks for this information. I'm just wondering if should not is a little bit too strong to express new recommended practice... If package builds according to expectations with RelWithDebInfo then perhaps it might be safe to keep as is... Best wishes, Dmitry Smirnov. --- Good luck happens when preparedness meets opportunity. -- 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/201306191946.04651.only...@debian.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
On Wed, 19 Jun 2013 03:25:05 Daniel Stender wrote: 1) buildflags.patch / build type First of all, the patch works fine. Actually, after removing the forced variable overrides Cmake recognizes already the standard environment build flags. Great, thanks for checking. :) I've came across that Debhelper 20130504 was set to always switch to RelWithDebInfo build type (#701233), which yes puts -DNDEBUG into building on current Sid (Debhelper 20130605) - are there different opinions on that issue? It is great than debhelper became better with cmake. From my past experience with cmake I might be a bit traumatised by weird upstream scripts that strip executables in Release mode. However explicitly passing build type may be advantages in some cases. It does not hide logic and allows to set proper corresponding CMAKE variables that are specific to build type. Concerning backportability it would be even preferable to explicitly set build type to produce reliable and predictable build results. For scantailor I have no preference and leave decision to maintainer. 2) hardening of scantailor-cli As another issue remains that scantailor-cli still doesn't got fortified: $ hardening-check scantailor-cli As far as I'm aware `hardening-check` might produce incorrect results. When I check build logs with `blhc` it prints no warnings whatsoever which is an evidence that all executables compiled will hardening flags so IMHO we're all good here. Here is another minor improvement suggestion: there are some unnecessary versioned build-dependencies on * cmake (= 2.6.0): oldest is 2.8.2+dfsg.1-0+squeeze1 * libqt4-dev (= 4.4.0): oldest is 4:4.6.3-4+squeeze1 Also I'd set source archive and .DEB files compression to xz: Source compression can be set in debian/source/options by adding compression = xz .DEB file compression can be set in debian/rules by adding override_dh_builddeb: dh_builddeb -- -Zxz I'll have yet another look at the package tonight. Thanks. Cheers, Dmitry Smirnov. -- 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/201306192009.50634.only...@debian.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
Hi Daniel, Thanks for your recent corrections. Just few more left to do and I'll upload for you. * When I mentioned unnecessary versioned dependencies I meant that versioning is unnecessary and safe to drop. There is no point writing cmake (= 2.8.2+dfsg.1-0+squeeze1) when just cmake is enough because cmake in oldstable is above minimum requirement. Same applies to libqt4-dev. * Short package description should start with lowercase letter. Copyright: * Upstream uses two emails in source files: Joseph Artsimovich joseph.artsimov...@gmail.com Joseph Artsimovich josep...@mail.ru The latter statement appears to be older (it is often accompanied by years 2007-2008 and one would hardly use this horrible russian email service while having account at gmail). I would at least mention first statement (i.e. contact email) in Upstream-Contact or even include both statement to copyright paragraph as it would be speculative to decide which statement is more important/valid. * The following copyright holders are not listed in debian/copyright: Vadim Kuznetsov ()DikBSD dik...@gmail.com 2011 Petr Kovar pej...@gmail.com * Based on code from the GIMP project is not a copyright statement so perhaps it's better to move it to Comment section. Then it would become obvious that word Copyright is used twice in the paragraph. * At least one file in packaging/osx is under BOOST license. Also file ScanTailor.icns is a (sourceless?) binary file... * License: PD perhaps is better written as License: public-domain. For files in Public-Domain copyright is not applicable so it is better to write Copyright: not-applicable but mention origin of files (i.e. Tango project and URL) in Comment field. * One of the man pages is written by Artem Popov art...@gmail.com but that's not how his name is written in debian/copyright. It is always safer to use original statement as written by author without unnecessary translation of person's name to native characters even if it is done correctly. * Generated man page is not removed on clean. Probably you don't need this reminder but when convenient please forward patch and man pages to upstream. Thanks for your patience. Correcting the above issues will increase our chances to pass ftp-master's review. Cheers, Dmitry Smirnov. -- 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/201306200642.13719.only...@debian.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
On Mon, 17 Jun 2013 21:15:09 Daniel Stender wrote:
As a matter of fact, the CXX_BUILDFLAGS are recognized after a 2nd cmake run:
http://www.cmake.org/pipermail/cmake/2013-June/055082.html
Interesting... I found another post discussing similar bug:
http://www.cmake.org/pipermail/cmake/2008-October/024550.html
Although I don't have good understanding of how it works, using the
above information I was able to produce patch (attached) that fixes
incorrect FLAGS override. I tested it and it looks like no build flags
are dropped any more. I would appreciate if you could review the patch
and apply it if appropriate.
Regards,
Dmitry Smirnov.
---
Platitude: an idea (a) that is admitted to be true by everyone, and (b)
that is not true.
-- H. L. Mencken
Last-Update: 2013-06-18
Forwarded: no
Author: Dmitry Smirnov only...@member.fsf.org
Description: fix FLAGS override due to incorrect caching
Read more about similar issue at
http://www.cmake.org/pipermail/cmake/2008-October/024550.html
--- a/cmake/SetDefaultGccFlags.cmake
+++ b/cmake/SetDefaultGccFlags.cmake
@@ -53,80 +53,80 @@
# Flags common for all build configurations.
SET(
CMAKE_C_FLAGS
-Wall -Wno-unused -ffast-math ${no_inline_dllexport_cflags_}
-CACHE STRING Common C flags for all build configurations. FORCE
+CACHE STRING Common C flags for all build configurations.
)
SET(
CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS} ${stdlibs_shared_static_}
-CACHE STRING Common C++ flags for all build configurations. FORCE
+CACHE STRING Common C++ flags for all build configurations.
)
# Release
SET(
CMAKE_C_FLAGS_RELEASE
-DNDEBUG -O2 ${visibility_cflags_} ${gc_sections_cflags_}
-CACHE STRING C flags for Release builds. FORCE
+CACHE STRING C flags for Release builds.
)
SET(
CMAKE_CXX_FLAGS_RELEASE
-DNDEBUG -O2 ${visibility_cflags_} ${gc_sections_cflags_}
-CACHE STRING C++ flags for Release builds. FORCE
+CACHE STRING C++ flags for Release builds.
)
SET(
CMAKE_EXE_LINKER_FLAGS_RELEASE
${gc_sections_ldflags_} ${dead_strip_ldflags_}
-CACHE STRING Link flags for Release builds. FORCE
+CACHE STRING Link flags for Release builds.
)
# MinSizeRel
SET(
CMAKE_C_FLAGS_MINSIZEREL
-DNDEBUG -Os ${visibility_cflags_} ${gc_sections_cflags_}
-CACHE STRING C flags for MinSizeRel builds. FORCE
+CACHE STRING C flags for MinSizeRel builds.
)
SET(
CMAKE_CXX_FLAGS_MINSIZEREL
-DNDEBUG -Os ${visibility_cflags_} ${gc_sections_cflags_}
-CACHE STRING C++ flags for MinSizeRel builds. FORCE
+CACHE STRING C++ flags for MinSizeRel builds.
)
SET(
CMAKE_EXE_LINKER_FLAGS_MINSIZEREL
${gc_sections_ldflags_} ${dead_strip_ldflags_}
-CACHE STRING Link flags for MinSizeRel builds. FORCE
+CACHE STRING Link flags for MinSizeRel builds.
)
# RelWithDebInfo
SET(
CMAKE_C_FLAGS_RELWITHDEBINFO
-DNDEBUG -g -O2 ${visibility_cflags_}
-CACHE STRING C flags for RelWithDebInfo builds. FORCE
+CACHE STRING C flags for RelWithDebInfo builds.
)
SET(
CMAKE_CXX_FLAGS_RELWITHDEBINFO
--DNDEBUG -g -O2 ${visibility_cflags_}
-CACHE STRING C++ flags for RelWithDebInfo builds. FORCE
+${CMAKE_CXX_FLAGS_RELWITHDEBINFO} -DNDEBUG -g -O2 ${visibility_cflags_}
+CACHE STRING C++ flags for RelWithDebInfo builds.
)
SET(
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO
-CACHE STRING Link flags for RelWithDebInfo builds. FORCE
+CACHE STRING Link flags for RelWithDebInfo builds.
)
# Debug
SET(
CMAKE_C_FLAGS_DEBUG -DDEBUG -g CACHE STRING
-C flags for Debug builds. FORCE
+C flags for Debug builds.
)
SET(
CMAKE_CXX_FLAGS_DEBUG -DDEBUG -g CACHE STRING
-C++ flags for Debug builds. FORCE
+C++ flags for Debug builds.
)
SET(
CMAKE_EXE_LINKER_FLAGS_DEBUG
-CACHE STRING Link flags for Debug builds. FORCE
+CACHE STRING Link flags for Debug builds.
)
- SET(COMPILER_FLAGS_OVERRIDDEN YES CACHE INTERNAL FORCE)
+ SET(COMPILER_FLAGS_OVERRIDDEN YES CACHE INTERNAL )
ENDIF(NOT COMPILER_FLAGS_OVERRIDDEN)
ENDIF(CMAKE_COMPILER_IS_GNUCC AND CMAKE_COMPILER_IS_GNUCXX
--- a/cmake/SetDefaultBuildType.cmake
+++ b/cmake/SetDefaultBuildType.cmake
@@ -1,9 +1,9 @@
MACRO(ST_SET_DEFAULT_BUILD_TYPE TYPE_)
IF(NOT CMAKE_BUILD_TYPE AND NOT DEFAULT_BUILD_TYPE_SET)
- SET(DEFAULT_BUILD_TYPE_SET TRUE CACHE INTERNAL FORCE)
+ SET(DEFAULT_BUILD_TYPE_SET TRUE CACHE INTERNAL )
SET(
CMAKE_BUILD_TYPE ${TYPE_} CACHE STRING
- Build type (Release Debug RelWithDebInfo MinSizeRel) FORCE
+ Build type (Release Debug RelWithDebInfo MinSizeRel)
)
ENDIF(NOT CMAKE_BUILD_TYPE AND NOT DEFAULT_BUILD_TYPE_SET)
ENDMACRO(ST_SET_DEFAULT_BUILD_TYPE)
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
Hi Daniel,
On Sun, 16 Jun 2013 01:16:30 Daniel Stender wrote:
3) buildflags
But Scantailor gets compiled w/o any customization
That's because upstream drop/override given CXXFLAGS (which is a
bug). :)
I'm not experienced with cmake but perhaps first attempt to fix this
problem might look like the following patch:
--- a/cmake/SetDefaultGccFlags.cmake
+++ b/cmake/SetDefaultGccFlags.cmake
@@ -102,9 +102,9 @@
CACHE STRING C flags for RelWithDebInfo
builds. FORCE
)
SET(
CMAKE_CXX_FLAGS_RELWITHDEBINFO
- -DNDEBUG -g -O2 ${visibility_cflags_}
+ ${CMAKE_CXX_FLAGS_RELWITHDEBINFO} -DNDEBUG
-g -O2 ${visibility_cflags_}
CACHE STRING C++ flags for RelWithDebInfo
builds. FORCE
)
SET(
CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO
There are might be better ways to preserve flags and I'm not sure if I
did it properly. Also CFLAGS might need similar workaround (I didn't
check).
Anyway, the custom linker flags got passed through!
Good. :)
I've experimented around, e.g. dropping the build type switch, but couldn't
got a clue why this
isn't working that way, is it?
Build type is better to leave as RELWITHDEBINFO. This might be
useful if you decide to provide -dbg package or just to (re-)build
with debugging info with command like
`DEB_BUILD_OPTIONS=nostrip debuild -us -b`
For recent changes, please cf.:
http://anonscm.debian.org/gitweb/?p=collab-maint/scantailor.git
Sure, I'll have a look in few days (as soon as I have time). Hopefully
it will be ready for upload by then. ;)
Mucht thanks also for the other comments!
No worries, you're very welcome. :)
Cheers,
Dmitry Smirnov
GPG key : 4096R/53968D1B
--
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/201306160220.01580.only...@debian.org
Bug#712056: RFS: scantailor [ITP] -- interactive post-processing tool for scanned document pages
Control: tags -1 moreinfo Hi Daniel, Thanks for packaging scantailor. I had a brief look at the package and IMHO it needs a little bit more work before we'll be able to upload it. * buildflags.patch is incorrect because it is hardcoding FLAGS. To make it useful upstream you could modify cmake to avoid overriding CXXFLAGS and then pass build flags like in the following example: override_dh_auto_configure: dh_auto_configure -- \ -DCMAKE_BUILD_TYPE:STRING=RelWithDebInfo \ -DCMAKE_CXX_FLAGS_RELWITHDEBINFO=$(CPPFLAGS) \ -DCMAKE_EXE_LINKER_FLAGS= -Wl,--as-needed $(LDFLAGS) Also perhaps more DEP-3 headers like [Forwarded,Last-Update] may be useful. * Passing build flags requires more work as there are still some FLAGS missing, according to `blhc`: CXXFLAGS missing (-fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security) * I: scantailor: unused-override hardening-no-fortify-functions usr/bin/scantailor-cli * Please do not override no-upstream-changelog. Lack of upstream changelog is a genuine (minor) problem isn't it? Silencing legitimate warnings is not a good idea, especially when you do it without corresponding comment about why the warning was suppressed in lintian-overrides. * regarding copyright, notation Files: ./crash_reporter/google-breakpad/* is a bit strange as there is no need to prefix file paths with ./ * In Copyright: 2006-2008 Google Inc. paragraph license other is incorrect -- it is a BSD-2-clause license. * In Copyright: 2005-2007 Paul Hsieh paragraph license other is incorrect -- it looks like modified BSD-3-clause license, so perhaps it might be better to mark it something like BSD-3-clause(modified) and/or add a comment. All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- No person, no idea, and no religion deserves to be illegal to insult, not even the Church of Emacs. -- Richard Stallman signature.asc Description: This is a digitally signed message part.
Bug#706361: gti review
Hello Felix, Thank you for your corrections. We're almost there, but I hope that few more pedantic issues could be fixed... :) I take it it is not customary to provide overrides for pedantic warnings? You can do it and on some occasions I overridden some pedantic warnings to acknowledge that I've had a look at it and no further action is necessary. I found overrides useful with maintaining many packages where I tend to forget whenever I already dealt with the warning in particular package. But it is important to recognise unnecessary overrides such as those that tell you about problems that can be addressed by you or by upstream developer(s). It is not good to silence such warnings so the best would be to keep them as reminders however unimportant they may appear. No upstream changelog can remind you to include changelog if/when upstream decide to add it or it may be a reminder to suggest upstream to ship it. Also you may choose to generate changelog if you produce orig.tar from repository checkout. Perhaps there is no reason to silence this particular warning if upstream changelog is not shipped... License name MIT is incorrect even though upstream may refer to this license as such. MIT is considered ambiguous by the Free Software Foundation. Yes, I saw that, which is why I included the full license text. I assumed that would disambiguate it. Does the ambiguous designation mean that the name MIT should simply not be used? I have changed it to MIT Old Style. I think you can use MIT to refer to new MIT license text but perhaps it would be better to call it Expat as advised in copyright-format-specification-1.0: There are many versions of the MIT license. Please use Expat instead, when it matches. Please do not use spaces in short license name -- see examples in copyright-format-1.0 specification which clearly state that License names are case-insensitive, and may not contain spaces. Remember I suggested to use MIT-old-style not MIT Old Style? ;) Specifically I think it is a good practice to maintain Forwarded and Last-Update headers. All patches now have these. Thanks. As for usage of Forwarded field it is unusual to leave it empty. When your patch have only debian customisation and not useful for upstream just use Forwarded: not-needed and you can skip long explanation (in description) why and how this patch is not useful for forwarding. Again, thank you for your review. I appreciate all the information you've shared, and I think the package is much improved after these changes. Thank you, it's been a pleasure to help. :) I checked updated version and to my taste the car is still moving too fast. Of course this is not a problem, just feedback. All the best, Dmitry Smirnov GPG key : 4096R/53968D1B --- I hate all sports as rabidly as a person who likes sports hates common sense. -- H. L. Mencken -- 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/201305240707.15512.only...@member.fsf.org
Bug#706361: gti review
Dear Felix, Thanks for packaging this funny software. :) Isn't the animation is a little too fast? I can hardly recognise the animated car and it's certainly moves faster than animated train in `sl`. I had a look at your package and I'd like to share some suggestions with you: There is unnecessary lintian-override for no-upstream-changelog. Please remove it. It may be a reminder to generate upstream changelog if you're producing orig.tar from checkout. By the way why you didn't forward man page upstream yet? Package version looks a little bit unconventional. Although it's not a problem I would suggest to use just version 1.0.4-1 and backport patches from unreleased upstream commits if necessary. If you don't want to use upstream tarball releases as is then please provide get-orig-source target in debian/rules to generate upstream tarball from checkout. Perhaps the easiest solution would be to use upstream tarball as is. ## debian/watch As it is debian/watch could be fine for package version 1.0.4-1. However it is broken for version 1.0.4+git.20130416.8b0819d-1 which requires dversionmangle. Otherwise `uscan` can't download orig.tar. ## debian/rules debian/rules contains unnecessary comments (dm-make template remnants?) -- please consider removing 'em. Also you might add override_dh_builddeb: dh_builddeb -- -Zxz To save some space you might want to compress .deb file with xz instead of gz. To use xz compression for Debian source you can also add compression = xz to debian/source/options. ## debian/copyright License name MIT is incorrect even though upstream may refer to this license as such. MIT is considered ambiguous by the Free Software Foundation. copyright-format-1.0 specification recommends to label newer MIT license as Expat however this is an older variant so it would be better called MIT-old-style or similar. See http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ https://en.wikipedia.org/wiki/MIT_License ## debian/control Priority extra is probably better changed to optional as per http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Priority IMHO Suggests: sl is incorrect because it suggests unrelated package. I would replace it with Enhances: git. Versioned build-depends on dpkg-dev (= 1.16.1~) is unnecessary and may be completely dropped. ## Patches Please follow Patch Tagging Guidelines: http://dep.debian.net/deps/dep3/ Specifically I think it is a good practice to maintain Forwarded and Last-Update headers. Perhaps it would be Forwarded: non-needed for fix-makefile-do-not-strip-symbols.patch fix-makefile-installation-path.patch fix-makefile-add-dpkg-buildflags.patch it is done wrong. I would rename it and modify to respect build flags but without including file provided my dpkg. This way your improvement will be usable for upstream and will have to be forwarded. debhelper 9 in compat 9 mode automatically export build flags which makes unnecessary to include /usr/share/dpkg/buildflags.mk or set DPKG_EXPORT_BUILDFLAGS as we used to do with dh 8 to import hardening flags. Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B --- Most people work just hard enough not to get fired and get paid just enough money not to quit -- George Carlin -- 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/201305011737.50681.only...@member.fsf.org
Re: Bug#706361: gti review
On Wed, 1 May 2013 18:42:19 Charles Plessy wrote: to be comprehensive, there are also the Software Package Data Exchange project and the Open Source Initiative which both agree on a reference MIT license: http://opensource.org/licenses/MIT http://spdx.org/licenses/MIT So if it matches the above, it may be fair to call it MIT if Upstream calls it MIT. Interesting, thanks. In the case of gti, the license does not match the text of the MIT or Expat license, therefore it is better to use an arbitrary short name. Something like gti, or MIT-like (as Upstream calls it), etc. would be enough. The following page https://fedoraproject.org/wiki/Licensing:MIT?rd=Licensing/MIT#Old_Style refers to the text of this license as MIT Old Style therefore I suggested to label it as MIT-old-style exactly because it's not a new MIT license (AKA Expat). Best wishes, Dmitry Smirnov GPG key : 4096R/53968D1B -- 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/201305011908.26555.only...@member.fsf.org
Re: Bug#700233: Subject: RFS: libre-jigsaw/2012.09.09-1 [ITP]
Hi Jon, On Sun, 10 Feb 2013 22:10:08 Jon Hulka wrote: I am looking for a sponsor for my package libre-jigsaw. As the name implies, this is a jigsaw puzzle game. Currently there is nothing like it in the Debian repositories, and I think it will be a good addition to Debian games. As I mentioned in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660433#18 there are decent jigsaw puzzle games in Debian: palapeli, xjig and others. I'm not that impressed with libre-jigsaw but the images are truly nice. Perhaps the best would be to package images separately as a standalone source package to benefit other jigsaw puzzle games as well as any other use such as desktop backgrounds etc. In this case package description shall be neutral i.e. it doesn't have to mention libre-jigsaw. The game packaging shall be improved. Paul already stressed the main points of importance but also you may consider * using javahelper. * to use up-to-date Standards (debian/control) * use xz compression for source and binaries. * tracking packaging in publicly accessible VCS. By the way what's the point installing that many (14) icons to /usr/share/icons/hicolor? Is it really necessary? Cheers, Dmitry Smirnov GPG key : 4096R/53968D1B --- Good luck happens when preparedness meets opportunity. -- 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/20130257.09416.only...@member.fsf.org
Bug#700233: Subject: RFS: libre-jigsaw/2012.09.09-1 [ITP]
On Mon, 11 Feb 2013 12:50:47 Jon Hulka wrote: there are decent jigsaw puzzle games in Debian: palapeli, xjig and others. I'm not that impressed with libre-jigsaw but the images are truly nice. I know I'm biased, but I didn't find these to be very playable. Did you have a good look? Clearly palapely is very playable because you can zoom-in/zoom-out, scroll and easily connect pieces together while in libre-jigsaw pieces are snapping together only after annoying precision-work. Besides pieces are looking better in palepeli. To appreciate xjig you need a little bit more patience: it is mostly controlled by command line and parhaps lacking some GUI to choose an image but it's gameplay is rich, unique and challenging because pieces can be flipped over as well as rotated. I might be overly critical to libre-jigsaw but its interface do not appears very impressive to me... By the way what's the point installing that many (14) icons to /usr/share/icons/hicolor? Is it really necessary? Probably not - I'm learning. Thank you for your effort. It is appreciated despite some criticism that you may feel. :) Regards, Dmitry Smirnov GPG key : 4096R/53968D1B -- 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/201302111310.35632.only...@member.fsf.org
Bug#696385: RFS: astromenace/1.3.1+ds-1 [ITP] -- hardcore 3D space shooter with spaceship upgrade possibilities
On Tue, 25 Dec 2012 21:06:54 Boris Pek wrote: - Since you use xz compression, please consider adding Pre-Depends: dpkg (= 1.15.6) to debian/control (i.e. lintian tag data.tar.xz-member-without-dpkg-pre-depends, which I think has been recently removed). Yes, I am aware of this lintian note, but I ignore it because: 1) It is useless for new packages. 2) Pre-Depends should be used sparingly, preferably only by packages whose premature upgrade or installation would hamper the ability of the system to continue with any upgrade that might be in progress. You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached. [1] [1] http://www.debian.org/doc/debian-policy/ch-relationships.html Perhaps it was me who ignored this lintian warning first. :) This warning doesn't make sense for Debain any more. I completely agree with Boris on this. - Dmitry Smirnov is listed as an Uploader for astromenace but not for astromenace-data; is this intended? I am not sure that he want to co-maintain it. But he could add or remove himself from uploaders list at any moment. Dmitry, could you comment this? Boris picked up the packaging where I left it. In the beginning both packages [astromenace,astromenace-data] were generated from single source. It was good enough as proof of concept. I was not following on development since Boris continued it but I trust Boris and I'm sure he knows what he is doing. :) As the moment I have other priorities so I can't co-maintain astromenace-data yet. I'd probably stay a bit longer as astromenace uploader until I decide whenever remove or add myself as uploader of astromenace-data. Thanks, Boris. Thanks Vincent. Cheers, Dmitry. -- 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/201212252241.42800.only...@member.fsf.org
Bug#688111: RFS: git2cl/2.0+git200808271242-2
Package: sponsorship-requests Severity: normal Dear mentors, Please consider uploading updated version of git2cl package. Changelog as follows: git2cl (2.0+git200808271242-2) unstable; urgency=low * Added new patch to introduce POD documentation to git2cl executable: best practice recommend providing embedded docs viewable with perldoc. * Changed man page generation from standalone markdown file with pandoc to pod2man producing man page from embedded documentation. This fixed hyphen-used-as-minus-sign (Closes: #672111). * Updated homepage and upstream source URLs. * Build-Depends: - dropped pandoc. + added perl-doc (used to pre-validate embedded POD documentation). * Debhelper compat to version 9. * Standards to 3.9.3. * Debian source compression to xz. * debian/copyright: + to copyright-format-1.0. + minor update to copyright year. - removed '©' characters (not needed according to specification). -- Dmitry Smirnov only...@member.fsf.org Wed, 19 Sep 2012 15:57:33 +1000 I think it is safe to upload to unstable as the probability of discovering a RC bug in git2cl/testing is quite low. (IMHO it doesn't worth troubles to upload this to experimental). To access further information about this package, please visit: http://mentors.debian.net/package/git2cl Source package is available from http://mentors.debian.net/debian/pool/main/g/git2cl/git2cl_2.0+git200808271242-2.dsc Thank you. Best regards, Dmitry. -- 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/201209192322.07112.only...@member.fsf.org
Bug#688111: RFS: git2cl/2.0+git200808271242-2
On Thu, 20 Sep 2012 00:10:31 Arno Töll wrote: I didn't look at your package, but at a first glimpse while looking through my mailbox, this came to my attention: Yesterday a new policy version was released, making this standards version outdated. I thought I'd have more time to absorb policy changes. :) Updated to 3.9.4, thanks. Regards, Dmitry. -- 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/201209200056.43782.only...@member.fsf.org
Bug#688184: RFS: redmine-plugin-markdown/2.0.1+git20120821-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my new package redmine-plugin-markdown * Package name: redmine-plugin-markdown Version : 2.0.1+git20120821-1 Upstream Author : Takashi Okamoto toran...@gmail.com * URL : https://github.com/alminium/redmine_redcarpet_formatter * License : GPL-2+ Section : web Description : Introduce Markdown support for Wiki in Redmine using Redcarpet. . Redcarpet is extremely fast and compatible Markdown formatter which is used as GitHub's wiki formatter. It builds the following binary package: redmine-plugin-markdown - Redmine plugin to add Markdown as a wiki format To access further information about this package, please visit: http://mentors.debian.net/package/redmine-plugin-markdown Source package is available from http://mentors.debian.net/debian/pool/main/r/redmine-plugin-markdown/redmine-plugin-markdown_2.0.1+git20120821-1.dsc Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#688185: RFS: winswitch/0.12.16+svn20120916-1
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my new package winswitch. * Package name: winswitch Version : 0.12.16+svn20120916-1 Upstream Author : Antoine Martin anto...@nagafix.co.uk * URL : http://winswitch.org/ * License : GPL-3+ Section : utils Description : tool to start and control remote sessions supports both seamless applications (via Xpra, NX and ssh) and full remote desktops (via NX, VNC, RDP). Once a session has been started via winswitch, it can be displayed on any other networked machine running the winswitch client. It builds the following binary package: winswitch - tool to start and control remote sessions To access further information about this package, please visit: http://mentors.debian.net/package/winswitch Source package is available from: http://mentors.debian.net/debian/pool/main/w/winswitch/winswitch_0.12.16+svn20120916-1.dsc Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Re: Need help for watch file
On Tue, 28 Aug 2012 19:27:28 Andreas Tille wrote: Hmmm, I tried this opts=dversionmangle=s/([\d.]+)\.(\d+)/$1-r$2/,downloadurlmangle=s/MRIConver t_.*/mriconvert_sources.zip/ \ http://lcni.uoregon.edu/~jolinda/MRIConvert/MRIConvert_x86-([\d\.]+-r\d+)\ .tar\.gz which ends up with version 2.0-r235. I know that dversionmangle is the wrong approach and it rather should be uversionmangle=s/([\d.]+)-r(\d+)/$1.$2/ but if I try this I do not get a match on the given download page. The following would work with uscan --rename --repack: ## opts=\ uversionmangle=s/([\d.]+)-r(\d+)/$1.$2/,\ downloadurlmangle=s/MRIConvert_.*/mriconvert_sources.zip/,\ filenamemangle=s/.*/orig.zip/,\ http://lcni.uoregon.edu/~jolinda/MRIConvert/MRIConvert_x86-([\d\.]+-r\d+)\.tar\.gz ## Hack-ish and perhaps ugly but works... Indeed the best would be to try convincing upstream to rename source archive... Cheers, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#659947: Bug #659947: RFS: portabase/2.0+git20110117-1 [ITP] -- Easy-to-use personal database application
This is fixed, thank you very much. http://mentors.debian.net/debian/pool/main/p/portabase/portabase_2.0+git20110117-1.dsc Cheers, Dmitry. On 31/05/12 04:01, Aron Xu wrote: Hi, The packaging of this package is almost fine, but there is a problem in DEP5 copyright file: W: portabase source: syntax-error-in-dep5-copyright line 8: Duplicate field copyright. Please fix this warning, thanks! signature.asc Description: OpenPGP digital signature
Bug#672394: RFS: ipset/6.12-1 -- administration tool for kernel IP sets
Hi Arno, On 15 May 2012 08:51, Arno Töll a...@debian.org wrote: * You declare the debhelper compat[ibility] to be 9, but you build depend on debhelper (= 9). Please use a version which actually supports the finalized level 9. That is 9.20120115. No need to impose this requirement because non-finalized versions are not present in the archive: http://packages.debian.org/search?keywords=debhelpersearchon=namessuite=allsection=all IMHO debhelper (= 9) would be perfectly fine. Moreover this is a common practice. Strict dependency would be justified only if there were any particular bugs in prior 9.20120115 but even then we could safely use (= 9) simply because no broken versions are present in the archive. Please share your concerns if I'm missing anything. Thank you. Regards, Dmitry. -- 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/CANBdODUmaF0jaELwaQrPOS2hmmmWjDuhV-ncx2rJF-c9bZ=M=a...@mail.gmail.com
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
Dear William, Since you're on board with us may I suggest that you'll close your RFS bug yourself? (I'm a bit overwhelmed with work at the moment) Michael, I set up package repository at collab-maint: http://anonscm.debian.org/gitweb/?p=collab-maint/autofs.git All the best, Dmitry. On 9 May 2012 04:27, William Dauchy wdau...@gmail.com wrote: I was also interested for this package since I uploaded a version in #671436 a few days ago with less modification for a first update. Please consider closing it since the package from Dmitry seems more complete. I'm also interested to be a co-maintainer. -- 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/canbdodxrcxa+9kabtb4cndhjvsau4y9pamce+44wtkh__zj...@mail.gmail.com
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
On Sun, 6 May 2012 15:24:10 Michael Tokarev wrote: And note that whole 5.0.6-allow-for-kernel-packet-size-change.patch is NOT NEEDED, it should be reverted upstream. *SIGH*, we spent a ton of time and emails discussing this matter, please find the recent LWN feature article about it (a good summary), or LKML threads. The patches are now added to all stable trees. The two patches -- linux kernel version check and this one -- should be reverted upstream and not included in debian package. Thanks for this, I trust you that we don't need 5.0.6-allow-for-kernel-packet-size-change.patch However it is not too easy to just drop this patch because it will break the chain of upstream patches. Possibly we need to apply all upstream patches and then use our new patch to revert some of their changes... Or maybe consider ignoring upstream patches... What do you think would be the best? Dropping kernel version check is a bit challenging as well due to multiple references to this code. If you're sure it will be a cause for any troubles perhaps we could modify the code of 'linux_version_code' function instead of dropping it completely... Unfortunately this is a bit beyond my competency so I hope you have some ideas. Thank you. Regards, Dmitry. -- 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/201205061616.03270.only...@member.fsf.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for package autofs * Package name: autofs Version : 5.0.6-1 Upstream Author : Transmeta corporation * URL : http://www.kernel.org/pub/linux/daemons/autofs/v5/ * License : GPL-2+ Section : utils It builds those binary packages: autofs - kernel-based automounter for Linux autofs-hesiod - Hesiod map support for autofs autofs-ldap- LDAP map support for autofs autofs5- transitional dummy package for 'autofs' autofs5-hesiod - transitional dummy package for 'autofs-hesiod' autofs5-ldap - transitional dummy package for 'autofs-ldap' To access further information about this package, please visit the following URL: http://mentors.debian.net/package/autofs Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/autofs/autofs_5.0.6-1.dsc Changes since the last upload: * New upstream release - mount(nfs): no hosts available (Closes: #608459). - new upstream version available (Closes: #602933). - autofs mounted directory are never dismounted (Closes: #521165). - autofs5 does not support recursive mount (Closes: #626473). - autofs5 crashed in a nested setup in combination with negative lookups on * (Closes: #617317). - autofs5-ldap: simple bind auth feature request (Closes: #595808). - autofs5-ldap: SASL auth broken (Closes: #568813). * package rename: dropping '5' from package names (Closes: #655351). * NMU changes acknowledged (Closes: #603491, #583094). * register /etc/default/autofs with ucf (Closes: #556961). * debian/copyright to DEP-5 format; upstream copyright audit. * packaging update: * use debhelper compat version 9. * standards to 3.9.3 * lintian-override for 'non-standard-file-perm' * install missing autofs_ldap_auth.conf.5 man page * source format to version 3 and .xz compression * debian/rules rewritten in debhelper style * patchworks: + replacing upstream patches with new patchset as of 2012-04-23. + replacing dpatch with quilt (Closes: #668077) + new patch to correct manpages spelling (Closes: #660075) thanks to Oz Nahum Tiram and Javi Merino + updated SYSV init script patch: * removed bashisms (Closes: #626435). * introduce 'status' support to SYSV script (Closes: #651978, #667811, #565507). * adding 'slapd' to Should-Start/Stop (Closes: #600764, #659616). * LSB output (Closes: #567805) thanks to Petter Reinholdtsen. * declare myself as Maintainer (adopting package) -- This package was NMU'ed twice since last maintainer's update in August 2009. Maintainer Jan Christoph Nordholz he...@pool.math.tu-berlin.de is MIA, here is what he wrote on another package some months ago: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641867#20 (I will follow the remaining bugs after upload of this package.) Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
Hi Michael, Thank you for quick reply. On Sun, 6 May 2012 15:01:42 Michael Tokarev wrote: I'm very much interested in this package myself, and wanted to do some packaging as well, but got distracted by other things, and especially by the famous 32/64bit user=kernel space interface issues we found recently (there was several threads on LKML about it and a feature LWN article). I'm swamped with work myself but I couldn't leave this package unattended. :) After all I'm actively using it. :) I looked at your packaging, it looks sane at first, but you did quite a few things all in one go, so it makes me a bit nervous. Especially, did you test transition from autofs5 to autofs, does it work correctly? Yes I did test it to the extent of my abilities. Actually it was quite tricky to do it right especially in regards to config files but I believe I've managed to do it well. Of course review, testing and improvement suggestions would be much appreciated. I'd love to sponsor this package, and maybe to become a co-maintainer if that's welcome in any way, but unfortunately I've no time in a few days to work with it, -- as you may know, we all russians have a long weekend, due to the Victory Day, so I'll be unavailable (and away from computers) up to May-10. Thank you very much - you are more than welcome as co-maintainer. Since I've been honoured with DM status recently I might be able to look after this package without bothering you too much with sponsorship requests, if you consider setting 'dm-upload-allowed'. ;) Congratulations for the upcoming holiday. Can you wait for a few days please? :) Unless someone else wants to sponsor this package ofcourse! I will try to find some time in these days to check it all too, but I can't promise. BTW, Monday (tomorrow) have a good chance to have me semi-available :) Souns great. :) Thank you, especially for doing this packaging! The new packaging and the care with which you do things - I like it! It is a pleasure to read your kind words. Thank you. All the best, Dmitry. -- 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/201205061538.07970.only...@member.fsf.org
Bug#671701: RFS: autofs/5.0.6-1 [ITA] -- kernel-based automounter for Linux
There's one more issue with the new package. I already
told Ian about it, but apparently he ignored it. This
new code being added as a patch to debian package,
originally from upstream author:
++static inline unsigned int linux_version_code(void)
++{
++struct utsname my_utsname;
++unsigned int p, q, r;
++
++if (uname(my_utsname))
++return 0;
++
++p = (unsigned int)atoi(strtok(my_utsname.release, .));
++q = (unsigned int)atoi(strtok(NULL, .));
++r = (unsigned int)atoi(strtok(NULL, .));
++return KERNEL_VERSION(p, q, r);
++}
This will break with 2-number kernel version string. There
were several tools who assumed 3-component version string
and who broke when 3.0-rc come out, so Linus decided to
postprone defaulting to 2-component version. Many packages
has been fixed since, but here autofs introduces a new bug
of the same theme.
Note that actually the version check isn't really necessary
since the issue for which it has been added is now resolved
in the kernel.
Thanks,
/mjt
I'm not sure if I fully understand the implications...
As far as I know it works well with 3.2 kernel...
Any suggestions are welcome.
By the way, many thanks to you for your work on 'mdadm' package.
I'm in your debt for this.
Eventually I might be available for help but you're doing great already. :)
Cheers,
Dmitry.
--
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/201205061545.41477.only...@member.fsf.org
how to adopt a non-orphaned package?
Dear mentors, What would be the best practice to adopt a package which was not properly orphaned? My particular concern is about 'autofs5' package which was not updated for years since squeeze release due to maintainer inactivity. I'd like to adopt this package but it wasn't properly orphaned or requested for adoption. I already sent an email to maintainer but considering proximity to freeze, we don't have three months to wait for maintainer's answer (if ever). What would be the best practice to adopt the package in such case? In the updated source package I uploaded to mentors.debian.net I set myself as maintainer and moved original non-active maintainer to Uploaders. Contrary to NMU uploads, I'm not sure how to properly adopt a de-facto orphaned (non-maintained) package. Please advise. Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Re: how to adopt a non-orphaned package?
Hi Paul, On Wed, 25 Apr 2012 18:39:58 Paul Wise wrote: http://www.debian.org/doc/manuals/developers-reference/beyond-pkging.html#mia-qa Thank you for reminding me about this link. (I already asked MIA team today). Sadly this is exactly the case when inactive maintainer had his packages sponsored so there is no information in database. All the best, Dmitry. -- 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/201204251928.42333.only...@member.fsf.org
Re: Making packages available to Debian users (was: Bug#659047: RFS: rpg - Readable Password Generator)
On Sunday 08 April 2012 12:58:08 Vladimir Stavrinov wrote: The problem is that I don't see this review process here. Instead, all of You are explaining what Debian is and what is not. But I've got no much new. You are trying to breach into opened door. But point is that all this discussion have no relation to script in question. Hi Vladimir, I routinely use 'pwgen' but because it doesn't have functionality I wish for on several occasions I've been trying other password generation tools. Shortly after you published your RFS I tried 'rpg' but quickly discarded it because from the first look I found no new functionality. (pwgen is more feature rich) In my view even if 'rpg' is marginally better with generation of certain kind of passwords than 'pwgen', it's not enough to justify inclusion of 'rpg' to archive but rather demonstrate a possible way to improve existing tools. I like, respect and appreciate diversity we're already have in Debian but having too many tools doing the same thing is hardly helpful. Moreover one simple script like 'rpg' do not benefit so much from packaging so perhaps it may be still useful for those who want to use it if they just get it with 'wget' etc. It is great that you love and care for your script and wish to share it with the world through Debian, however I have a feeling that few people around here convinced that we have a problem worth introducing 'rpg' as solution. Debian always needs manpower and if you truly wish to help us we will much appreciate your contribution to existing packages. I imagine you might be already using some Debian packages which need more love and care. Your skills will be better used if you dedicate a bit of your attention to addressing existing problems. Your work on other packages will help you to learn and to demonstrate that you're capable of taking responsibility for a package maintenance. All the best, Dmitry. -- 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/201204081618.55921.only...@member.fsf.org
Re: sponsorship-requests mails should not go to debian-mentors
We already tried to discuss the issue in Bug#658498: sponsorship-requests and debian-mentors mailing list but I have a feeling our argument hasn't been heard. Regards, Dmitry. -- 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/201203071127.48981.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Hi Russ, On Monday 27 February 2012 17:59:28 Russ Allbery wrote: Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). A bug in the test suite? It's worth being careful about assuming that the package is working when the tests are failing. :) Sorry, sorry, never mind. :) Actually I couldn't find peace with it so I checked again I realised that tests actually are not failing on Hurd. Fortunately I was wrong. :) All good, no need to ignore. So again I had to ignore post-build test(s) failure. I don't think that makes sense to do for Hurd, actually. The package needs to be ported to it; I would let the build fail until that's happened. That may mean just porting the test suite or the test suite may be uncovering a real issue. That's generally what I do with any non-release architecture until I have time to do the (low priority, usually) porting work. You don't want to accidentally hide failures that need porting effort by making the build succeed artificially. Fully agreed. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. Making the *dependency* strict isn't going to add a failure point. It's not like valgrind is going to disappear on i386 and amd64. True, good point to keep in mind when considering. If the build failures are mostly due to bugs in the test suite, I agree with you. That's the criteria on which I'd make the decision. If the tests are finding bugs, then the failures are valuable and shouldn't be suppressed. That's common sense, I can only agree. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. However, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Rather, I think you should make a decision: either depend on the tools required to run the tests and ignore the test failures (if you think they're bugs in the test suite and not the package) if the output is valuable, or don't depend on the tools and skip the tests. Thank you, I think this is a good advice. I'll keep it in mind. All the best, Dmitry. -- 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/201202272049.33489.only...@member.fsf.org
Re: build server at home?
Hi Gergely, Thank you for sharing your experience - very interesting. Regards, Dmitry. -- 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/201202272052.23376.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
In case someone is tempted to try Build-Depends like check | dpkg, it doesn't work at all in pbuilder which is smart enough to notice that dpkg is already installed so it never pulls 'check'. (Anyway particular example with check is silly because check is available on all architectures) Apart from that such approach will provoke a nasty lintian error. So this idea is not worth the effort. As Russ Albury noticed earlier, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Regards, Dmitry. -- 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/201202280245.33508.only...@member.fsf.org
Re: RFS: ipset
Hi Nikolai, Basically what you're talking about is just happened - some hours ago 'ipset' was accepted to unstable, see http://packages.qa.debian.org/i/ipset.html When credits for preparing standalone 'ipset' package goes to Neutron Soutmun, yours truly played a key role in coordinating and preparing a non-colflicting upload of both packages (ipset and xtables-addons). Next challenge would be to backport ipset... Regards, Dmitry. -- 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/201202280354.33561.only...@member.fsf.org
Re: Bug#661568: RFS: ipset/6.11-2
Hi Neutron, Just one little suggestion if you excuse me: Could you please put a short description of bugs you're closing to changelog? This would be very helpful. Cheers, Dmitry. On Tuesday 28 February 2012 14:28:25 Neutron Soutmun wrote: * Close bugs that have been reintroduced again since updating version uploaded. (Closes: #528990,#625360,#648366) -- 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/201202281523.27413.only...@member.fsf.org
Re: Explain to me any all
Fantastic, thanks very much Bernhard, I think that's the explanation we're all needed. Regards, Dmitry. On Sunday 26 February 2012 22:02:15 Bernhard R. Link wrote: * Paul Elliott pelli...@blackpatchpanel.com [120226 02:03]: The new standard allows any all in the Architecture field. Please explain this new feature. What does it do and under what circumstances should it be used? It's for the Architecture field of the .dsc. As that field is automatically generated, you don't use it normally. As maintainer you usually edit the debian/control field. There every binary package has an Architecture list. This Architecture in the .dsc is the merged list of all those architectures. If one package is e.g. architecture i386 and one is architecture any, then those are merged to any (as there is a package to be generated on any architecture, it does not matter that on i386 there are even more packages to generate). What is changed is what happens if one .deb is architecture any and one .deb is architecture all. Former versions of dpkg merged that to any and policy reflected that. The problem with this is that it loses information whether there are architecture all packages to be built. As architecture all packages were never built by the buildds, this was no actual problem, so only fixed recently. Current versions of dpkg merge this to any all, and policy was changed to reflect this. Bernhard R. Link -- 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/201202262352.35402.only...@member.fsf.org
Re: Announcing Debexpo v2
I just wanted to thank you sincerely for all the hard work of yours which is so very useful for all of us. Thank you, Arno and Nicolas! Good work. Cheers, Dmitry. -- 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/201202262357.47195.only...@member.fsf.org
build server at home?
Dear mentors, Could any of you share experience of having your own private build server? I'm thinking of something which could build uploaded source for as many architectures as possible on amd64 host, and ideally put the results to 'reprepro'-managed tree. The goal is to simplify package deployment to internal infrastructure for evaluation before upload to debian. Any hints for quick start please? Thank you. Regards, Dmitry. -- 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/201202270005.46734.only...@member.fsf.org
optional package in Build-Depends (how?)
Dear mentors, I have an interesting problem on my hands: The package I need to build have optional build dependency (libgpm-dev) which is not available on all platforms. If I just put it to Build-Depends, package will FTBFS on some platforms. So idea is to specify an optional (soft) build-dependency like Build-Depends: libgpm-dev | TRUE where 'TRUE' would stand for essential package like 'dpkg'. However I suspect there must be a better way to do that, a practical equivalent to hypothetical 'Build-Recommends'. What would be the best practice for such case? Any suggestions? Thank you. All the best, Dmitry. -- 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/201202271251.20803.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Hi Paul, Thanks for quick reply. On Monday 27 February 2012 13:00:32 Paul Wise wrote: See section 7.1 of debian-policy for examples on how to do that (you probably want linux-any for the arch): http://www.debian.org/doc/debian-policy/ch-relationships.html Indeed it probably could be written as Build-Depends: libgpm-dev [linux-any] But the obvious drawback would be the requirement to know all architectures where this package is available. In this case Build-Depends configuration will be ineffective against changes. Maintainer will have to track if the package was ported to new architecture and maintaining such relationships may potentially turn into expanded list of architectures. Perhaps it will work beautifully for dependencies which will never be ported. But let's discuss more general case: what if optional dependency is not ported to target architecture yet, or if if is not available in backports? There are might be situations where defining optional build dependencies without architecture wildcard may be more error-proof and easier to maintain. Another case I'm thinking of is when upstream is using unit-testing framework like 'valgrind'. I like to have post-build tests enabled. But this functionality requires an optional dependency. I don't want to risk my package to FTBFS because I put dependency only needed for unit tests to Build-Depends and it is not available on all our platforms. In such case using architecture wildcard is just inappropriate because availability of such package (may) have nothing to do with architecture. Specifically regarding 'libgpm-dev', I've made a list of architectures where it is available (below). At the moment I have no idea what 's390x' is (linux or not) so I have doubts regarding architecture wildcars to use. (OK, I admit I've checked with 'type-handling any linux-gnu' command but I'm still confused how to use architecture wildcards properly in this case) All of this makes me think about the approach to use essential alternative to make sure build will never fail because of my lack of understanding which platform will have the required package. What do you think? libgpm-dev avr32 N hppaN hurd-i386 N kfreebsd-amd64 N kfreebsd-i386 N s390x N alpha Y amd64 Y armel Y i386Y ia64Y m68kY mipsY mipsel Y powerpc Y armhf Y powerpcspe Y s390Y sh4 Y sparc Y sparc64 Y Regards, Dmitry. -- 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/201202271342.28308.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Hi Craig, Thak you for sharing your experience. On Monday 27 February 2012 14:09:21 Craig Small wrote: That's the problem I have with mudlet. libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386], liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386], Very interesting and useful. This is exactly what I'm afraid of. How can fellow maintainer track the changes in all architectures effectively? I imagine the maintenance pain for such configuration and it is probably breaks once in a while... It's not pretty and basically means if other arches come along and support libluajit I have to manually fix it. I don't think I could use or | because it didn't work on some build systems. I see... A or nothing would be handy but I always get worried that you will miss linking because of a transistional bump then the program behaviour changes. Imagine if on the armel libluajit is not available temporarily. I think its better to fail to build than to issue out a package without that linking. This is a very valid point, thank you. You're right, if libgpm-dev is not available on i386 or amd64 for whatever reason, build should fail rather than ignore the problem. Which makes this dependency package optional only on some architectures so I probably need to use something like libgpm-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], or libgpm-dev [linux-any], It's not too bad after all. Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. OK, so for really optional packages like 'check' or 'bison' it may be appropriate to use something like check | dpkg if we're not linking against it. I understand it much better now. Thank you. Cheers, Dmitry -- 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/201202271518.25990.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Hi Russ, On Monday 27 February 2012 15:28:51 Russ Allbery wrote: Even with valgrind, personally I'd just list a specific set of architectures on which valgrind is required, even if you also opportunistically test for its existence. There's no reason to allow *not* running valgrind tests on i386 and amd64. It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). So again I had to ignore post-build test(s) failure. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. Regards, Dmitry. -- 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/201202271628.51099.only...@member.fsf.org
Bug#660175: RFS: fcgi-daemon
Package: sponsorship-requests Severity: normal Dear mentors, New package fcgi-daemon is looking for sponsor. fcgi-daemon is an 'fcgiwrap' alternative with friendly debconf interface; It makes CGI applications available through FastCGI interface which comes handy for nginx. It can execute CGI scripts written in Perl with persistent interpreter for acceleration. Additionally it uses RLIMITs, and check for memory leaks on Linux. Package name: fcgi-daemon Version: 0.2021-1 Upstream Author: Dmitry Smirnov only...@cpan.org Homepage: http://search.cpan.org/dist/FCGI-Daemon/ License: AGPL-3+ Section: web Language: Perl Description: Perl-aware FastCGI daemon FCGI::Daemon is a small FastCGI server for use as fcgiwrap alternative with nginx web server. It is enforcing RLIMITs and running unmodified perl applications with persistent interpreter like mod_perl. FCGI-Daemon correctly passing STDERR output to web server. Source package URL: http://mentors.debian.net/debian/pool/main/f/fcgi-daemon/fcgi-daemon_0.2021-1.dsc It produces the following architecture-independent packages: fcgi-daemon libfcgi-daemon-perl QA information: Info: Package is Lintian clean Info: Package is not native Info: The maintainer and uploader emails are the same Info: Package is the latest upstream version Info: A watch file is present Info: The watch file works Info: Closes WNPP bug #650198: ITP: fcgi-daemon -- Perl-aware FastCGI daemon Info: The package uses straight debhelper More information about this package is available from the following URL: http://mentors.debian.net/package/fcgi-daemon Thank you. All the best, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#659947: RFS: portabase
Package: sponsorship-requests Severity: normal Dear mentors, New package portabase is looking for sponsor. Portabase is a modern alternative to MobileDB (and to Jfile). Use case: you're taking water samples and analyse them on spot with portable colorimeter. Then you enter results to mobile version of portabase (I use my Nokia N900). Desktop version of this application comes handy to work with the data on workstation with full-size screen. Also Portabase is useful to prepare data for mobile use. * Package name: portabase * Version : 2.0-1-1 * Upstream Author : Jeremy Bowman jmbow...@alum.mit.edu * Homepage: http://portabase.sourceforge.net/ * License : GPL-2+ * Section : databases * Language: C++ * Description : Easy-to-use personal database application Source package URL : http://mentors.debian.net/debian/pool/main/p/portabase/portabase_2.0-1-1.dsc It produces the binary package portabase. ### PortaBase is a program for conveniently managing one-table database files. It is available for many platforms, including Linux, Mac OS X, Windows, and Maemo. Features include: * String, Integer, Decimal, Boolean, Note (multi-line text), Date, Time, Calculation, Sequence, Image, and Enum column types; * custom data views (subsets of the columns in any order); * filter the displayed rows using sets of conditions; * sort the rows by any combination of columns, each in ascending or descending order; * add, delete, rearrange, and rename columns at any time; * view summary statistics for columns (total, average, min, max, etc.); * import data from CSV, XML, and MobileDB files; * export data to CSV and XML files; * command-line format conversions (to and from XML, from MobileDB); * optional data file encryption. ### QA information: Info: Package is Lintian clean Info: Package is not native Info: The maintainer and uploader emails are the same Info: Package is the latest upstream version Info: A watch file is present Info: The watch file works Info: The package uses straight debhelper Info: Closes WNPP bug #584570: ITP: portabase -- An easy-to-use personal database application To access further information about this package, please visit the following URL: http://mentors.debian.net/package/portabase Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Bug#660014: RFS: portabase
Package: sponsorship-requests Severity: normal Dear mentors, New package git-ftp is looking for sponsor. Package name: git-ftp Version: 0.6.0+git20110923-1 Upstream Author: René Moser m...@renemoser.net URL: https://github.com/resmo/git-ftp License: GPL-3 Description: git-ftp is a shell script for uploading Git tracked files to an FTP server. By default, it uploads only those files which have changed since the last upload. . This saves time and bandwidth. It can even work with different branches. Source package URL: http://mentors.debian.net/debian/pool/main/g/git-ftp/git-ftp_0.6.0+git20110923-1.dsc To access further information about this package, please visit the following URL: http://mentors.debian.net/package/git-ftp Thank you. Regards, Dmitry. signature.asc Description: This is a digitally signed message part.
Re: How to convince maintainer to use --as-needed?
On Fri, 10 Feb 2012 23:15:22 Bernhard R. Link wrote: I personally strongly recommend against using --as-needed unless you understand very well what it does. It may change the runtime behaviour of a program without any signs at link time. Surely it's a powerful thing which should be used with care. Many packages has no or little benefit so using --as-needed would not be justified. But sometimes an innocent call to library causing package to inherit the whole hierarchy of needless dependencies. And this affect not just obvious things like slower start-up and installation but also troubles with migration to testing and complications with library transitions. The latter sucks our precious manpower not just from package maintainer. Package maintainers can surely track problems to --as-needed if that's the case and here we have hope because many packages using it already for years successfully. Unless you are entangled in libraries ignoring usual best practises and ignoring library borders in their headers (libglib, libboost), there might be better solutions than --as-needed. I'd like to learn more about --as-needed alternatives. Could you suggest any resources/guidelines, please? That is not to say there might not be cases where --as-needed is the best solution, but it is definitely not something one should apply blindly. Indeed. But this seems to be more like risk management and less like informed technical decision. (I wonder what makes Ubuntu taking the risk applying --as- needed to everything?) Surely there must be software incompatible with --as-needed. But what are the chances to experience it? How to identify situation when --as-needed is likely to cause troubles? Regards, Dmitry. -- 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/201202111249.36777.only...@member.fsf.org
Re: How to convince maintainer to use --as-needed?
On Sat, 11 Feb 2012 11:38:23 Paul Wise wrote: The --as-needed flag is a workaround for buggy upstream build systems, IMO it should not be used unless the relevant build systems will not be fixed any time soon. Seems like a typical case with GNOME project stuff. Do you know if there are something what might contribute to potential problems with --as-needed, like outdated toolchain? So far we're reluctant to use --as-needed where it may be beneficial because in theory it might break something. However what's the practical likehood of that? Do we know any particular example of --as-needed incompatibility to look into and analyse? Regards, Dmitry. -- 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/201202111257.38792.only...@member.fsf.org
How to convince maintainer to use --as-needed?
Dear mentors, I seek your advice regarding the best practice with using --as-needed. Recently I tried to convince two package maintainers to use --as-needed in order to reduce overlinking. Surprisingly this time this idea was opposed with great resistance as none of maintainers but me had previous experience with -- as-needed. Because in their eyes I have neither expertise nor reputation I couldn't convince them that benefits are outweight risks. (--as-needed removes dozen of packages from Depends) I've been asked to provide a document or a quote from reputable DD regarding using --as-needed as recommended practice in Debian, if such. So here am I asking for your expertise. Thank you. Those who interested might read the following document describing the problem and the solutions. https://wiki.mageia.org/en/Overlinking_issues_in_packaging (Links to Debian mail list discussions in the end of this document are worth reading as well.) All the best, Dmitry. P.S. does anyone knows good examples of debian package using --as-needed? -- 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/201202101717.59933.only...@member.fsf.org
Bug#659045: RFS: goplay (NMU)
Package: sponsorship-requests Severity: normal Dear mentors, NMU for package goplay is looking for a sponsor. (See attached debdiff output) # GoPlay! is a Graphical User Interface (GUI) that uses DebTags for easily finding games in Debian. The program uses FLTK for handling the widgets, and libept as the backend for retrieving the data. . GoPlay! is also a generic yet simple to use DebTags-based package browser. Prepackaged browsers GoLearn!, GoAdmin!, GoNet!, GoOffice!, GoSafe!, GoWeb! and GoScience! show applications (and for some of them also documentation) packages related to education, administration, network, office, safety, web and science. You can also roll your own custom browsers using commandline options. # * Source package URL : http://mentors.debian.net/debian/pool/main/g/goplay/goplay_0.4-1.1.dsc * Package name: goplay * Version : 0.4-1.1 * debian/changelog: goplay (0.4-1.1) unstable; urgency=low * Non-maintainer upload. * Packaging update: - removed dh-buildinfo, autotools-dev + added missing build-deps, dh-autotools; build-deps optimised + compat and debhelper to version 9 + default hardening (with the exception of fortify) + standards to 3.9.2 + ept-cache replaced with apt-xapian-index in Depends (Closes: #615495 important:goplay must be run as root at least once to function) (Closes: #460921 wishlist:requires manual ept-cache reindex on the first start) + games-thumbnails moved to Recommends (Closes: #470047 wishlist:please Recommends: games-thumbnails instead of Depends) + no longer depends on g++-4.5 (Closes: #654733 important:non-standard gcc/g++ used for build...) + build-time .xpm icon regeneration, no longer ship pre-built icon (imagemagick added to build-deps) * patch to introduce 'goscience' browser, thanks to Frederic Daniel Luc Lehobey (Closes: #474603 wishlist:Please add a goscience browser) * debian/copyright: + updated list of contributors + little correction for DEP-5 compliance To access further information about this package, please visit the following URL: http://mentors.debian.net/package/goplay Cheers, Dmitry. diff -Nru goplay-0.4/debian/changelog goplay-0.4/debian/changelog --- goplay-0.4/debian/changelog 2010-06-25 18:37:46.0 +1000 +++ goplay-0.4/debian/changelog 2012-02-08 03:15:17.0 +1100 @@ -1,3 +1,33 @@ +goplay (0.4-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Packaging update: +- removed dh-buildinfo, autotools-dev ++ added missing build-deps, dh-autotools; build-deps optimised ++ compat and debhelper to version 9 ++ default hardening (with the exception of fortify) ++ standards to 3.9.2 ++ ept-cache replaced with apt-xapian-index in Depends + (Closes: #615495 important:goplay must be run as root at least + once to function) + (Closes: #460921 wishlist:requires manual ept-cache reindex on + the first start) ++ games-thumbnails moved to Recommends + (Closes: #470047 wishlist:please Recommends: games-thumbnails + instead of Depends) ++ no longer depends on g++-4.5 + (Closes: #654733 important:non-standard gcc/g++ used for build...) ++ build-time .xpm icon regeneration, no longer ship pre-built icon + (imagemagick added to build-deps) + * patch to introduce 'goscience' browser, +thanks to Frederic Daniel Luc Lehobey +(Closes: #474603 wishlist:Please add a goscience browser) + * debian/copyright: ++ updated list of contributors ++ little correction for DEP-5 compliance + + -- Dmitry Smirnov only...@member.fsf.org Wed, 08 Feb 2012 01:08:17 +1100 + goplay (0.4-1) UNRELEASED; urgency=low [ Peter De Wachter ] diff -Nru goplay-0.4/debian/clean goplay-0.4/debian/clean --- goplay-0.4/debian/clean 1970-01-01 10:00:00.0 +1000 +++ goplay-0.4/debian/clean 2012-02-08 02:49:34.0 +1100 @@ -0,0 +1 @@ +goplay.xpm diff -Nru goplay-0.4/debian/compat goplay-0.4/debian/compat --- goplay-0.4/debian/compat 2010-06-25 17:58:22.0 +1000 +++ goplay-0.4/debian/compat 2012-02-08 01:08:35.0 +1100 @@ -1 +1 @@ -7 +9 diff -Nru goplay-0.4/debian/control goplay-0.4/debian/control --- goplay-0.4/debian/control 2010-06-25 17:59:44.0 +1000 +++ goplay-0.4/debian/control 2012-02-08 02:47:24.0 +1100 @@ -6,16 +6,16 @@ Miriam Ruiz little_m...@yahoo.es, Enrico Zini enr...@debian.org, Jonas Smedegaard d...@jones.dk -Build-Depends: debhelper (= 7.0.50~), autotools-dev, - g++-4.5 | c++abi2-dev, dh-buildinfo, pkg-config, - libept-dev (= 1.0), libept-dev ( 2), - libwibble-dev (= 0.1.9), libwibble-dev ( 0.2), - libfltk1.1-dev, fluid -Standards-Version: 3.8.4 +Build-Depends: debhelper (= 9), dh-autoreconf, pkg-config, + libept-dev, libwibble-dev, libfltk1.1-dev, libtagcoll2-dev + ,imagemagick +#, fluid +Standards-Version: 3.9.2 Package: goplay
Re: Bug#659045: RFS: goplay (NMU)
Hi Arno, On Wed, 8 Feb 2012 04:10:48 Arno Töll wrote: + compat and debhelper to version 9 + default hardening (with the exception of fortify) + standards to 3.9.2 + ept-cache replaced with apt-xapian-index in Depends We don't do such things in NMUs. *Sometimes* we do. The options are: * QA : Not in this case since the package is team-maintained. * Team : Looks like best option, but I'm not the team member so I can't upload on behalf of the team. * NMU: Certainly not an unreasonable option, read below. Of course team upload would be the best but because package hasn't been touched for years, I have reasonable concerns that either team is not active or they are busy with something more important. Normally I would send patches but in this case I found no public repository and not even upstream repository. Because for few years there were no activity regarding the package (neither package updates nor bug tracker activity) I think the NMU approach is reasonable. Changes in NMU are easy enough to acknowledge so whoever interested may just drop my work in DELAYED unless team would step in. (Closes: #615495 important:goplay must be run as root at least once to function) (Closes: #460921 wishlist:requires manual ept-cache reindex on the first start) + games-thumbnails moved to Recommends (Closes: #470047 wishlist:please Recommends: games-thumbnails instead of Depends) + no longer depends on g++-4.5 (Closes: #654733 important:non-standard gcc/g++ used for build...) + build-time .xpm icon regeneration, no longer ship pre-built icon (imagemagick added to build-deps) And neither most of that. I think sometimes you'd better consider common sense. I believe you're not saying don't do the best you can in NMU because that would be quite discouraging. There are enough teams out there who do not accept anything less than perfect. So I spent couple of hours doing those improvements and I've chosen to fix what I could and then walk away to address other problems. This provides more help regarding work needed and allow to use time effectively. Let me point out that your concerns regarding what can be done in NMU would be better considered in context of what's the best for the package and if the changes are good enough for upload. I've seen NMUs with bigger changes. NMUs are there to address problems aren't they? Also from technical prospective it is reasonable to use proven up-to-date packaging since outdated packaging often cause problems by itself. NMU should not be in the way of quality. Please keep NMUs minimally invasive and fix _very_ important bugs only (i.e. RC bugs or other important bugs which qualify for a NMU). See [1] [1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu I'm aware of that, thank you. Regards, Dmitry. -- 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/201202081110.55656.only...@member.fsf.org
Bug#659045: RFS: goplay (NMU)
Hi Charles, have you actually tried to contact the team ? I do not see messages from you in January or February on their mailing list. I did just before I noticed this message of yours, but I wrote to them after I placed the sponsorship request. :( Probably that's wasn't the best choice but I didn't expect an answer hence I decided to file NMU. I reckon I should have give them a chance to respond. Lesson learned. All the best, Dmitry. -- 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/201202081328.43442.only...@member.fsf.org
Bug#659045: RFS: goplay (NMU)
Hi Charles, On Wed, 8 Feb 2012 12:51:19 Charles Plessy wrote: have you actually tried to contact the team ? I do not see messages from you in January or February on their mailing list. How could I forget, I did contact them thought the Alioth request to join the team, where I mention the prepared NMU. But I give them almost not time to respond before RFS. (Due to low activity I didn't expect a soon response) Sorry for my impatience. Regards, Dmitry. -- 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/201202081336.08590.only...@member.fsf.org
Bug#659045: RFS: goplay (NMU)
Hi Charles, On Wed, 8 Feb 2012 13:51:42 Charles Plessy wrote: Alioth requests are a mess: when one admin answers, there is no notification to the other admins. As a consequence, it can happen that everyone expects the others to have answered. I recommend to contact the team on its mailing list. Thank you for this very useful information. Now I understand why sometimes it takes so long to process a join application. Cheers, Dmitry. -- 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/201202081413.22935.only...@member.fsf.org
Re: RFS: git2cl
Hi Paul, No worries and many thanks for all the troubles with git2cl. Sorry for missing the ChangeLog issue, perhaps I was so busy so I neglected to give the required attention to the package. I acknowledged your changes - much appreciated. Thank you. Cheers, Dmitry. On 04/02/12 13:37, Paul Wise wrote: On Sat, Jan 21, 2012 at 8:14 PM, Dmitry Smirnov wrote: http://mentors.debian.net/debian/pool/main/g/git2cl/git2cl_2.0+git200808271242-1.dsc Apologies for not getting to this sooner. The source package you uploaded does not have a ChangeLog file in it, IIRC you were going to add that. I took the liberty of regenerating the tarball and removing the stuff that deletes the ChangeLog file on clean. Most of the comments and blank lines in debian/watch are not needed, I deleted them. Uploaded, should be in NEW soon. Please integrate the debdiff below into your VCS: -- 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/4f2ce837.50...@gmail.com
Re: RFS: git2cl
Hi Paul, No worries and many thanks for all the troubles with git2cl. Sorry for missing the ChangeLog issue, perhaps I was so busy so I neglected to give the required attention to the package. I acknowledged your changes - much appreciated. Thank you. Cheers, Dmitry. On 04/02/12 13:37, Paul Wise wrote: On Sat, Jan 21, 2012 at 8:14 PM, Dmitry Smirnov wrote: http://mentors.debian.net/debian/pool/main/g/git2cl/git2cl_2.0+git200808271242-1.dsc Apologies for not getting to this sooner. The source package you uploaded does not have a ChangeLog file in it, IIRC you were going to add that. I took the liberty of regenerating the tarball and removing the stuff that deletes the ChangeLog file on clean. Most of the comments and blank lines in debian/watch are not needed, I deleted them. Uploaded, should be in NEW soon. Please integrate the debdiff below into your VCS: -- 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/4f2ce848.8020...@member.fsf.org
Re: ipset/xtables-addons
Hi Neutron, On 04/02/12 19:16, Neutron Soutmun wrote: Now when I had a look at your package I feel convinced that everybody will benefit from ipset separation. :) :) You did a good work. In the recent xtables-addons changelog for release v1.41 (2012-01-04) upstream states: == Changes: - Deactivate build of ipset-genl by default. I think the original ipset package can now take over, given there are a handful of kernels (2.6.39 onwards) that do not need patching. == So apparently even upstream is OK to ship ipset no longer as a part of xtables-addons. I came to the same conclusion. :) 0001-debian-copyright-correct-DEP-5-format-URL.patch: * I'm unsure to use http://dep.debian.net/deps/dep5; as lintian still warning with message: $ lintian --pedantic -i ipset_6.11-1_amd64.changes = 8 = P: ipset source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 ... ... = 8 = but I follow some mailing-lists threads, and they said that http://dep.debian.net/deps/dep5; could be used instead. BTW, applied. :) Thanks. The idea behind is to get rid of non-working link. It makes no sense whatsoever to have non-working link in format URL even if there is no lintian warning for it. Already pushed with a little bit more update to debian/changelog, please pull from the repository again. or get it from dget -x http://mentors.debian.net/debian/pool/main/i/ipset/ipset_6.11-1.dsc Looks good. :) Cheers, Dmitry. -- 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/4f2cf2ae.3050...@member.fsf.org
dh-buildinfo: is it useful?
Dear mentors, Does anyone know if using dh-buildinfo is still recommended practice or is it obsolete? When dh-buildinfo is useful and what could be a typical use case? Thanks, Dmitry. -- 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/4f2686ee.6040...@gmail.com
Re: dh-buildinfo: is it useful?
Thank you for confirming my suspicions. On 31/01/12 03:25, Paul Wise wrote: On Mon, Jan 30, 2012 at 8:02 PM, Dmitry Smirnov wrote: Does anyone know if using dh-buildinfo is still recommended practice or is it obsolete? When dh-buildinfo is useful and what could be a typical use case? For packages destined for the Debian archive it doesn't have much use since we have build logs. Its actively harmful for multi-arch too since build info is different between architectures. -- 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/4f275e64.3040...@member.fsf.org
