Re: How to specify a = X Y Depends (Was: Packaging GNU Health)
Hi all, Hi Emilien, On Sat, Nov 24, 2012 at 11:54:59AM +0100, Emilien Klein wrote: ... As a general question: If package A depends on a specific set of releases (like in this case Tryton 2.4.X), how do we usually handle the case where the libraries are updated before the package depending on the library? Should I depend on Tryton = 2.4 2.5? I assume that would generate conflicts once 2.6 is made available, but GNU Health still depends on an earlier version... I admit a quick search has not uncovered the answer how to express this Tryton = 2.4 2.5 relation correctly. So I ask on debian-mentors list for help. So what's wrong with using Conflicts: Tryton = 2.5? Best, Michael pgpP7UdqKUQW4.pgp Description: PGP signature
Re: Help with patching PackageKit for *BSD
Hi! I don't think this is the right place to request this help, but I don't know a better one at time... (RFH seems to be too big) The problem is the following: PackageKit (Debian package src:packagekit) recently became Linux-specific by accident, and I need someone who knows *BSD/portable-programming better than I do to make it compile on *BSD again. The problem is this code: http://gitorious.org/packagekit/packagekit/blobs/master/lib/packagekit-glib2/pk-spawn-polkit-agent.c On *BSD I get: pk-spawn-polkit-agent.c:24:23: fatal error: sys/prctl.h: No such file or directory compilation terminated. make[5]: *** [libpackagekit_glib2_la-pk-spawn-polkit-agent.lo] Error 1 [...] Well, the use of prctl is inherently unportable. So instead of having the forked agent set up a signal in case of death of the parent, install a proper signal handler right in the parent's code that kills all forked agents (so keep a container containing all agent pids) upon reception of a signal. Hope this helps, Michael pgpltAR8Xk7q0.pgp Description: PGP signature
Re: Help with patching PackageKit for *BSD
IIRC a process group will make the maintainence easier. You may want to check negative values in kill(2). [...] Yes, but if going this route make sure you set up your own process group - otherwise you might be killing your parent as well. Best, Michael pgpWik4D8FAKA.pgp Description: PGP signature
Bug#661570: reviewing
owner 661570 ! tags 661570 + pending thanks I'm now looking into this package. Best, Michael pgpb2p4LUb9cL.pgp Description: PGP signature
Bug#661570: Review of cvc3 2.4.1-1
Hi Chris, Many thanks for providing this updated package. I've finally managed to review it. In short, it's almost ready to be uploaded, but if possibly, could you fix a few minor glitches? The primary inspection of changes didn't turn up anything, but lintian notices a few minor issues. What primarily keeps me from doing the upload is the seemingly strange tar file (as that would stay in the archive until you release a new upstream version). Please just let me know once a new version was uploaded, I'll then do a brief re-inspection and will then upload. Best, Michael I: cvc3 source: tar-errors-from-source A lone zero block at 11280 I: cvc3 source: tar-errors-from-source A lone zero block at 11280 That's rather weird, should only occur if you used some broken software to build the original tar file. W: cvc3 source: format-3.0-but-debian-changes-patch $ diffstat debian/patches/debian-changes-2.4.1-1 configure | 227 ++ 1 file changed, 126 insertions(+), 101 deletions(-) It seems the configure file is rebuilt for some reason. This shouldn't really be necessary as you don't have any patches. W: cvc3 source: syntax-error-in-dep5-copyright line 96: Cannot parse line Copyright (c) The Regents of the University of California. Wrong indentation. W: cvc3 source: out-of-date-standards-version 3.9.2 (current is 3.9.3) It should be safe to upgrade to 3.9.3 without any changes. W: libcvc3-5-jni: postinst-has-useless-call-to-ldconfig W: libcvc3-5-jni: postrm-has-useless-call-to-ldconfig Maybe a bug in dh_makeshlibs? pgpOrDWBOEMVL.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi Hendrik, Dear mentors, I am looking for a sponsor for my package gogglesmm. This package contains a new upstream release of gogglesmm. It contains some bug fixes. Especially it fixes bug#656902. [...] Are you aware of the ongoing transitions that (also) concern gogglesmm? Looking at http://packages.qa.debian.org/g/gogglesmm.html it seems to be preferable not to upload at this time, unless well coordinated with the release team. Best, Michael pgpf9hMWBu1Am.pgp Description: PGP signature
Bug#660606: reviewing
owner 660606 ! tags 660606 + pending thanks pgpSTi0MFWTiu.pgp Description: PGP signature
Bug#658992: Reviewing
owner 658992 ! tags 658992 + pending thanks Hi, I'm now looking into this updated version of the package. Best, Michael pgpJlmxF0LH70.pgp Description: PGP signature
Re: Fwd: Why does lintian tell me this?
Hello everybody! When I'm running lintian on my almost finished package, it tells me: E: jailkit: duplicate-updaterc.d-calls-in-postinst jailkit E: jailkit: duplicate-updaterc.d-calls-in-postrm jailkit But why? I do not see anything duplicate there. You would need to look at the final result ... Here are the complete files: postinst #!/bin/sh #DEBHELPER# set -e if ! grep /usr/sbin/jk_chrootsh /etc/shells /dev/null; then \ echo /usr/sbin/jk_chrootsh /etc/shells ;\ fi if [ -x /etc/init.d/jailkit ]; then update-rc.d jailkit defaults /dev/null if [ -x /usr/sbin/invoke-rc.d ]; then invoke-rc.d jailkit start else /etc/init.d/jailkit start fi fi exit 0 [...] The #DEBHELPER# is there for a reason: it's for debhelper to put useful code in there. And that precisely will be this if [ -x /etc/init.d/jailkit ]; then ... fi bit. Just use #!/bin/sh set -e if ! grep /usr/sbin/jk_chrootsh /etc/shells /dev/null; then \ echo /usr/sbin/jk_chrootsh /etc/shells ;\ fi #DEBHELPER# and you should be fine. Same for your other file. Best, Michael pgpu2i4iQzxne.pgp Description: PGP signature
Re: RFS: cxxtest - xUnit-like framework for C/C++ applications
Hi Simone, [...] The headers contained in cxxtest-gui, cxxtest-gui-qt4 and cxxtest-gui-x11 can be used to create GUIs for each test suite. Probably the appended -gui can be misleading because users could suppose that they contain a GUI for cxxtest, but I couldn't find a better name. Any suggestion? Maybe really just remove the -gui in the package name and fix the description? [...] Besides that, a watch file would be nice. Just take a look at subversion's watch file to figure out how to handle tigris.org. I didn't create the watch file because the link to the upstream source is strange: http://cxxtest.tigris.org/files/documents/6421/43281/cxxtest-3.10.1.tar.gz and those numbers could change with the new releases. In addition none of the URLs - http://cxxtest.tigris.org/files/ - http://cxxtest.tigris.org/files/documents/ - http://cxxtest.tigris.org/files/documents/6421/ - http://cxxtest.tigris.org/files/documents/6421/43281/ are browsable and I couldn't create a watch file. I don't think a watch file with http://cxxtest.tigris.org/files/documents/\d+/\d+/cxxtest-([\d\.]+)\.tar\.gz will work. Am I wrong? Following the subversion example, this should work: version=3 http://cxxtest.tigris.org/servlets/ProjectDocumentList?folderID=9766expandFolder=9766 \ http://cxxtest.tigris.org/files/documents/\d+/\d+/cxxtest-([\d\.]+)\.tar\.gz But ok, that might depend on whether upstream retains 9766 as a good folderID (note that subversion has a folder Source Code to provide all the releases instead of creating one folder per release). Might require more discussion with upstream. Best, Michael pgp6qOvQNGK9k.pgp Description: PGP signature
Re: RFS: cxxtest - xUnit-like framework for C/C++ applications
Hi Simone, I am looking for a sponsor for my package cxxtest. [...] I've looked at your package and would be interested in sponsoring it's upload. Yet I'd first ask for a bit more information on two issues: - None of the source files contains license or copyright information. Yet even the included COPYING file highly suggests that: To apply these terms, attach the following notices to the library. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the copyright line and a pointer to where the full notice is found. Do you think you could convince upstream to get that fixed really soon? - Those packages: cxxtest-gui-qt4 - xUnit-like framework for C/C++ applications (Qt4 GUI for test-cases) cxxtest-gui-x11 - xUnit-like framework for C/C++ applications (X11 GUI for test-cases) seem to be almost empty, and I can't see why they actually ship a GUI - isn't it just a single header file each? (Plus suitable dependencies, of course, but adding them as Suggests to the main package doesn't feel too wrong.) Besides that, a watch file would be nice. Just take a look at subversion's watch file to figure out how to handle tigris.org. Best, Michael pgphpGjb7p9I3.pgp Description: PGP signature
Re: Alternative dependencies
Hi, [...] Which would you recommend? I'm leaning towards xmltoman. Although it depends on some perl packages they were all already installed when I installed it; I guess anything with dh already has a lot of perl stuff installed. xmltoman makes for a much simpler command than xsltproc. So does xmlto but it has a lot of dependencies that I don't normally have installed otherwise. I don't really have strong opinion about any of these packages, but your justification sounds highly sensible. Hence just go for xmltoman. Best, Michael pgpTvdeObIzSn.pgp Description: PGP signature
Re: Alternative dependencies
[...] Build-Depends: xsltproc | xmltoman | xmlto, docbook-xsl | xmltoman | xmlto This would be a correct rewrite to CNF, but ... Or would it be better to choose one and stick to that for the sake of consistency? ... there isn't much of a point doing it here for Build-Depends. The situation is definitely a different one for Depends, but for Build-Depends just go for one of the choices, in the interest of both consistency and simplicity. Best, Michael pgpiYY20JvEIG.pgp Description: PGP signature
Re: RFS: spotweb (updated version with dfsg source, please review)
Michael and others, I've again uploaded a new version to mentors. The main reason is that upstream has (on my request) started tagging releases. That makes the version numbering so much nicer... The latest .dsc is at http://mentors.debian.net/debian/pool/main/s/spotweb/spotweb_20111002+dfsg-1.dsc Could you please have a look at the new version and, if it looks good enough, sponsor its upload? [...] I hope not to have missed anything this time 'round. Package looks fine to me. Built and just uploading. Best, Michael pgpLxxAtMLYrK.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi, Dear mentors, I am looking for a sponsor for my package gogglesmm. [...] Thanks for updating the package. I've reviewed the changes and uploaded a new version. Best regards, Michael pgpPkF2Esa7SR.pgp Description: PGP signature
Re: Fwd: RFS: kpartsplugin (updated package)
Hi Michele, (added debian-mentors in CC, hope that's ok) Hi I'm forwarding the RFS I sent on debian-mentors for updated kpartsplugin package, as I didn't quite get how the sponsorship works probably, so I'm unsure if i should have written to you as original sponsor for the package, or if it's normal/necessary to write on debian-mentors every time package is updated. [...] I've built and uploaded your package - sorry for taking so long to respond. Yet there is one lintian warning to be addressed in future uploads: W: kpartsplugin source: syntax-error-in-dep5-copyright syntax error in section 4 after the tag license: You may use this file under the terms of the BSD license as follows:\n Thanks a lot for your work, Michael pgpnj9Ytkzq2Z.pgp Description: PGP signature
Re: Re: Fwd: RFS: kpartsplugin (updated package)
Hi, [...] Also, there is another thing I'd like to edit, but I'm unsure how to do so. The package is a plugin that works with some different browsers (Firefox, Opera, Chrome among them). At the moment, though, I've changed the CMakeLists so that the plugin is only installed in Firefox's plugins dir (instead of a generic /usr/lib/nsplugin). What would be the best way to install it for other browsers too? Is it best to install the same file in the correct directories (adding rules to CMakeLists I guess), or to instead use symlinks (and in such a case, should the real file be in /usr/lib/nsplugin, in /usr/lib/mozilla/ or elsewhere?)? [...] I'm by no means an expert on browser plug-ins; but you will definitively want to use symlinks. For the primary location it's probably best to take a look at other cross-browser plug-ins. Best, Michael pgpREBTcMBcMN.pgp Description: PGP signature
Re: RFS: bftpd - Very configurable small FTP server
Hi, [...] bftpd - Very configurable small FTP server [...] Could you please help to clarify why we need yet another FTP daemon in Debian? Many thanks, Michael pgpLz2FlEMgA3.pgp Description: PGP signature
Re: spotweb_0~20110903+gitab1d95b4-1_i386.changes REJECTED
[...] In this case I would get upstream to remove them from git and generate the compressed versions during the Debian package build process. If upstream doesn't want to remove the compressed versions from git then your get-orig-source target should remove them when creating a tarball for Debian. +1 Jan-Pascal, please prepare a version built in this way, I will then take another look at it and sponsor its upload. Best, Michael pgpCZMlnVnKIt.pgp Description: PGP signature
Re: Tracking RFSs as bugs
[...] The BTS provides a good way to track requests. But mentors.d.n does, too. On the other hand, the BTS doesn't have a useful interface to search, filter and sort RFSes based on various criterias, such as: - is the package already in Debian? (sponsoring a second upload is easier) - did I sponsor the previous upload? - is the package related to Ruby (easy to determine by grepping build-depends and depends) - ... What about usertags and usercategories? I believe the BTS could do a really good job here if used in the right way. all of this can easily be implemented on mentors.debian.net, but cannot be added to a BTS pseudo-package. So I don't see the point of using a BTS pseudo-package instead of mentors.d.n. (I also don't see the point of using mentors.d.n together with a BTS pseudo-package.) In my opinion the BTS and mentors.d.n could serve two somewhat distinct parts of the process: clearly we need a space that packages can be uploaded to. Indeed the BTS would do poor job if source packages got uploaded as attachments to the BTS. On the other hand, the BTS is an excellent platform to track sponsoring progress, making all the comments over time available in a single bug log. Additionally, it's very important to note that not all packages should eventually be uploaded, so the fact that some packages never get sponsored is a feature. Debian doesn't want to contain every piece of free software ever written, because some of them have better alternatives already in Debian, for example. How would you deal with that with a BTS pseudo-package? After some time, there will be a few hundred RFSes that should never ever be uploaded to Debian, but are still open. Who gets to decide that they can be closed? As Arno outlined before, all we would see here is an improvement (if any change) - who is it that gets to decide now? Its the community and the decision is communicated by not responding to (possibly repeated) RFS. With the BTS, this could be tagged as wontfix. In some earlier email I stated that we should probably come up with a dedicated sponsoring team that gets to handle the bureaucratic bits. It would, IMHO, then be this team's work to close such bugs from time to time. Best regards, Michael pgpQBxF11mPlr.pgp Description: PGP signature
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
Hi Chris, [...] I would very much appreciate your help. May I email you? I wouldn't claim I could answer all your questions, especially when it comes to games-specific ones, but at least I'll try my best to help. So yes, please go ahead. Best, Michael pgp6wMMNMscgR.pgp Description: PGP signature
Re: Tracking RFSs as bugs
I'm concerned that this might turn out about as useful as filing an RFP bug against wnpp; not very useful at all. Hmm, not sure - after all, people are still free to remind potential sponsors about outstanding RFS via debian-mentors. Well, and with such a new tracking possibility, e.g., sprints could be organized from time to time. We'd definitively need some more formal assignment of responsibilities for sponsoring. People assigned those responsibilities are required to ask for help from time to time, organize such sprints, send pings for open RFS tagged more-info (or close them), work closely with the authors of debexpo, and probably some other tasks that go beyond the basic step of sponsoring uploads. Best, Michael pgpyEJzCB5alJ.pgp Description: PGP signature
Re: Becoming DM [was: Re: Tracking RFSs as bugs]
Hi Chris, [...] I think what I meant was that part of the social contract, if I understand correctly, is that we're all here to become DMs/DDs, not just to get our packages uploaded by someone else and walk away. So why is it that DDs sponsor packages and not people? In the ideal case, and this is largely where I started my sponsoring activities from, I'd only mentor a few people. Indeed I used to have (and sometimes still have) a lot more interaction with the people behind those packages than just the occasional uploaded. email. I used to ask people what their long-term intentions were, tried to understand their background, etc. It was around the 4-days-proposal that I decided to trade quality for quantity. Sadly, this trade off had to be made. I'd still be happy to mentor (more) people if someone were interested in getting into this mentoring relationship; but so far most people seemed just happy with getting their package uploaded, apparently not caring about more than that. Debian has a steep learning curve - I've been running several Debian systems for ~9 years, packaging for ~2.5 years and still have tons to learn. I would greatly appreciate the ability to correspond with someone about issues which arise for me *before* I have a package ready for review - or even which are only tangentially related to my package(s) but relevant to my broader understanding of Debian and the journey towards DM. As said above: I for one would be perfectly fine to offer this kind of mentoring to you. I'm not sure whether you had ever had a negative answer to such a request for mentorship - have you ever asked for it (before)? FWIW I'd support the use of the BTS for tracking RFSs. For new packages, couldn't it be as simple as tagging ITP bugs as packaged, uploaded and awaiting review? (Not sure about upgrades.) I believe the workflow could be implemented as simply reassigning the ITP to the proposed mentors.debian.(org|net) pseudo-package. No need for extra tagging, it would all come for free. Best, Michael pgpsmfcOmc95i.pgp Description: PGP signature
Re: RFS: xxxterm
Hi, [...] I've just uploaded a new package containing a rule that converts the icon into an xpm file. It removes the lintian error, making the package lintian clean. Here's the link to the package: http://mentors.debian.net/debian/pool/main/x/xxxterm/xxxterm_1.518-1.dsc [...] Built, signed, and uploaded. Thanks a lot for your work, Michael pgp3d0J0hImwd.pgp Description: PGP signature
Re: Tracking RFSs as bugs
Hi Michael, hi all, (keeping Don CC'ed) [...] I've noticed that the release team has a lot of success addressing their issues in a rather timely manner. I think that this success comes from the fact that they treat all of the items they need to accomplish as bugs [0]. So, as requests get old, they notice that and do something about it (or they just close it out if the submitter isn't responsive). [...] I'm all for tracking RFS in some more formal way, it would quite a bit reduce the load on my inbox (which I'm currently using for tracking). There is one fundamental difference, however, to, e.g, the release team: there is no *team*. Who are they in case of sponsoring? What makes the situation worse is that the number of people filing RFS is unbounded, this process is open to everyone (don't get me wrong, this is a good thing in general). I don't think technical infrastructure alone will solve those problems. In fact, mentors.debian.net would already have all the necessary infrastructure: packages are uploaded there and hence tracked. It is possible to leave comments, and maybe this whole RFS business should just move over to mentors.debian.net. Oh, and with all this moaning about RFS not being dealt with in a timely manner: true, we don't manage to get packages reviewed and sponsored within 4 days, but is the situation really that bad at the moment? Are there any packages older than one month still waiting for sponsorship? Best, Michael pgpThnq9RAMkD.pgp Description: PGP signature
Becoming DM [was: Re: Tracking RFSs as bugs]
Hi, [...] No moaning from me btw - I am sure there are many more RFSs than there are sponsors. I just wish it wasn't so hard to reach DM. [...] Could you please be more precise about that last bit? What exactly is hard about becoming DM? I really wish more people applied for DM. Sponsoring the same package more than a few times makes little sense in most cases (there are exceptions, and I for one are regularly sponsoring at least one such exception). Best, Michael pgpYNApHKtMWq.pgp Description: PGP signature
Re: Tracking RFSs as bugs
Hi, [...] This is not a new idea: http://lists.debian.org/debian-mentors/2002/08/msg00262.html Thanks a lot for the pointer, indeed this is an interesting read (well, the technical part of that). [...] I can't talk to debexpo using my MUA. This is a big no-go for me. Fully agreed. [...] I'll continue in another subthread, just wanted to note those bits here. Best, Michael pgpnFqr7gxeM6.pgp Description: PGP signature
Re: RFS: xxxterm
Hi, [...] E: xxxterm: menu-icon-not-in-xpm-format usr/share/xxxterm/xxxtermicon32.png If that could be fixed, the package should be ready to be uploaded. Thank you for your review. As the png files within the package are provided by upstreams, I thought it would be OK to keep them. What's the usual way to correct this error? Coverting them to xpm files? [...] It's ok to keep the file, but you can't use it as-is. I think a conversion during package build is the easiest solution and AFAIK other packages do so as well. Best, Michael PS.: Others might be able to comment on new icons, or maybe ask on some more specific list such as debian-desktop. pgpsxUbHpYsNO.pgp Description: PGP signature
Re: RFS: fizsh
Hi Guido, Dear Michael, and other mentors, Thank you very much for reviewing my package! I corrected the errors you spotted. I also added a lintian-override file to suppress the lintian hyphen-used-as-minus-sign tag. (This override-file will not be needed anymore when Upstream releases a newer version of fizsh.) [...] I understand that you fixed some of these errors, but - why not fix the hyphen-used-as-minus-sign via a patch instead of overriding the warning? Overriding a correct warning for the mere reason of silencing lintian seems to be of no use. - The tar.gz file differs in the same way it did before. Why don't you use exactly the file that can be downloaded from sf.net? Best, Michael pgpJMJtrWo606.pgp Description: PGP signature
Re: decibel-audio-player
Hi, [...] I need assistance for configure svn (last config doesn't work), i saw http://wiki.debian.org/Alioth/Svn but, i confused with this, and how to update package in alioth :) You might want to contact the Python Apps packaging team directly, but most likely your project membership should immediately give you (write) access to the subversion repository. I suppose you have already read http://wiki.debian.org/Teams/PythonAppsPackagingTeam/HowTo which provides more appropriate information for your use case then the URL you cited. Hope this helps, Michael pgp3CYQIaNIFR.pgp Description: PGP signature
Re: RFS: fizsh
Hi Guido, I fixed the two remaining issues (added a patch for the man page, and used dput to upload the original version of fizsh_1.0.2.orig.tar.gz). [...] Thanks a lot for this quick update. I've checked the changes, built the package, signed, and uploaded it. Thanks a lot for your work, Michael pgp8KL6pGGF24.pgp Description: PGP signature
Re: RFS: fizsh
Hi, I am looking for a sponsor for my package fizsh. [...] I've reviewed your package fizsh and have the following comments: - .orig.tar.gz differs from upstream: aclocal.m4 |4 configure | 328 ++--- 2 files changed, 147 insertions(+), 185 deletions(-) - No need to depend on coreutils, it is essential. - debian/docs is empty - (You had already noted yourself the hyphen-used-as-minus-sign.) Other than the above, the package looks really fine. The first item (differing orig.tar.gz), however, is a show stopper. Best, Michael pgpxEYbuN2kE3.pgp Description: PGP signature
Re: RFS: assimp (3rd try)
Hi, Dear mentors, sponsors and fellow Debianistas, here is my third attempt to find a sponsor (or more reviewers) for my package assimp. [...] Package built, signed, and uploaded. Will be sitting in NEW now. Best, Michael pgp3CYWHaluU9.pgp Description: PGP signature
Re: RFS: spotweb (third version)
Hi Jan-Pascal, On my request, upstream has added an explicit LICENSE file detailing the (BSD-3-clause) license. Up to now, the license wasn't in the source package itself. I've also changed to packaging to use debhelper instead of cdbs. The new .dsc is at http://mentors.debian.net/debian/pool/main/s/spotweb/spotweb_0~20110818+git9fcd44c4-1~pre2.dsc [...] I've taken a look at your package and have the following comments: - debian/compat says 5 but your require debhelper 8 in debian/control. - I don't see where you migrated to debhelper from cdbs!? - Please try to convince upstream to produce release tags - using git SHA1 in version numbers means that essentially you can only do a single release on any given date. Other than the above, your package looks pretty ok. In your changelog, however, you indicate that this packaging is preliminary. I suppose the next version will be a releasable one!? Best, Michael pgp4ra1LMSY6N.pgp Description: PGP signature
Re: RFS: libharu (updated package)
Hi, [...] I am looking for a sponsor for the new version 2.2.1-1 of my package libharu. [...] Looks good. Built, signed, and uploaded. Best, Michael pgpwxxdN84WF6.pgp Description: PGP signature
Re: RFS: gkrellm-gkrellmpc
Hi, I am looking for a sponsor for my package gkrellm-gkrellmpc. * Package name: gkrellm-gkrellmpc Version : 0.1~beta10-2 Upstream Author : Mina Naguib webmas...@topfx.com * URL : http://mpd.wikia.com/wiki/Client:GKrellMPC * License : GPL-2 Section : sound [...] Thanks a lot for this update. Built, signed, and uploaded. One request for future uploads, though: please include a watch file. In my opinion, this should be reasonably easy by using http://mina.naguib.ca/dist/ as a watch space. Best, Michael pgpAN9e3ieyPM.pgp Description: PGP signature
Re: RFS: presage (updated package)
Hi Matteo, [...] I would be glad if someone uploaded this package for me. Done. Thanks a lot for this update, Michael pgpHJU4dX8bKp.pgp Description: PGP signature
Re: experimental or unstable
Hi, [...] You're probably thinking if I'm making a new release already it can't be that stable! But only one of the changes relates to something specific to roxterm 2, and it's to make a new feature optional rather than to fix a bug https://sourceforge.net/tracker/?func=detailaid=3365527group_id=124080atid=698431. It also closes a bug in previous unstable releases (#639687). It's in almost all cases completely up to you to decide whether a package is ready to go in unstable or not (and should go in experimental instead). Best, Michael pgpxAhRZNtpx4.pgp Description: PGP signature
Re: RFS: qmpdclient
Hi, I am looking for a sponsor for my package qmpdclient. * Package name: qmpdclient Version : 1.2.2-1 Upstream Author : Voker57 voke...@gmail.com * URL : http://bitcheese.net/wiki/QMPDClient * License : GPL-2+ Section : sound [...] This package looks ok, although it would be nice if upstream could add license and copyright information to a number of source files missing such information. Two more issues to be addressed in forthcoming uploads: - The binary lacks a man page. - The package description could include some text about mpd in general. Package built, signed, and uploaded. Best, Michael pgptCEqN40SHx.pgp Description: PGP signature
Re: RFS: xxxterm
Hi, I am looking for a sponsor for my package xxxterm. * Package name: xxxterm Version : 1.518-1 Upstream Author : Several (Marco Peereboom ma...@peereboom.us) * URL : http://opensource.conformal.com/wiki/XXXTerm * License : ISC, MIT, BSD-4-clause, BSD-3-clause, BSD-2-clause, CC-BY Section : web [...] The package looks mostly fine, except for one major error (as also reported by lintian): E: xxxterm: menu-icon-not-in-xpm-format usr/share/xxxterm/xxxtermicon32.png If that could be fixed, the package should be ready to be uploaded. Best, Michael pgpN8qfsiTfZD.pgp Description: PGP signature
Re: RFS: spotweb (third version)
Hi Jan-Pascal, [...] As far as I'm concerned, yes. The new version is on mentors, the .dsc is at http://mentors.debian.net/debian/pool/main/s/spotweb/spotweb_0~20110903+gitab1d95b4-1.dsc By the way, I'm a Maintainer, and I've set the DM-Upload-Allowed flag on this package. Hope you agree to that. [...] That's fine. Package reviewed, built, signed, and uploaded. Best, Michael pgpGILD3TAk7x.pgp Description: PGP signature
Re: RFS: assimp
Hi again, On 08/19/2011 01:31 AM, Michael Tautschnig wrote: I'm wondering whether it would make sense to remove other cruft as well - basically contrib/ entirely and workspaces could go as well. And, well, I think might be a good idea, thanks. when i did it, i mainly removed the MUST (test/models_nonfreebsd), and _some_ obvious ones... I completely agree that the principal idea should be stripping only the DFSG-incompatible stuff, but here there may be added value of both saved space and a guaranteed clean build: if, e.g., contrib/zlib/ isn't there, it can't be unintentionally used :-) +dfsg would be preferable over ~dfsg, but you might have good reasons for your choice? im using that because in the pkg-multimedia team (where i partake), we use ~. [...] (interesting statistics) I think the only potential problem is weird version numbers in cases where a backport or security uploads come into play. We've had this issue in clamav and hence moved to +dfsg ever since. But thanks a lot for providing those nice statistics and I believe it's just fine if you go with the pkg-multimedia line. [...] i checked with upstream and they assure me, that _all_ code is under BSD(3 clause), and that the 4 files mentioned are wrongly flagged as LGPL. what is the proper way to proceed from here? - waiting for new upstream to fix these issues (i have been waiting for a new upstream for 5 months now; and while they are active, it might take a long time for them to do a proper release, so i hope to not have to do that) - add a debian/patches/fix_licenses.pach to fix the license according to what upstream says - fix debian/copyright to make everything BSD-3 and eventually add some notice that this is in accordance to what upstream says. I think it would be ok to simply quote upstream's email (after asking for permission, if it was a private conversation at least) in debian/copyright. Patching license/copyright information always feels a bit strange. [...] - Upstream seems to ship tests; it would be nice if those were run at build time. (But using Debian's cppunit, not the home-grown one in contrib/.) i will have a look. the tests mainly use the supplied model data, and a lot of models are stripped away for dfsg reasons. i was also thinking of stripping away the (free) models as well, as they currently do not appear in any binary package and take 40MB or so of disk space. adding tests would then make at least _some_ use of those models. [...] Hmm, indeed it seems sensible to strip such large and useless files. Yet tests are definitively good to have, personally I'd strongly prefer tests over smaller source packages. Best, Michael pgpTG4whtchJ5.pgp Description: PGP signature
Re: RFS: mspdebug
Hi all, [...] It builds these binary packages: mspdebug - free debugger for use with Texas Instruments MS430 MCUs The package appears to be lintian clean. The upload would fix these bugs: 637345 [...] As noted in the (already closed) bug 637345, this package is in Debian already and owned by a different person. Best regards, Michael pgpb4E6T452P8.pgp Description: PGP signature
Re: RFS: acsccid
Hi, Dear mentors, I am looking for a sponsor for my package acsccid. This release is to correct the udev rules filename (debian/libacsccid1.udev) to fix the problem that the udev rules file was not added to the package. The udev rules file is required by the latest pcscd. The smart card readers will not work if this file does not exist. [...] Thanks a lot for this update. Package built, signed, and uploaded. Best regards, Michael pgp3HEH8CVqXs.pgp Description: PGP signature
Re: RFS: kbdd
Hi Stas, The package is again available on mentors.debian.net website. Could someone please review and upload it if everything is ok? I've built, signed, and uploaded your package as-is. Yet the following issues should be resolved with future uploads: - I: kbdd: hyphen-used-as-minus-sign usr/share/man/man1/kbdd.1.gz:38 - The upstream sources seem to be unclean as there is m-kbdd-service-marshal.o in src/dbus/. Please make sure upstream gets their build process sorted. Thanks a lot for your work, Michael pgpAHNHaMAEx7.pgp Description: PGP signature
Re: RFS: assimp
Hi, Dear mentors, sponsors and fellow Debianistas, I am looking for a sponsor for my package assimp. * Package name: assimp Version : 2.0.863~dfsg-1 Upstream Author : ASSIMP Development team * URL : http://assimp.sf.net * License : BSD (3-clause) Section : graphics Thanks a lot for looking into packaging this software. Definitively not the easiest one... [...] the package uses cdbs for packaging. If you must. the package has been repackaged to strip away non-dfsg parts from upstream tarball. I'm wondering whether it would make sense to remove other cruft as well - basically contrib/ entirely and workspaces could go as well. And, well, I think +dfsg would be preferable over ~dfsg, but you might have good reasons for your choice? i someone would be willing to have a look at it, i would be very thankful. i would especially like to hear comments on the following topics: - repackaging (for dfsg-compliancy) See above. Plus some missing copyright information: please check code/pstdint.h, code/BoostWorkaround/boost/tuple/tuple.hpp, code/MDCNormalTable.h. Remove the LGPL'ed code from tools/assimp_view/ or make upstream ship a proper license. This is a requirement of LGPL 4b), which I believe is what applies here. Obviously debian/assimp-utils.lintian-overrides then isn't needed anymore. - the debian/libassimp2.symbols file Please consider using the c++ tag after having applied c++filt; see several recent threads on debian-mentors, e.g., [1]. - python bindings package - D bindings package - ... I'm neither an expert on python nor D packaging, hence I'll leave this bit to others. Yet I do have further comments: - Package FTBFS: dpkg-source -b assimp-2.0.863~dfsg dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building assimp using existing ./assimp_2.0.863~dfsg.orig.tar.gz dpkg-source: error: unwanted binary file: debian/copyright_hints dpkg-source: error: detected 1 unwanted binary file (add it in debian/source/include-binaries to allow its inclusion). - Upstream seems to ship tests; it would be nice if those were run at build time. (But using Debian's cppunit, not the home-grown one in contrib/.) Hope this helps, Michael [1] http://lists.debian.org/debian-mentors/2011/07/msg00632.html pgpBZG3KtjIEe.pgp Description: PGP signature
Re: Dependency problem
[...] You can use something as ugly as: Depends: python-wxgtk2.8 | python-qt4 | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4 | python-fltk | python-gtkglext1, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtk2, python-wxgtk2.8 | python-qt4-gl | python-fltk | python-gtkglext1 [...] Perhaps I'll just force the user to install the WX frontend, and list the all others as suggested packages... Given that python-qt4-gl already depends on python-qt4 the above list given by Jakub actually shrinks to half. This resulting two-liner doesn't seem too bad after all. Best, Michael pgpmvLYeX0ZvF.pgp Description: PGP signature
Re: News about the mentors.debian.net transition to upgraded software
Hi Asheesh, [...] If you upload a new package to mentors.debian.net before the end of Thu Aug 11, then your package might get lost. If you find that's the case, just re-upload it. Couldn't you put a big fat banner on mentors.debian.net during migration time? I've noticed that there is a short paragraph at the top of the page, but it really should be in all sorts of colours and bold. Oh, and couldn't the upload simply be disabled? Thanks a lot for all your work, Michael pgpDkuHK5nRpA.pgp Description: PGP signature
Re: RFS: wmmixer
Hi, [...] It builds these binary packages: wmmixer- mixer application designed for WindowMaker [...] Built, signed, and uploaded. Just one request though: would you mind speaking to upstream about getting their C-string handling straight (that is, introduce some const)? GCC keeps warning us: XPM/wmmixer.xpm:77:67: warning: deprecated conversion from string constant to ‘char*’ [-Wwrite-strings] Thanks a lot for your work, Michael pgpUmlz5WHwL4.pgp Description: PGP signature
Re: Doubt about library version
Hi, if one application has two packages in debian (Z and libZ), but in the new upstream release, the library does not exists, what's happend with the package libZ in debian? we need to close the library package? What do you mean by close here!? Furthermore, are you asking this question as the maintainer of the application or a user of libZ? Best, Michael PS.: I guess it would be helpful if you could name the package. pgp7SQ3iphrgU.pgp Description: PGP signature
Re: Doubt about library version
Hi, [...] the wmaker package includes some libraries in the upstream source. One of this libraries includes some files (WMaker.h and libMaker.*). This files are not in the source tree now (were removed from the git because they are not longer needed). Therefore, the package libwmaker0-dev doesn't include any files (only the documentation files README.debian,...), and then the package should not be included in future versions. I need to do something in the debian folder files? As a very first step you need to check for reverse depends, for instance by doing apt-cache showpkg libwmaker0-dev (on a sid system!). If no Reverse Dependencies are reported, you can remove the package from your control file, upload a new version, and then file a removal request. For much more information please see http://wiki.debian.org/ftpmaster_Removals Best, Michael pgpzUDeJAUQsq.pgp Description: PGP signature
Re: Adding symbols files to the tango package.
Hi, [...] Yes that is why I try to apply the generated patch and it does not work for exemple this hunk took from the armel architecture [...] as you can see the patch generated by dpkg-gensymbols can not apply. Indeed symbols are not ordered the same way ??? Maybe this is due to the c++ demangled symbols. Indeed symbol ordering may vary, but also there is no reason for dpkg-gensymbols to guarantee a particular ordering. Although dpkg-gensymbols produces a diff, this is surely not meant for you to apply directly as a patch: each change requires proper manual inspection to understand whether this is an intended change. The symbols file is not to be understood as a mere documentation/dumb list, rather it is a contract: as a package maintainer you guarantee that the listed symbols are provided. Best, Michael pgpQ2RQYCEF0t.pgp Description: PGP signature
Re: RFS: taxbird (updated package)
Hi Olaf, [...] I added NMU-diffs for the debian changes only, because I think adding the upstream diffs from libgeier 0.11 to 0.12 and taxbird from 0.15 to 0.16 don't add any value. [...] I suppose that's fine. I've now done the following: - Built libgeier and uploaded to DELAYED/5. - Fixed the build-dep of taxbird to use glade instead of glade-gnome as there is some semi-broken transition going on. Noted the change in the changelog. - Built and uploaded taxbird to DELAYED/7. Thanks a lot for your work and patience, Michael pgpmdEJHV0aE3.pgp Description: PGP signature
Re: RFS: l2tp-ipsec-vpn
Hi Werner, [...] I've taken another look at your package. For reference, I've used http://mentors.debian.net/debian/pool/main/l/l2tp-ipsec-vpn/l2tp-ipsec-vpn_1.0.0-1.dsc dated 29-Jul-2011 09:46. The first thing I stumbled upon was the orig.tar.gz that doesn't match the upstream one. Not only do md5sums differ, but the actual contents does: (... diffstat output) 125 files changed, 116 insertions(+), 404 deletions(-) Although these changes only concern revision control ids, it is IMHO not acceptable to have orig.tar.gz differ in such a way from upstream's tar.gz. Further comments: - The description is clearly improved and the first stanza is appropriate; others, however, should probably only go in some README file. Please see Debian Policy about this, Section 3.4, which provides a very nice guideline what should (not) be included. (http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions) - debian/postinst: * service rsyslog restart || true -- no, there is no service command in general in Debian. And why restart a foreign service!? * Why use gksu when su should do the trick? I really wouldn't want to do system administration remotely with GUI su popping up. - The package build-depends on (and indeed appears to require) libopensc2-dev, which unfortunately is no longer available in Debian. Could you find a way around that, given that you are upstream? Otherwise please speak to the opensc maintainer in Debian about this. Thanks a lot for your work, Michael pgpEneVgXRNic.pgp Description: PGP signature
Re: RFS: acsccid (Updated)
Hi, Dear mentors, I am looking for a sponsor for my package acsccid. Actually, I posted the request about 1 month ago and I did not receive any response here. The package had been updated and fix the following problems: 1. The project is hosted in sourceforge now and watch file is updated. 2. Remove dh_makeshlibs from rules file. 3. Fix non-redistributable reference manual problem. * Package name: acsccid Version : 1.0.2-1 Upstream Author : Advanced Card Systems Ltd. * URL : http://acsccid.sourceforge.net/ * License : LGPL-2.1 Section : libs It builds these binary packages: libacsccid - PC/SC driver for ACS USB CCID smart card readers The package appears to be lintian clean. [...] This may be true, but it doesn't build :-/ Well, to start out in proper order, here's my review results: - Please use DEP-5 format for debian/copyright and please make extra-sure you don't miss any copyright holders as the package seems to have quite a number of them. DEP-5 format will make this much easier to check. - You probably want to add a Depends: on udev instead of merely recommending it in some README file. - configure yields the following result: ... udev support:no ... I'm not sure this is intended. - Your package fails to build from source: ifdhandler.c: In function ‘IFDHControl’: ifdhandler.c:1416:22: error: ‘FEATURE_MCT_READERDIRECT’ undeclared (first use in this function) ifdhandler.c:1416:22: note: each undeclared identifier is reported only once for each function it appears in make[3]: *** [libacsccid_la-ifdhandler.lo] Error 1 make[3]: Leaving directory `/home/tautschnig/debian/acsccid/acsccid-1.0.2/src' Please get those fixed, then another more thorough package review will follow. Best, Michael pgp05k30TMWKV.pgp Description: PGP signature
Re: Adding symbols files to the tango package.
Hi Frédéric, I just added the symbol files to one of my packages [1], which provided two C++ libraries. I solved by hand the build failure for the first on (liblog4tango4). I would like your opinion about my fix [2]. I am not sure that I did the right things. Is seems that a few of the missing symbols was Destructor or va_list implementation differences or even int(32bit) vs int (64bits). Now it fails on the second library (libtango7) as your can see here [3]. So I would like also your advices about thoses FTBFS as it seems thaht it will be a lot more work... Is there a link somewhere explaining by examples how to deal with thoses MISSING symbols or differences of implementations ? [...] I'd like to suggest the following: - Use the c++ tag to move to human-readable symbols and get rid of problems due to different name mangling schemes. - Combine this with regex to work around 32/64 bits issues. - Both of this is quite extensively documented in the dpkg-gensymbols man page. - Take a look at some existing package that makes use of these features, for example my diagnostics package. Hope this helps, Michael pgpTHdxCTWuO7.pgp Description: PGP signature
Re: Adding symbols files to the tango package.
Hi again, Le Fri, 29 Jul 2011 09:45:53 +0100, Michael Tautschnig m...@debian.org a écrit : - Use the c++ tag to move to human-readable symbols and get rid of problems due to different name mangling schemes. yes it is nicer with c++ tag, is there an automatic way to convert a symbol file to this human readable format. Please take a look at this [1] post to the list. Should I tune my rule file to generate automatically a symbol file with thoses c++ tag. I don't think there's any tuning need in your rules file. - Combine this with regex to work around 32/64 bits issues. - Both of this is quite extensively documented in the dpkg-gensymbols man page. Yes there is plenty of explanation in the man page but I need a lot more practice to learn about symbols. Sometimes I do not know if it Hmm, I'm not sure I understand that last sentence!? - Take a look at some existing package that makes use of these features, for example my diagnostics package. I took a look at your package, nice symbol fil and I like the symbol split between symbols, optional, stacktrace(what for ?). It requier a huge knowledge of the projet internals. Which project internals do you refer to? stacktrace is just a sub-part of diagnostics that isn't available on all architectures, hence the split-out of this part. Hope this helps, Michael [1] http://lists.debian.org/debian-mentors/2011/07/msg00360.html pgpdURgaRcosE.pgp Description: PGP signature
Re: RFS: libchart-php
Hi Daniel, I have update the package with the latest available version 1.3. Please, can you check if everything is OK? [...] I just thought I'd briefly check whether your orig.tar.gz matches the upstream tar.gz, found different md5sums and then this: (omitting full diffstat output) 78 files changed, 3771 insertions(+), 4496 deletions(-) !? It seems you completely reorganized the source tree. That's not quite the point of a .orig.tar.gz file. I didn't dig any deeper as copyright checks don't make sense if upstream source isn't actually upstream source. Sorry, Michael pgpMS8atKbNtk.pgp Description: PGP signature
Re: RFS: libpam-abl
Hi Alex, [...] Instead of setting an override, you can probably patch the manpages. This could also be related to a docbook bug. [...] I've uploaded a new version with mentioned fixes . I didn't touch overrides because don't know how to fix these warnings , also I see that linitian complains about other packages as well .( samba for example ) Ignoring warnings/errors isn't quite the way to solve problems. You might simply want to ask for help on debian-mentors in such cases. I do agree with Etienne that this must be a docbook bug, but the shame is that upstream doesn't actually provide the sources they generated the man pages from. You should ping upstream about that, but for now there's no way around patching the man pages. Yet this isn't really too hard, it seems. I've just looked at them and it seems that modifying three lines does the trick. Hint: if man --warnings respectively lintian reports a warning for line 168, start looking from there. In this case it's a bit more tricky as .SH is redefined, hence you'll have to take a look at its redefinition. Feel free to return with questions if you need more guidance on this. Best, Michael pgpuqcZDy6GBo.pgp Description: PGP signature
Re: RFS: nullidentd (adopting package)
Hi, [...] Thanks a lot for stepping up as new maintainer of this package. I've briefly reviewed your changes over the previous package and it all looks good. Built and uploaded. For a future upload, however, it would be nice to see an update to the copyright file: it doesn't say that this is GPL v2, and using DEP-5 format would be a plus. Thanks a lot for your work, Michael pgpG8Z2Dn5QiG.pgp Description: PGP signature
Re: RFS: libharu (updated package)
Hi, Dear mentors, I am looking for a sponsor for the new version 2.2.1-1 of my package libharu. It builds these binary packages: (new) libhpdf-2.2.1 - C library for generating pdf files libhpdf-dev - C library for generating pdf files (development files) I've tested the package and lintian does not complain. [...] The package looks mostly fine, except for the fact that our lintian's seem to disagree: W: libharu source: format-3.0-but-debian-changes-patch E: libhpdf-2.2.1: helper-templates-in-copyright E: libhpdf-dev: helper-templates-in-copyright Could you please git rid of those (all of which should be easily addressed, the latter two ideally by a DEP-5 formatted copyright file) and re-upload? Thanks, Michael pgpU2M8xJGWiL.pgp Description: PGP signature
Re: RFS: taxbird (updated package)
Hi Olaf, Sorry for the late reply (and it seems that all other people are busy as well :-/). [...] I added two messages to the bug report #619734, including the diffs for the packages. I also uploaded new versions of libgeier (0.12-1.1) and taxbird (0.16-1.1) based on the packages, Marvin provided on his homepage. [...] I'm seeing two problems here: - The NMU bug against libgeier should also be filed against libgeier package; in this case it was just appended to 619734. - The NMU is (intentionally) based on Marvin's packages, which, however, don't exist in Debian (if they did, there wouldn't be too much of a need for an NMU). Could you please build version -0.1 instead of 1.1, which combine Marvin's changes and your modifications into on version, and then update the NMU diffs? You will want to gzip those, as they will obviously be much larger, including all the new upstream changes. Thanks a lot, Michael pgpsWnodqWr4Q.pgp Description: PGP signature
Re: Sponsored packages are not automatically deleted from debian.metors
Hi, I've seen that does not automatically remove the sponsored packages from debian.metors. Before, the package are removed when the package is uploaded. Is this a change or may be a mistake? mentors.d.n lists support AT mentors.debian.net as the main contact. Could you please contact them and report back your results here? Thanks a lot, Michael pgpZWvF3Z6gZk.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi Hendrik, [...] I am glad, that it worked. I have one further question. When there is a new upstream release and I build a new package. May I put you on CC, when sending an RFS? You may, but no need to do this as I'm subscribed and haven't got any filters in place that would result in any different mail handling. Feel free to ping me about the RFS in an extra private mail if you've been waiting for too long :-) Best, Michael pgpJaghN6qMRU.pgp Description: PGP signature
Re: dacco and qdacco packages waiting sponsor
Hi, [...] I have created the new file symbols: the new file is attached to the email. If the file is now correct, then you can review the new version of the package in debian.mentors ( http://mentors.debian.net/debian/pool/main/q/qdacco). I couldn't find any attachment in your email, but the best solution would anyway be to make it part of the package on mentors.d.n :-) Do you know any document that spells out the use of tags in the symbols file ? I want more information on the subject. man dpkg-gensymbols has lot's of information. Best, Michael pgpuC5uFEq2BP.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi, [...] I fixed these warnings. [...] Thanks a lot for quickly addressing all those points! I've now built and uploaded your package. Pending review and acceptance by ftp-masters, it should appear in the archives in a few days! Thanks a lot for your work, Michael pgp6IZX5OAzzy.pgp Description: PGP signature
Re: RFS: kpartsplugin (updated package)
Hi, [...] Changes: kpartsplugin (20110606-1) unstable; urgency=low . * New upstream release * Added missing libx11-dev in Build-Depends (Closes: #632122) * Copyright file switched to DEP-5 format [...] Thanks a lot for updating and improving the package! It's built and uploaded. Thanks a lot for our work, Michael pgpufKG9XGUgR.pgp Description: PGP signature
Re: RFS: assaultcube-data (updated package)
Hi again, [...] Thanks a lot for updating this package. Yet the new non-repacking leaves some doubts to me: - Don't repack anymore. is a nice hint that something has changed, but yet it left me to find this out myself via the debdiff. - Using repacknot1 as version appears to be a cruel hack. Ideally we'd have a new upstream version that could be packaged, but if that doesn't happen soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem like a better solution either...) - Why do server binaries belong to a data package? Isn't that just a hack to avoid a new source package? - The original license appears to disallow re-packaging/splitting, hence there must be some exclusive exception provided to Debian. This is, however, not detailed in the copyright file. Best regards, Michael Hello. - True, I've changed it to read Upstream tarball no longer repacked; binaries not removed since used, would this be reasonably verbose? Ok, cool, that sounds more helpful. - Yeah, 1.1.0.5 is in the works, but when is very uncertain (maybe this year...). I discussed the renaming on IRC (mentors/games) and it seemed like this was the most reasonable solution. Ok, thanks a lot for the info. - Would splitting it into two source packages be better, it seems a tad unnecessary? Upstream distributes one AC package with precompiled binaries and data for compile-less usage (which Debian uses only for data currently), and an AC-source package, which Debian uses to create the packages with the binaries. Since the binaries comes in the upstream tarball which Debian calls -data I guessed it would be best to use this source package as-is.. In this case I do agree that splitting is probably too much of a hassle. However, the name still doesn't seem appropriate. Wouldn't it be good to rename the source package? What about moving to assaultcube-nonfree for the source package name? (Here I'm assuming that the assaultcube-data package was non-free before, is that correct?) Renaming the source package requires the additional step of requesting removal of the previous source package from the archives, but that's doable. - Noted (complicates the current deletion of the binaries as well, I guess), I've sent the question of special permission for the Debian project to the main project people, we'll see where that discussion leads. Given your above information about the assaultcube binary package I'm not sure I understand whether the new repacknot package isn't actually license-compliant as it is unmodified!? Best regards, Michael pgpcorRiCnrGk.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi all, [...] okay. That was my mistake. For some time there was no man page, but now there is. There was a mistake in the package such that the man page was not installed. I hope this fixes the last issue with the package. [...] I'm afraid the copyright file isn't yet fully complete: - src/md5.h, src/md5.cpp have a distinct license and copyright holders. - src/GMDBus.h is LGPL v2.1+ - line 11 of debian/copyright should probably say LGPL, not GPL. A few more minor notes: - debian/rules, target clean depends on itself!? - lintian has a few more notes, all of which are easy to fix: I: gogglesmm source: quilt-patch-missing-description fox_pkg_config.diff I: gogglesmm source: debian-watch-contains-dh_make-template I: gogglesmm: package-contains-empty-directory usr/sbin/ I: gogglesmm: desktop-entry-contains-encoding-key usr/share/applications/gogglesmm.desktop:2 Encoding May I ask you to fix those remaining small issues? Then your package should be ready to be uploaded! Best, Michael pgpUnMxRLofwn.pgp Description: PGP signature
Re: dacco and qdacco packages waiting sponsor
Hi, [...] The question is: how do you generate these files with c++ tags? Is it possible to automatically generate the files? [...] Yes, that can be done almost fully automatically. The main step is piping the current symbols file through c++filt, as in cat qdacco-0.8.2/debian/libqdaccolib0.7.symbols | c++filt then make sure you keep the first line of your current file. The final step is only text mangling: add (c++) in front of each symbol and enclose each symbol in double quotes (as you've taken a look at diagnostics already, you can pick up the exact positioning of all this from there). Please let me know if you need any further details! Best, Michael pgpTl7eepjcl5.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi, [...] Left is the missing man page. The original package does not provide a man page, so I can not provide one. I'm sorry, but I don't buy that argument - it's quite frequent that Debian package maintainers have to provide additional man pages because upstream doesn't provide one. Adding man pages in no way differs from other patches. Best, Michael pgpqG0zxFhzr4.pgp Description: PGP signature
Re: RFS: wmmixer
Hi, [...] I think the package is finished now. Cool, thanks, package looks pretty good. I've just uploaded it, but please consider the following comments for the next version you might prepare: - I've remove one line from changelog (priority to extra), added the Homepage to debian/control and changed the debhelper build dep to = 7 (you don't use overrides). Given these changes, please pick the source files from the Debian archive and update your local copy. - The long description of the package (in debian/control) essential speaks only about whether or not to use WindowMaker, but says nothing about the package itself (as in being an audio mixer). Please improve this description. Thanks a lot for your work on this package, Michael pgpgAWtF3DDnZ.pgp Description: PGP signature
Re: RFS: taxbird (updated package)
Hi Olaf, Michael Tautschnig m...@debian.org writes: Could you please briefly explain why you are NMUing this package? Are you intending to take over package maintainership? What about the previous maintainer? No, I don't want to take over the package. The maintainer is still maintaining libgeier and taxbird. But although he provided packages on his homepage and promised to upload them to the repositories, this didn't happen. So, in order to fix bugs 577760 and 619734 for taxbird, I uploaded libgeier and taxbird to debian-mentors. Thanks a lot for the clarification (and, Marc, thank you as well). I do understand the need for an urgent update of the package - yet an NMU requires following NMU procedures as outlined in Debian policy, see http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu What is required in addition to the work that was already done is - express the intend to NMU in the bug report (probably #619734) - attach the NMU diff to the bug report Olaf, if you could take care of those steps, I'd be fine with sponsoring an upload to DELAYED. Best, Michael pgpJ6E40YAKf1.pgp Description: PGP signature
Re: RFS: mosh
Hi David, [...] Given that, according to the discussion in #156, some earlier version had apparently worked fine: couldn't the Debian package simply revert that optimization that requires GC_DONT_ADD_BYTE_AT_END? At the time this was implemented it was quite a significant change and touched most aspects of the interpreter. I think this would be quite hard to revert, and doing so would basically constitute a fork. However I haven't tried to do it, so I can't really be sure. It's worth noting that the bundled version of libgc is also a CVS version, as several bugs unrelated to the optimization were found in the stable libgc. (I get the impression from upstream that this is because Mosh uses the C++ wrapper, which is part of libgc but not as heavily tested.) Ok, it seems that unpatching mosh really isn't quite an option. May I thus suggest a different route? You could try to convince the Debian libgc maintainers to produce a -src package (see http://packages.debian.org/search?keywords=-src for examples thereof) that provides the source code of the Debian binary packages. I suppose the maintainers should also be more than happy to take all the bugfix patches and include them in the Debian package. Then re-build libgc with any options mosh requires and be happy :-) I must state that a package that only works under very specific compile-time settings of an external library makes me shiver. It seems that mosh has no safety checks and the necessity to rely on such low-level optimizations raises questions about the design of this software... Sure, I agree, and I will probably raise a question on the ML about this. I think mosh maintainers should at least seek to include some run-time checks for the options required for correct operation. [...] I didn't follow either of these routes yet as I wanted to make sure I wasn't completely off track before working on one. Personally I agree that the dual-build seems cleaner, so I would prefer to go with that. I don't claim to be an expert on this, but it seems like a sane way to follow. Another complication (hah) that I should have mentioned in my original message was that the build script for the 'binary' that I'm referring to here, which is fairly substantial human readable source code, was NOT shipped with the upstream tarball. However, it is under a free license and is in the git respository, for some reason it was just excluded when releasing the tarball. As a result, to actually do this dual build, I would have to patch in the build script, or repack. Are either of these legally OK? Which do you think would be better? If the build script is fine license-wise, then just patch it in - that seems much less work than repacking. Keep it simple... (it's complicated enough anyway :-) ). Best, Michael pgp59jMfe0Igv.pgp Description: PGP signature
Re: RFS: cmsmadesimple
Hi again, [...] One suggestion for the package install procedure, though: why do you first install all the files and afterwards remove them again via an override in debian/rules? Wouldn't it be much cleaner to only install the desired files? I preferred this method for a couple of reasons, firstly because I think the code for installing all of the folders separately would be much bigger and also because this makes the packaging a bit less error prone. If I do all of the install in the .install file, I would have to have a lot of lines (because I have to omit the translation files and the shared libs) and if upstream adds any files or folders, these might not get included without changing the install file. [...] I do agree that this incurs some risk. With the use of wildcards, however, I'm not quite sure whether the .install file will really be more complicated: you're now spending 60 lines in your debian/rules file on removing files (including comments, though). My concern is a security-related one: yes, your package might break if you fail to install a newly-added file. But it will be completely broken. On the other hand, if you fail to remove a newly-added file that unfortunately contains some security problem which would have been already addressed in the system version of that file, this problem will go undetected until exploited. Thanks again for your work, Michael pgpFc5MymMjlB.pgp Description: PGP signature
Re: RFS: mosquitto
Hi Roger, [...] Lintian run as lintian -iIE --pedantic gives the following output: W: mosquitto source: debhelper-overrides-need-versioned-build-depends (= 7.0.50~) [...] Instead of copy-pasting this lintian warning, you should have addressed it :-/ - could you please fix that and re-upload to mentors? I will then happily sponsor your upload. I'm sure I had an email from this list in the past with a very lucid reason why I shouldn't heed that warning, but I can't seem to find it now. I certainly can't remember the reasoning. I've made the change and re-uploaded. It is now lintian clean. Well, most likely this is the initial email of the nitpicking... thread. Indeed that included a discussion about debhelper versions and compatibility levels, but the main point was a different one: a sponsor's request to update to debhelper version 8 from 7 or 7.0.50, which may induce undesired changes. In your case, however, you are already using features (dh overrides) of 7.0.50, but weren't declaring a proper build dependency. Does this help to clarify? Package reviewed, built, and uploaded. Thanks a lot for the work, Michael pgpsFG4YRyhgu.pgp Description: PGP signature
Re: RFS: assaultcube-data (updated package)
Hi, Dear mentors, I am looking for a sponsor for the new version 1.1.0.4+repacknot1-1 of my package assaultcube-data. It builds these binary packages: assaultcube-data - data files for AssaultCube assaultcube-server-anticheat - AssaultCube server with closed source anti-cheat module The changes are: * Update manpages - CC-BY-NC-SA (previous license was incorrect given content used) - Few formatting fixes * Update debian/copyright - Note license of manpages - Files: headers pointing at directory instead of license file. * Update debian/rules to dh7 format * New package: assaultcube-server-anticheat, installs upstream server binaries * Create a wrapper script for the server with --help for manpage * Don't repack anymore. [...] Thanks a lot for updating this package. Yet the new non-repacking leaves some doubts to me: - Don't repack anymore. is a nice hint that something has changed, but yet it left me to find this out myself via the debdiff. - Using repacknot1 as version appears to be a cruel hack. Ideally we'd have a new upstream version that could be packaged, but if that doesn't happen soonish, we'll have to live with that hack. (Introducing an epoch doesn't seem like a better solution either...) - Why do server binaries belong to a data package? Isn't that just a hack to avoid a new source package? - The original license appears to disallow re-packaging/splitting, hence there must be some exclusive exception provided to Debian. This is, however, not detailed in the copyright file. Best regards, Michael pgp18JSNz1JWU.pgp Description: PGP signature
Re: RFS: propel
Hi, Dear mentors, I am looking for a sponsor for my package propel. * Package name: propel Version : 1.5.6-1 Upstream Author : [fill in name and email of upstream] * URL : http://www.propelorm.org/ * License : MIT License Section : php It builds these binary packages: propel - Object-Relational Mapping (ORM) library written in PHP5 The package appears to be lintian clean. Further comments follow below, but that's simply not true: I got 13 warnings and 1 error. The upload would fix these bugs: 330203 My motivation for maintaining this package is: I'm user of symfony framework with Propel as ORM. [...] Have you spoken to the symfony maintainers for sponsorship? As you are anyway intending to upload this package with pkg-symfony-maint set as maintainer, you would probably want to incorporate their feedback and might well get much more appropriate input from that side. For the general comments, however, I've got three notes: - test/etc/xsl has files with Apache 2.0 license. This must be noted in debian/copyright. - Having read the package description in debian/control, I have no idea what this package is about. Please make it much more verbose and possibly reword it. Here, the debian-l10n-english list may be of help. - A new upstream release is available. Best regards, Michael pgp2AIVUVUmmQ.pgp Description: PGP signature
Re: RFS: steadyflow (now in Ubuntu)
Hi, I have updated my steadyflow package on mentors to the latest upstream version 0.1.7, based on the version of the package I got approved into Ubuntu Oneiric. I would be grateful if someone could review and sponsor the package. I'm upstream and a DM, and if I have the DM-Upload-Allowed flag set on this package, I'll be able to maintain it from now on in both Debian and Ubuntu without any need for further sponsorship. The package looks mostly fine as far as the formal aspects are concerned, but there are two practical problems: - libappindicator-dev doesn't exist in Debian, and I do have certain doubt that the autobuilders would successfully resolve the alternative depends to hello. I'd suggest removing libappindicator-dev from the build dependencies. - The package FTBFS: dh_auto_configure -- -DCOMPILE_GSETTINGS_ON_INSTALL=OFF [...] -- Checking for libappindicator... -- checking for module 'appindicator-0.1' -- package 'appindicator-0.1' not found -- checking for a minimum Vala version of 0.12.0 CMake Error at cmake/ValaVersion.cmake:88 (message): Vala version 0.12.0 or greater is required. Call Stack (most recent call first): CMakeLists.txt:35 (ensure_vala_version) Hope this helps, Michael pgpvBcNxZaopk.pgp Description: PGP signature
Re: RFS: steadyflow (now in Ubuntu)
The reason I added libappindicator-dev | hello was to avoid this dependency being the only delta between Debian and Ubuntu. This way I'd be able to sync from Debian into Ubuntu without changes. If that's flat out unacceptable, I'll leave the dependency out and add it in Ubuntu only until libappindicator appears in Debian. I would be fine sponsoring the package with the libappindicator-dev | hello; it'll be your task to handle possible build failures :-) As for the second reason, it's strange - it built last time I checked. I'll look into it. [...] Ok, cool, please just let me/the list know when an updated version is available. Best, Michael pgpscJn22YZV9.pgp Description: PGP signature
Re: RFS: steadyflow (now in Ubuntu)
Hi, This is strange. I just tried building it in a sid pbuilder, and it succeeded - in fact, I cannot reproduce this build error at all. Could it be possible that you have vala-0.12 installed alongside some other version of Vala (say, 0.10) and it's not the default version selected in alternatives? [...] Hmm, indeed I do: # dpkg -l | grep vala ii libvala-0.10-00.10.4-1 C# like language for the GObject system - library ii libvala-0.12-00.12.1-1 C# like language for the GObject system - library ii valac 0.10.4-1 C# like language for the GObject system ii valac-0.100.10.4-1 C# like language for the GObject system ii valac-0.120.12.1-1 C# like language for the GObject system I'm afraid, however, that you will have to cope with this situation. You could use Build-Conflicts to hack away the problem, but then I wonder whether the problem would just be deferred to runtime? Best, Michael pgpx5JRfRllcB.pgp Description: PGP signature
Re: RFS: steadyflow (now in Ubuntu)
I've uploaded a new version to mentors, which patches the upstream build system to use valac-0.12 as the executable name. Not very pretty, but since we depend on the versioned package anyway, the version can always be changed in both places. Ok, looks good. Built uploaded. Thanks a lot for your work, Michael pgpHVqgENQ8vQ.pgp Description: PGP signature
Re: dacco and qdacco packages waiting sponsor
Hi, Hi! These packages are waiting for a sponsor: http://mentors.debian.net/debian/pool/main/q/qdacco and http://mentors.debian.net/debian/pool/main/d/dacco. This is a Catalan-English dictionary and a query GUI. [...] I've just uploaded dacco, looks good. For qdacco, however, I get an FTBFS because of an outdated symbols file. Looking at the diff, this is quite likely caused by name mangling changes in GCC. I'd suggest moving to c++ tags, as supported by recent dpkg-gensymbols, which permit to use human readable signatures. Please let me know if you need any help with those. Thanks a lot for your work, Michael pgpjx4XNzZtZU.pgp Description: PGP signature
Re: RFS: mgen
Hi, Dear mentors, I am looking for a sponsor for my package mgen. * Package name: mgen Version : 5.02-1 Upstream Author : Naval Research Laboratory m...@pf.itd.nrl.navy.mil * URL : http://cs.itd.nrl.navy.mil/work/mgen/index.php * License : Open Source Section : net It builds these binary packages: mgen - The Multi-Generator for IP network performance tests The package appears to be lintian clean. Err, no: W: mgen source: debian-rules-missing-recommended-target build-arch W: mgen source: debian-rules-missing-recommended-target build-indep W: mgen source: out-of-date-standards-version 3.8.4 (current is 3.9.2) I: mgen source: debian-watch-contains-dh_make-template E: mgen: helper-templates-in-copyright W: mgen: description-synopsis-starts-with-article I: mgen: arch-dep-package-has-big-usr-share 4497kB 92% [...] Anyhow, despite these the package looks pretty much ok; and all of the above should be easy to address. Just two more issues that need to be resolved: - The package ships PDF files; please rebuild them from source as part of the package build process; I suppose all the necessary sources are part of the package anyhow. Otherwise we will be in trouble and those files will have to be removed. - Your debian/watch file is slightly broken: the final src-mgen-(.*).02.tar.gz should probably be src-mgen-(.*).tar.gz, otherwise the Debian package will be reported as being newer than upstream. Two further nice-to-have changes: Use dh 7 simplified debian/rules; this would immediately address the first two lintian warnings. Moving debian/copyright to DEP-5 could go along with the fix of the error reported by lintian. Hope this helps, Michael pgp39xby647nc.pgp Description: PGP signature
Re: RFS: JLDrill
Hi, This is again a request for a sponsor for JLDrill, a Japanese language learning tool. I'm not a Debian developer and have had some difficulty making good packages. I appreciate your patience! :-) This time I have removed the need for rake to build the debian package. I've left ruby, rspec, rcov and ruby-gems in the build dependencies because they are necessary if you want to do development on JLDrill, but they should no longer be necessary to build the debian package (I use the debhelper scripts now). [...] It appears that this RFS is open for quite a while now, with no substantial response. As myself I have no knowledge about packaging ruby applications, I'd like to point out the Debian ruby teams instead. Please take a look at http://wiki.debian.org/Teams/Ruby and contact those people. Just one more note, though: you don't even have filed an ITP for this package, which could also have drawn more interest to this package. Best regards, Michael pgp6ChewKWbDy.pgp Description: PGP signature
Re: RFS: gogglesmm
Hi, Dear mentors, I am looking for a sponsor for my package gogglesmm. * Package name: gogglesmm Version : 0.12.2-5 Upstream Author : Sander Jansen s.jan...@gmail.com * URL : http://code.google.com/p/gogglesmm/ * License : GPLv3 Section : sound It builds these binary packages: gogglesmm - Goggles Music Manager The package appears to be lintian clean. [...] I've taken a look at your package and noticed the following issues that I'd like to see addressed before sponsoring its upload: - No ITP. Please file an ITP first and close it in your changelog. - The conflicts/replaces for musicmanager-tray, musicmanager seem strange as neither of which exists as a Debian package. - debian/copyright: Please indicate which version of the GPL your packaging conforms to. Updating debian/copyright to DEP-5 format would be a plus. - Some header files in src/ are LGPL, not GPL. Needs to be noted in debian/copyright. - Have you considered moving to v3 (quilt) source format, dropping dpatch? - I can't confirm the lintian-cleanliness, there's one warning about the lack of a man page and several info-level messages. Hope this helps, Michael pgpwMtr1EoSAz.pgp Description: PGP signature
Re: RFS: mosh
Hi, I'm sorry, I haven't yet reviewed your package, I'm only commenting on the issues you raised. [...] It builds these binary packages: mosh - fast R6RS Scheme interpreter mosh-doc - reference documentation for Mosh [...] #1. It requires an embedded copy of the Boehm GC. dmoerner previously attempted to unbundle this and it did work, however a recent change in Mosh relies on a non-default compile time configuration of the GC, and also bugfixes which are only present in the CVS version. As such it's quite impractical to unbundle the GC library at the moment, and the upstream bug is marked WONTFIX. See: http://code.google.com/p/mosh-scheme/issues/detail?id=156 For reference, I have attempted to build against a libgc using a default configuration and it breaks badly at runtime. Given that, according to the discussion in #156, some earlier version had apparently worked fine: couldn't the Debian package simply revert that optimization that requires GC_DONT_ADD_BYTE_AT_END? I must state that a package that only works under very specific compile-time settings of an external library makes me shiver. It seems that mosh has no safety checks and the necessity to rely on such low-level optimizations raises questions about the design of this software... #2. psyntax-mosh requires several Scheme sources to be compiled into a single 'binary' (which is actually text, but not human-editable). However, the build script requires a previous version of Mosh. Releases are distributed with a precompiled version so the users doesn't need an older version. I asked about this on IRC, and it seems it's unacceptable to use the precompiled file in the final build, so two solutions were suggested. One is to initially build using the precompiled file and then rebuild over the top using the now-bootstrapped version (The version doesn't necessarily need to be older.) The other method is to split the source package into two packages, mosh-bootstrap and mosh, where mosh-bootstrap is arch-independent and mosh arch-dependent. Neither of these are clean but that is probably unavoidable. Well, then, which route did you follow? I don't really see a problem with the rebuild-over-the-top variant, although of course this introduces some complexity. Best regards, Michael pgpVecbDlSo3u.pgp Description: PGP signature
Re: RFS: JLDrill
Hi again, On 11 July 2011 06:09, Michael Tautschnig m...@debian.org wrote: Just one more note, though: you don't even have filed an ITP for this package, which could also have drawn more interest to this package. Hi Michael. Thanks for the response. Since I didn't get a response for the RFP, I thought I would wait until the next release before I tried again. I will definitely contact the Debian Ruby team. Thanks for the advice. Also, what is an ITP? I'm new to Debian, so I'm not familiar with everything yet. Oops, sorry for being brief on that. An ITP is the intent-to-package, which is a bug report to be filed against the wnpp pseudo package. Have you already had a chance to read the Debian New Maintainers' Guide? I'd suggest to start from there, which at least will briefly touch upon the ITP in the section dedicated to debian/changelog. Hope this helps, Michael pgpbfHP4xE671.pgp Description: PGP signature
Re: RFS: taxbird (updated package)
Hi Olaf, Dear mentors, I am looking for a sponsor for the new version 0.16-0.1 of the package taxbird. It builds these binary packages: taxbird- The first free Elster client (German Tax Declarations) [...] Could you please briefly explain why you are NMUing this package? Are you intending to take over package maintainership? What about the previous maintainer? Thanks a lot, Michael pgp4HYNTgaXLU.pgp Description: PGP signature
Re: RFS: wmmixer
Hi again, [...] Minor improvements to be made: - You don't need to build-depend on quilt. I don't know how to solve it. I cannot found the build-depend. Sorry, I meant the Build-Depends: entry in debian/control. [...] Concerning your question for getting rid of binary-arch in debian/rules: please see the man pages of dh_installchangelogs, etc. You will find that mostly you may specify the upstream files in debian/package.tool files, e.g., for dh_installexamples use debian/wmmixer.examples. If that option isn't available, use overrides, e.g., override_dh_installchangelogs. Ok, but these files (CHANGES, README, home.mixer) are included in the original source. To make that, I need to create a patch to move these files to the correct name in the debian folder. I don't have problems to do that, but I am not sure if is correct. What do you think? [...] No, you don't need to rename anything. These files, such as debian/wmmixer.examples should then contain a list of file names to be installed as examples. Does this help as clarification? Best, Michael pgparXZ6kFeFf.pgp Description: PGP signature
Re: RFS: mosquitto
Hi Roger, [...] Thanks a lot for updating your package. I've reviewed your changes and it looks mostly fine, except for one issue: Lintian run as lintian -iIE --pedantic gives the following output: W: mosquitto source: debhelper-overrides-need-versioned-build-depends (= 7.0.50~) [...] Instead of copy-pasting this lintian warning, you should have addressed it :-/ - could you please fix that and re-upload to mentors? I will then happily sponsor your upload. Best regards, Michael pgp9IqWQbNLQg.pgp Description: PGP signature
Re: RFS: wmmixer
Hi, [...] Can you check the package again. I've got a few questions concerning your changes, which aren't necessarily bugs, but at least I'd like to see the rationale. - The most recent policy version is 3.9.2; why did you update to 3.9.1 only? - Why has the priority been changed to extra? - What is the upstream status of your patches, have you forwarded them/tried to contact upstream? Minor improvements to be made: - You don't need to build-depend on quilt. - No need for include /usr/share/quilt/quilt.make in debian/rules - debian/watch only holds a comment, that doesn't really help uscan to check the status. Could you make that a proper watch file? Concerning your question for getting rid of binary-arch in debian/rules: please see the man pages of dh_installchangelogs, etc. You will find that mostly you may specify the upstream files in debian/package.tool files, e.g., for dh_installexamples use debian/wmmixer.examples. If that option isn't available, use overrides, e.g., override_dh_installchangelogs. Please provide some information on the questions I've posed above and please take a look at the possible improvements. Then your package should be ready to be uploaded. Hope this helps, Michael pgplV9xr0WrkI.pgp Description: PGP signature
Re: RFS: naev
Hi, I am looking for a sponsor for my packages naev and naev-data. * Package name: naev, naev-data Version : 0.4.2-1 Upstream Author : Edgar Simo bobbens bobb...@gmail.com Nikola Whallon 6.satur...@gmail.com Josiah Schwartfeger Deiz Bas Fournier BTAxis bta...@gmail.com * URL : http://code.google.com/p/naev/ * License : code - GPL-3 ; data - public domain, GPLv2, GPLv3, CC-By (and -SA) 3.0 Programming Lang: C, Lua Section : games Description : 2D space trading combat game [...] I've taken a look at this package and would really hope for further input from the Games team, as they might be much more experienced with the mix of licenses that occurs when packaging graphics and sound files together with the source code. My main focus of this reviewing round was the copyright file; it is already very helpful to be in DEP-5 format, but I'm afraid it's still incomplete: - What about the file in build/? - The contents of dat/ is a bit dangerous: the font files appear to lack the sources that they were generated from!? - In src/, a few files contain copyright and license information. Those copyright holders (and licenses) are not reflected in debian/copyright. - Your debian/changelog file gives pointers to further potential issues. Aside these missing bits, it would be preferable if licenses found in /usr/share/common-licenses were not quoted in full; I'm asking for this because the copyright file is already huge anyhow. Hope this helps, Michael pgpeTYC9cZQAS.pgp Description: PGP signature
Re: RFS: cmsmadesimple
Hi, Dear mentors, I am looking for a sponsor for my package cmsmadesimple. * Package name: cmsmadesimple Version : 1.9.4.1-1 Upstream Author : Ted Kulp, t...@cmsmadesimple.org * URL : http://www.cmsmadesimple.org * License : mixed: GPL-2+, GPL-3+, LGPL-2.1, LGPL-3 Section : web It builds these binary packages: cmsmadesimple - scalable content management system cmsmadesimple-l10n - scalable content management system - localization files #p(lzlG8NhB.j4 The package appears to be lintian clean. The upload would fix these bugs: 60 [...] Sorry for taking so long for anyone to respond. Indeed this is a very nice example of making proper use of existing Debian packages, despite upstream shipping all the duplicate code. The only remaining point is modules/Printing/tcpdf/fonts/: it wouldn't occur to me as a surprise to find this freefont code to be part of some of the *-freefont packages!? One suggestion for the package install procedure, though: why do you first install all the files and afterwards remove them again via an override in debian/rules? Wouldn't it be much cleaner to only install the desired files? Anyhow, built, signed, and uploaded. But as a new upstream version is already available, there is a chance for you to update the packaging as well :-) Thanks a lot for your work, Michael pgphBINPNkSjY.pgp Description: PGP signature
Re: RFS: naev
Hi again, Hi Michael, Thanks for the review. Please also consider reviewing my most up-to-date packaging in the Debian Games svn repository; my Naev packaging at mentors.d.n is heavily outdated at the moment, mostly because I'm getting tired of having to upload a 200 MB tarball every time I want to make a minor change to my packaging. $ svn co svn://svn.debian.org/svn/pkg-games/packages/trunk/naev/ That makes sense, yes - but where can one find the original source archive? Below, you are speaking of some upstream changes since 0.5.0, hence there should be some newer version of that upstream archive!? [...] - In src/, a few files contain copyright and license information. Those copyright holders (and licenses) are not reflected in debian/copyright. Upstream has added copyright/license info to every source file since the latest Naev 0.5.0 release, so this shouldn't be an issue. That update is very much appreciated; however, unless some source files were removed, there is still a need to update debian/copyright to list all copyright holders. I will provide more precise input once you let me know where to find the most recent upstream source. - Your debian/changelog file gives pointers to further potential issues. And I'd gladly accept any help in resolving those issues. I'm not sure whether anybody other than upstream can help resolving those questions!? Aside these missing bits, it would be preferable if licenses found in /usr/share/common-licenses were not quoted in full; I'm asking for this because the copyright file is already huge anyhow. None of the various Creative Commons licenses (which take up the bulk of debian/copyright) are found under /usr/share/common-licenses. Indeed, sorry for the noise! Best regards, Michael pgpJcLEJoUfrx.pgp Description: PGP signature
Re: Nitpicking: you are doing it wrong
Hi Jakub, hi all, [...] (whether or not to request bumping debhelper compat; I do agree with the technical arguments put forward by Jakub, but that's not the focus of my reply) The obvious provocative answer is: Nitpicking is the way to go. As always, however, there's more than black and white out there. Dear reviewers, next time if you are going to complain about: - debian/compat being too low; - debian/rules not using dh (or not using cdbs); - debian/copyright not in DEP-5 format; - source format not 3.0 (quilt) when there are no patches whatsoever; please think twice. Most likely, you are doing it wrong. Don't get me wrong, in my opinion (some of) these things are good. But making a big fuss about them is not helping anybody. It only distracts attention from things that are important, and creates false impression that they are somehow crucial for high quality packages. I can assure, they are not. I tend to agree that mentioning such potential-but-not-required improvements may distract from major problems. Yet, speaking for myself, I try to only put those points forward whenever they could also help to fix more serious issues. I'm trying to use these rules (in the order of the above list): - If debian/rules is overly complicated, and thus either known to be broken or at least likely to contain errors, I'll suggest going for dh 7 simplified format. - If debian/copyright is clearly missing information, or does not state sufficiently clearly the copyright holders and license information, I'll suggest DEP-5. This is almost always true whenever the code uses more than one license or copyright holder. - Source format 3.0 if quilt is manually invoked. All of the above points are about maintaining minimal packaging standards. If that's called nitpicking then, well, so be it. To me, however, package sponsorship and nitpicking do go well together: 1. Likely there won't be any review as detailed as the one before sponsoring a package for the first time. Nitpicking: now or never. 2. Consistent nitpicking yields consistent minimal package quality (yes, it's not necessarily good quality, but it's consistent). 3. Unwillingness to sponsor a package that only fails those non-essential tests (nitpicking) does not mean a package would be rejected. It's just about finding another sponsor. Especially the comments about debian/rules not using dh or cdbs: if a sponsor feels uncomfortable with the packager's debian/rules it's clearly preferable that the package not be sponsored by this particular reviewer. In summary: there are technical arguments against increasing dh compat level - agreed. debian/rules: to be left to the reviewer's discretion. debian/copyright: I'm in favour of DEP-5 for added clarity, which is particularly important when it comes to licensing and copyright issues. Best, Michael pgptmZWKJgAVB.pgp Description: PGP signature
Re: RFS: wmmixer
Hi again, [...] - Why have urgency=low QA (group) upload in the first line when you are doing a proper upload? Lintian detects the package as orphan and then shows the warning. If I try to write QA (group) upload in the first line (alone), lintian shows other warning. I don't know how to avoid the lintian warning. What should I do? IMHO the lintian warning message cannot be solved. - Aren't you adopting this package? At least #490739 appears to say so. I am trying to do that. I think both the non-QA-upload and lintian warning will be fixed by closing this particular ITA bug in the changelog properly. [...] Furthermore, why did you bump the debhelper build dependency to 7.0 when at the same time not making use of its new simplified debian/rules? I cannot find the info to rewrite the debian/rules to 7.0 What are the differences? When can I found docs about it. Please take a look at, e.g., http://en.wikipedia.org/wiki/Debhelper http://kitenet.net/~joey/blog/entry/cdbs_killer___40__design_phase__41__/ Hope this helps, Michael pgp1O2NtF1AIJ.pgp Description: PGP signature
Seeking package reviewing help by non-DDs
Hi all, I suppose many of you might not (yet) be DDs and hence feel like all they can do is package software and wait for some DD to come and respond to this RFS (in fact there are many other options to contribute, but please read on for at least one of them). Given that I've BCC'ed all the people whose packages I have sponsored recently I know that this can be a fairly long and even somewhat frustrating time span. Yet there is a way that *you* could help making this time span a lot shorter: There is a number of packages still seeking sponsorship, most of which are packages that are entirely new to the archive and the quality of which has not been checked so far. Most likely many of them will be of high quality, but at them same time there will be hardly any package out there that could not be improved in some or the other way. Any one who has read this post thus far and has some time to share, DD or not-yet-DD, would thus be cordially invited to take a look at one or several of the RFS listed below. If the package is found to be in fantastic shape then fine, please just go ahead and post that as well. If, however, you do find anything you could see improved, please let the owner of the RFS and the list know. So here's some of the RFS that, as far as I know, are open for quite a while (more than one month, in this case) and haven't seen much of a response: http://lists.debian.org/debian-mentors/2011/04/msg00108.html http://lists.debian.org/debian-mentors/2011/04/msg00125.html http://lists.debian.org/debian-mentors/2011/04/msg00194.html http://lists.debian.org/debian-mentors/2011/04/msg00290.html http://lists.debian.org/debian-mentors/2011/04/msg00346.html http://lists.debian.org/debian-mentors/2011/04/msg00347.html http://lists.debian.org/debian-mentors/2011/04/msg00371.html http://lists.debian.org/debian-mentors/2011/04/msg00374.html http://lists.debian.org/debian-mentors/2011/04/msg00448.html http://lists.debian.org/debian-mentors/2011/05/msg00079.html http://lists.debian.org/debian-mentors/2011/05/msg00092.html http://lists.debian.org/debian-mentors/2011/05/msg00118.html http://lists.debian.org/debian-mentors/2011/05/msg00342.html http://lists.debian.org/debian-mentors/2011/05/msg00349.html http://lists.debian.org/debian-mentors/2011/05/msg00353.html Personally, I'd highly appreciate if each of the people I'm BCC'ing, i.e., those whose packages I sponsored recently, would pick up at least one of the above. Don't worry about duplicate reviews, I'm sure everyone will have something to add. Best regards, Michael pgppQtwTFP2OY.pgp Description: PGP signature
Re: RFS: oggfix
Hi, [...] Ok, I wouldn't bother much about the above, but one thing does stop me from uploading: why are you setting the version number in such a way that Debian is upstream? This doesn't seem to be accurate. IMHO you should be using 0.9.1-1 as version number!? Never found out what the version number ought to be. 0.9.1-1 sounds exactly right. Thanks for that, too! This is explained in full detail in the Debian Policy [1]. Hope this helps, Michael [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version pgpjqeXLda4PY.pgp Description: PGP signature
Re: RFS: jappix
Hi, [...] The package looks pretty fine from my POV, hence built and uploaded. One thing to be fixed by upstream, however, is the lack of license and copyright information in source files. Given that this is what will be shipped plus the interspersed BSD and GPL files such information would really be valuable. Furthermore, in future uploads please address the following: W: jappix: description-synopsis-starts-with-article W: jappix: embedded-javascript-library usr/share/jappix/js/jquery.form.js Best regards, Michael PS.: And yes, there's a new upstream version out :-) Thanks Michael for taking the time to review this package. I started to set up the packaging in the pkg-xmpp team Git repository. I am also in the process of making a package with the latest (0.7) version. Marcelo Jorge Viera helped me to find the issues with the initial package. Most of the problems you mentioned should be fixed in the Git repository. Do you want me to copy the new version to mentors.debian.net? Not necessarily, no, but a pointer to the git repository would have been nice :-) Anyway, I figured it must be anonscm.debian.org/git/pkg-xmpp/jappix.git/ and did a git-buildpackage on that one. The HEAD appears to be a somewhat outdated ed8c3e4ab8ee2992bd4987f14e37ea01450df957, however, and I couldn't find any of my above concerns addressed in this version!? Best, Michael pgpxYvYjlDpej.pgp Description: PGP signature
