Re: nbc package has been removed from Mentors
On Monday 16 July 2012 11:58:23 Slavko wrote: Hi Thibaut, Hi, thank you for quick reply. Dňa Mon, 16 Jul 2012 11:30:35 +0200 Thibaut Paumard paum...@users.sourceforge.net napísal: It's not easy to get a sponsor, especially during a freeze (please read my previous message from 15min ago entitled Re: freeze policy - open requests for sponsorship). my package was uploaded a long time before freeze. After freeze i am do not expect, that it will be the part of wheeze. Don't give up, re-upload and try to send your RFS to maintainers (team or other) who you think should be interested (not only to debian-mentors). When I'm looking for a sponsor, I personally answer my own RFS with a [ping] message every month or so, just to show I'm still there, waiting for a sponsor. I tried post to electronics team, but without any reply. Sometimes it is really hard to find the balance... Consider for instance, that adding more packages to Debian would increase the overall maintenance (in terms of bugs, reviews, uploads, etc - all human time), which in turn might lead to exhaustion of sometimes very scarce human resources, which are then possibly supposed to take care of theirs, and sponsor yours or anyone else other packages as well. See the loop? Therefore, it is sometimes (but not always) more appropriate to just help the existing packages, by joining established teams or simply looking after bug logs of the existing packages you care for, provided you have the time and the will. I'm pretty sure, any well maintained package with responsible maintainer deserves to enter the Debian archive... but the sad part is that sometimes even such good candidates are not considered on time, due to prosaic reasons, like lack of time and/or lack of interest. Hence, just keep trying again. I am confused with these pings now - after the sponsorship-request pseudo package was introduced (and RFS bugreports) i understand, that there are no pings needed. You can still prod people and lists from time to time, you think might be interested in it. Another confusion is about the existing RFS bugreport now. It will be closed and new one must be created? Or after new upload i will only need to post reply to existing bug? Is this somewhere documented, please? Just re-use the existing one (reportbug -N bugnumber) Concerning your RFS: you should perhaps explain why you think nbc is good for Debian, whether you intend on maintaining it on the longer run (think 5-10 years) and why... In the meantime you can upload your package on a personal repository (have a look at the reprepro package) and try building a userbase outside Debian. Reading the ITP, I see you already have a prospective user, contact him. I have published it in my public personal repo for some (two or three) years, along with others (older or SVN versions) NXT brick's related packages for Debian. You can see them at http://slavino.sk/ulozisko-apt but thanks, i will try it again :-) Of course, you should try again. Just put some more salt, in hope to whet the prospective sponsor's appetite. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207161234.55457.danc...@spnet.net
Re: packaging help
On Tue, 24 Apr 2012 15:39:41 +0200, Ansgar Burchardt ans...@43-1.org wrote: On 04/24/2012 03:16 PM, Whit Armstrong wrote: I would be looking for 6-64999, assuming my package eventually made it into debian, I suppose it would need to have a 'globally allocated' uid. The idea is simply not to give users executing an R script on the machine root access. You shouldn't need a statically allocated user id for this; just creating a (system) user with adduser should be fine. (The 100-999 range in policy 9.2.2.) Regarding, reSIProcate, it's cdbs based? Would the postinst script be the same format if I use dh? Based on Lucas Nussbaum's tutorial (http://www.debian.org/doc/manuals/packaging-tutorial/packaging-tutorial.en.pdf) I thought that dh would be the way to go for new packages. Maintainer scripts shouldn't differ (they are more or less just copied into the binary packages[1]). dh should be the most popular for new packages, but in the end it's a matter of preferences. I believe it might also be easier to find a sponsor for packages using dh as more people are familiar with it than with cdbs. Regards, Ansgar [1] With a few modifications: debhelper (and cdbs as it uses debhelper) might add some lines to them by replacing a special marker with shell code (#DEBHELPER#). Agreed, and just to add few more bits to the above: As a good reference of adding and removing system users have a look at the vsftpd package, that is, its portinst and postrm scripts. However, the project's general agreement is that system users, once added, should not be removed [1] by packaging means, so you will only need to worry about the addition part. [1[ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621833 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/7c5c04e5e99e1d8aef38840f2d1bb...@spnet.net
Bug#664634: RFS: engauge-digitizer/5.0-2 [RC]
On Monday 19 March 2012 15:52:38 Tobias Winchen wrote: Dear mentors, Hi Tobias, I am looking for a sponsor for my package engauge-digitizer * Added patch fixing passing double as qreal. Closes: #656943 (FTBFS on armel and armhf) While the original reporter of bug #656943 did his best to prepare a patch which follows DEP-3 [1], he didn't have in advance all the required information to complete the patch header fields (e.g. bug number) as prescirbed by DEP-3, also claimed by the patch itself. OTOH, you have all the needed data to complete, at least: Origin: http://bugs.debian.org/656943 Bug-Debian: http://bugs.debian.org/656943 Reviewed-By: Tobias Winchen winc...@physik.rwth-aachen.de Last-Update: 2012-03-19 and optionally, the Forwarded field, see DEP-3. You can also drop the redundant line of: Bug-Debian: http://bugs.debian.org/??; right after the Description field. [1] http://dep.debian.net/deps/dep3/ -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203201737.34352.danc...@spnet.net
Re: Best use of bug tracker for a complicated situation
On Mon, 19 Mar 2012 17:37:45 +, Tony Houghton h...@realh.co.uk wrote: Hi, I maintain roxterm. The source package of that name generates a number of binary packages: roxterm-common, roxterm-gtk2, roxterm-gtk3 and roxterm (a virtual package depending on roxterm-gtk3). A user has reported 2 bugs with slightly different symptoms, one for roxterm-gtk2 and one for roxterm-gtk3. They're actually the same bug, applying to both, and I think also to old versions when there was only one binary package, roxterm. What's the best way to show the bugs affect all three? I used: affects n roxterm roxterm-gtk2 roxterm-gtk3 Would it be better to reassign them to the source package? In my control message how would I distinguish that from the binary packages of the same name? By appending :src? In this case use the 'found' command for these two (still meant to be separate) bugs: found NNN sourcepackagename/version found MMM sourcepackagename/version I reassigned them both to roxterm-gtk3 and then tried to merge them, but the merge is failing with what looks like an internal error involving an array where it expected a hash (reported verbatim to owner@bdo). So far I've been copying my comments to both bugs. This internal mishap needs to be investigated. Perhaps owner@bdo will provide more information. Meanwhile the user has added a comment to both which looks like there might be a new, separate bug. So I reckon I should forget the merge, continue to discuss the first problem in one of the reports and retitle the other report to reflect the possible new problem. Agreed? Yes, if you feel that these two bug reports appear to be caused by two distinct issues, then you should not merge them anyway and continue to gather more feedback about them as them being diverged. If at some point you can see that they appear to be caused by one and the same issue, you should be able to 'merge' or 'forcemerge' them provided certain 'merge' preconditions are being met: http://www.debian.org/Bugs/server-control#merge Alternatively you can also use 'New upstream release - fixes issue FOO (Closes: #NNN, #MMM)' from the changelog instead or merging them. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/38b07cf6b70e39f804cf8371a751a...@spnet.net
Bug#662968: RFS: shc/3.8.7-1
Hi Vibhav, Please have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327263 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508109 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203071941.33904.danc...@spnet.net
Re: RFS: quickrdp
On Sunday 22 January 2012 17:08:48 Tobias Eliasson wrote:
Hi,
--cut--
There are multiple implementations of telnet in Debian. Does quickrdp
really need this particular one provided by the telnet binary
package? If not, then the recommendation/suggestion should be changed
to telnet-client.
Not really sure I understand. From what I could search, there is no
package called telnet-client. To me it seems that the package telnet
is actually the proper 'telnet-client' package.
'telnet-client' is a virtual package (as in Policy#3.6) provided by several
real packages, which share more or less the same functionality, so other
packages requiring such functionality can simply depend on the virtual package
without having to specify any particular real package(s) from the list. You
can try 'apt-get install telnet-client' to see the list of real packages. Of
course, if you really have good reasons to depend on a particular real
package, then you do so.
Same goes for perl-base, but that's just for perl script support in
QuickRDP. I guess Suggests will work here aswell.
Do I understand correctly that this feature allows users to run their
own Perl scripts? If this is the case, it should be probably perl,
not perl-base.
Yes, users running their own perl scripts with arguments from the
specific connections. Alright, switching to perl. Reason i chose
perl-base was due to the description saying minimal Perl system.
I don't understand why Lintian complains on
helper-template-in-copyright. I can't see that it's actually a
template anymore. Sure I used dh_make to create the template, but
I've changed all parts I should as far as I understand... (obviously
not though).
It doesn't like Upstream Author(s). Just remove the (s).
Alright, thanks.
And why out-of-date-standards-version is 3.8.4 instead of 3.9.2 I
have no idea.
Standards-Version: 3.8.4 is in debian/control, isn't it?
Yes, it is. What I meant to ask would rather be; is it because I'm
running stable version of Debian that dh_make generates 3.8.4 instead of
3.9.2? Due to the explanation above that packaging focuses on unstable
and testing I guess switching to Squeeze on this machine would be the
best option for me.
Well you should prepare, build and test you package on a system ('suite' in
ftpmaster terms) you intend to upload to, that is, the one your declare in
your debian/changelog. Maintaining 'unstable' instance on your 'stable' system
should be relatively easy, by using:
* chroots - via cowbuilder, schroot (to name a few) to install, upgrade,
login to your chrooted system. This is as fast as your main system is, but
running X inside a chroot is tricky;
* virtual machines - this could be significantly slower, but more realistic
environment. For instance, you can pick a ready-to-go qemu image from:
http://people.debian.org/~aurel32/qemu/ and upgrade appropriately.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201201241100.32562.danc...@spnet.net
Re: RFS: engauge-digitizer
On Saturday 07 January 2012 18:48:29 Tobias Winchen wrote: Dear mentors, Hi, (a bit late, but anyway ...) I am looking for a sponsor for my package engauge-digitizer. The package is an update for engauge-digitizer 4.1, which is already in debian. The update closes the following bugs: #604503, #556025, and #556028. Uploaded. Thanks for taking care of the bugs in existing packages. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: OpenCPN navigation (ITP #538067)
On Monday 16 January 2012 09:09:27 Hamish wrote: Hi, Hi, (just to summarize the log from IRC session, we had) It's been 5 weeks without response, and no luck finding a sponsor on IRC, so I'll try a repeat posting. :-) Yeah, a lot of effort has been put into making this packaged properly (as seen from the ITP bug), but the package is in very specific niche and possibly only few interest is provoked amongst DDs, of course the lack of free time is also a blocker, and last bu not least the whole thing is quite complex. As a measure of end-user interest in this program, downloads in the last 12 months have averaged about 500/day from the sourceforge d/l site. http://sourceforge.net/projects/opencpn/files/stats/timeline?dates=2006-10- 26%20to%202011-12-31 the most visible issues, so far: * modified embedded copies of external projects - nmea (for the main app - okay; and each plugin, why so?), iso8211, gdal. Maybe all these modifications are justified, as seen from the ITP, this is best to be sorted out. * unrelated (wrt Debian archive) binary files (like vc_redist.exe, visual studio redistributable) are found the the upstream tarball, also removed by you in the dfsg tarball. Both of these could be documented within the 'Comment' field of DEP-5, mentioning the reason for removal and modification. It is good to have them carefully put together, so that they are traceable at least; these of course might be solved one way or another in the future versions. Next, * long package descriptions should be impoved, and in my opinoin to the point where a person with a driver license could be comfortable to read and understand it :) For instance: the bullet list of bullet of features, should have more explanations; you cold add a sentence or two about the Route handling facility. * get-orig-source, or have a look at DevRef - 6.7.8.2. - Repackaged upstream source - to at least ease the fetching of your dfsg tarball from alioth. * to put dfsg in the version number or not? yes, ...+dfsg-1. Hamish wrote: You'll notice our source tarball is labeled dfsg. This is because there were some included DLLs to help build the MS Windows version of the program which we didn't need/want for the Linux build, the source code itself is untouched. Paul Tagliamonte wrote: Is the source included for those DLLS? No. They are 3rd party; specifically Nullsoft's NSIS installer, http://nsis.sourceforge.net/License and Microsoft's VisualC++ runtime redistributable. NSIS is permissive FOSS; vcredist is free as in beer. Without even considering the unused source-avail-at-sourceforge NSIS, I'm pretty certain that free-as-in-beer anything is not allowed to be uploaded within src.tar.gz files, so it needs to be repacked anyway. so it comes down to a trivial adjustment: If pbuilder cares that the exact tarball filename matches the version in the changelog file it is trivial to edit it in I would leave that to the DD uploader to adjust or not as they see fit. For me building with `debuild -i -uc -us -b -j6` there is no issue. aside: Anyone know the redistribution terms for vcredist_x86.exe ? MS's download site does not make it obvious and I guess you have to actually install it to get the EULA. - Can a GPL'd Windows program validly ship it as part of the install, or must it be left as a why does it fail with Error 14001? FAQ on the project's homepage? Whatever, we don't need vc_redist.exe in Debian archive -- at least 300 mirrors will have some disk space trashed for no good reasons. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201191740.52905.danc...@spnet.net
Re: RFS: solarpowerlog
On Thursday 22 December 2011 13:37:36 Tobias Frost wrote: Dear mentors, I am looking for a sponsor for my package solarpowerlog. * Package name: solarpowerlog Version : 0.21-1 Upstream Author : Tobias Frost t...@coldtobi.de * URL : http://sourceforge.net/projects/solarpowerlog/ * License : GPL, LGPL Section : utils Hi, Few more comments, actually this is my first impression looking at your source package. Embedded (external) code copies is almost always a bad idea, security-wise, and places burden on -security team, -release team, and what not, to identify and update potentially erroneous code copy. $ cat extlibs/README ~~ In this folder, external code is placed which is used by solarpowerlog but which is not available through debian packages: Please check the projects information for details about copyright, license and authors -- the packages are provided as is. Folder License Origin ctemplate GPL http://libctemplate.sourceforge.net Used for templating the HTML output Modifications: Added C++ Wrapper to the header file. Emits smaller pages due filtering double-blanks Folder License Origin dbixx LGPL2.1 http://cppcms.svn.sourceforge.net/viewvc/cppcms/dbixx/trunk/ CppCMS LibDBI C++ Wrapper -- C++ Web Development Framework Modifications: ~~ Sure, there are quite a few embedded copies already [1], and it would be sad to keep adding even more. IMO, packaging dbixx and ctemplate separately should be the way to go, so they could be easily identified in case of trouble, fixed just once, and potentially re-used as build-dependencies by other packages. However, as far as I can see it, there is unfortunate upstream name clash. The source package name of 'ctemplate' has already been taken by another unrelated package, so maybe you can put 'html' in the source and binary package names (perhaps 'chtmltemplate'?) if you decide to package and maintain this one: http://libctemplate.sourceforge.net separately. [1] http://wiki.debian.org/EmbeddedCodeCopies -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112221506.29746.danc...@spnet.net
Re: RFS: solarpowerlog
On Thursday 22 December 2011 23:49:36 Tobias Frost wrote: Hallo George, Hoi, (top posting is not preferred:) dbixxx is currently not used and could be removed for the moment -- I only have a feature branch that needs this library, but this feature is quite low priority for the moment. (Probably best I remove it from trunk for the time being...) Okay, let's forget dbixx for a while. About ctemplate -- this is unfortunatly I library I really needed for a key feature of solarpowerlog. (solarpowerlog statically links to it) I fear that this library is not very often used in other projects, so I cannot tell if it would be accepted by debian as an own package. Also upstream of this library seems not to be active, last release was in 2009. So basically libctemplate could also be considered more as a kind of a part of solarpowerlog than an own library. Of course I monitor upstream for any changes. Well, you can't have it both ways, either it has its own upstream (and so packaged separately as source, and resp. binary packages) or you claim to adopt it upstream jammed into your own project upstream. Even in that latter case, you can still split separate shared library and -dev binary packages. Of course, it would be better to be packaged as a separate source package, since it is still a separate upstream project, and it doesn't even look tiny to be merged into another, larger one. Nethertheless, I was already thinking about packaging it (if it can be accepted in debian), but I thought to postpone this for a moment until I gained some experience in art of packaging. There is no rush, have your time. My question is, would it be ok -- in this circumstances -- to keep ctemplate part of solarpowerlog for the time being? Why going that route? It would be a compromise, which could be avoided. You don't want your favorite distro to be full of packaged stuff, which embeds copies and statically links to them :) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201112230120.34136.danc...@spnet.net
Re: RFS: cppcheck, new upstream version 1.50
On Monday, August 15, 2011 12:41:29 AM Reijo Tomperi wrote: Hi, New upstream version was released, so I made a new Debian package of it. I'm again looking for a sponsor for it. It is lintian clean and builds with cowbuilder. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cppcheck Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.50-1.dsc Closes bugs: #632084 ftbs with --as-needed Original 1.50 didn't pass make test so there is one patch applied with this version to fix that problem. Hi, JFYI, also hinting co-sponsors :) I'll try to have a look in the coming days, unless someone did it before me. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: Nitpicking: you are doing it wrong
On Saturday, July 09, 2011 12:41:09 AM Leo costela Antunes wrote: On 08/07/11 22:23, Thomas Goirand wrote: On 07/08/2011 08:47 PM, Scott Howard wrote: Right now, the general consensus is the dh and cdbs produce debian packages that are easier to maintain in the long run (if the sponsor has to take over maintenance of the package or if NMUs are required in the future.) I really would like you to explain WHERE you saw such a consensus. When it goes down to myself, I would *not* sponsor a package that is using either dh or CDBS, because I like to be in the control and see what's going on. I believe that CDBS/dh is hiding what's necessary to do a good packaging, and is calling too many unnecessary helpers, which slows down the build process. Also, with dh_override_*, if you have a lot of them, it soon becomes unreadable. That's only my opinion though, but I suspect that I might not be the only one to think this way. In anyways, I don't see at all a consensus here!!! Seeing what's going on is important for learning and for debugging. Thankfully debugging with dh is pretty mature, should you happen to need it (don't really know about cdbs), but having to read a non-dh-using rules file to understand exactly what happens when and why can be a lot of work and shouldn't be imposed on your fellow DDs if you don't have a good reason for it (curiosity and a micro-management tendency are not good reasons; funky non-standard build-systems are) Please use dh/cdbs/whatever other means necessary to make your packaging work easy to read and understand. Don't make the packaging more complex for other people just because you want to know what's going on. That sounds awfully like NIH[0]. You never know who might have to NMU it, make QA uploads, etc and even you yourself might find it pretty hard to remember why you did something in this particular fashion, when it actually could just as well be done in a more common way. Not using these tools goes against your own advice here[1]: you're making the life of other developers who have to look at your code harder for no reason. Or to put it more succinctly in your own words: otherwise, you have no rules at all and it's a mess. And your performance argument seems like a dud unless you can provide some evidence that you actually save a significant amount of time by not using dh/cdbs/whatever during package builds (and by significant I mean more than just a couple of seconds per build). + a debhelperized use pattern, for performing common tasks, is very likely to be way more robust than a 200 lines of (self-tested) NIH thing, simply because thousand of people using/testing it. It is about re-use of well tested code, a lot of wisdom has been accumulated and implanted during the years. + If we were to live with the old concepts and old patterns, which might have been valid a decade ago, then there would be no progress and inventions at all. Debhelper is the perfect compromise (as design) and a giant step upward (as implementation). Cheers [0] http://en.wikipedia.org/wiki/Not_Invented_Here [1] http://lists.debian.org/msgid-search/4e176b0d.8060...@debian.org -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107090111.23445.danc...@spnet.net
Re: RFS: roxterm (updated package)
On Thursday, June 23, 2011 07:33:58 PM Tony Houghton wrote: Dear mentors, I am looking for a sponsor for the new version 1.22.2-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. This release is to fix a bug with compositing/colormaps. See: https://sourceforge.net/tracker/?func=detailaid=3314176group_id=124080a tid=698428 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.22.2-1.dsc I would be glad if someone uploaded this package for me. Uploaded, thanks for your work. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: cppcheck, new upstream version 1.49
On Tuesday, June 14, 2011 09:57:33 PM Reijo Tomperi wrote: Hi, New upstream version was released, so I made a new Debian package of it. I'm again looking for a sponsor for it. It is lintian clean and builds with cowbuilder. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cppcheck - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.49-1.dsc Fix segmentation fault with asm code. Closes: #625959 Hi, we are now looking into that (irc meeting)... -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106142241.06701.danc...@spnet.net
Re: RFS: cppcheck, new upstream version 1.49
On Tuesday, June 14, 2011 10:41:06 PM George Danchev wrote: On Tuesday, June 14, 2011 09:57:33 PM Reijo Tomperi wrote: Hi, http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.49-1.dsc Fix segmentation fault with asm code. Closes: #625959 we are now looking into that (irc meeting)... Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
On Thursday 02 June 2011 16:38:00 Tony Houghton wrote: Dear mentors, I am looking for a sponsor for the new version 1.22.1-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. Amongst other things this version fixes a bug which, although unreported, could be quite serious, especially for new users. In version 1.21.4-1 the profile editor failed to respond to changes in the text entry fields, making it impossible to edit these options without resorting to hacking the options files. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.22.1-1.dsc Uploaded. Thanks for taking care of the bugs. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: stx-btree (updated package)
On Monday 23 May 2011 09:23:27 Ury Stankevich wrote: On Sat, May 21, 2011 at 10:29 AM, George Danchev danc...@spnet.net wrote: Package looks good, though I'd like to: 1) drop quilt from Build-Depends. Hi, i'm not really sure if i should drop quilt from Build-Depends, since one tine patch still here. (yes, i made a bit of mess here: patch 10* is not really required, so i've drop it first time, but... i've revive it later, since one can build package w/o wx ) You don't need to build-depend on 'quilt' with '3.0 (quilt)' source format if you don't have patch/unpatch logic in your debian/rules; they are applied on unpack phase. This is your case, hence I pointed you to FAQ #2. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105240925.48962.danc...@spnet.net
Re: RFS: stx-btree (updated package)
On Tuesday 24 May 2011 11:17:56 Ury Stankevich wrote: On Tue, May 24, 2011 at 12:06 PM, Ury Stankevich ury...@gmail.com wrote: On Tue, May 24, 2011 at 10:25 AM, George Danchev danc...@spnet.net wrote: You don't need to build-depend on 'quilt' with '3.0 (quilt)' source format if you don't have patch/unpatch logic in your debian/rules; they are applied on unpack phase. This is your case, hence I pointed you to FAQ #2. Hi, hm... i make(and upload) such package, but now it have a lintian error: E: stx-btree source: missing-build-dependency quilt (= 0.46-7~) fixed! ps: i should read manuals better ;) Uploaded. Thanks for you work. Next time: a) check with latest standards-version; b) optionally, if you want dpkg-source1) to create debian.tar.bz2 for you (to look consistent with orig.tar.bz2) you can put: compression = bzip2 in debian/source/options -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS or Review: nzbget
On Sunday 22 May 2011 20:28:01 Andreas Moog wrote: Dear mentors, Hi, Vote (signed): +1. looks a good one, in a sense I'm unable to find a flaw :-) I hope you find a sponsor who'll be actually using it. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: stx-btree (updated package)
On Thursday 19 May 2011 16:54:15 Ury Stankevich wrote: On Wed, May 18, 2011 at 7:42 PM, George Danchev danc...@spnet.net wrote: As a start your debian/changelog does not mention that a patch was dropped since it has been applied upstream. It is not a big deal in that particular case, but changelog entries are meant to be read by a much broader audience, than sponsoree and sponsor set. So, yes, expected behavior is to document every single change, since users draw conclusions we can hardly predict upon a release. Hi, Hi, i had uploaded an updated version. (add changelog entry about merged patch, restored patch for configure ) Package looks good, though I'd like to: 1) drop quilt from Build-Depends. 2) finally use upstream's bz2 tarball, instead of me diffing your orig.tar.gz against it to be sure nothing has been changed by accident. See, FAQ #2 and #5 at: http://wiki.debian.org/Projects/DebSrc3.0 Fine with you? ps: please, CC'me on reply. CC'ed. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105210929.32369.danc...@spnet.net
Re: RFS: stx-btree (updated package)
On Wednesday 18 May 2011 16:11:36 Ury Stankevich wrote: Dear mentors, Hi, http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.6-1.dsc I would be glad if someone uploaded this package for me. I will have a closer look in the next few days unless anyone else sponsor it in the meantime. As a start your debian/changelog does not mention that a patch was dropped since it has been applied upstream. It is not a big deal in that particular case, but changelog entries are meant to be read by a much broader audience, than sponsoree and sponsor set. So, yes, expected behavior is to document every single change, since users draw conclusions we can hardly predict upon a release. ps: please, CC'me on reply. Done. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105181842.48065.danc...@spnet.net
Re: bt747: doubts on licenses and embedded libraries
On Sunday 15 May 2011 14:48:07 Eric Lavarde wrote: Hello Monica, Hi, interesting that you're now working on bt747: I'm also using this program to download my GPS tracks and flag my photos, wanted as well to package it, and basically silently gave up as I looked into it :-P I'd actually favor your decision, instead :-) Anyway I'm happy that someone has more courage and/or time to do it! On 15/05/11 13:22, Mònica Ramírez Arceda wrote: El dg 15 de 05 de 2011 a les 19:08 +0800, en/na Paul Wise va escriure: Yep, package any embedded code copies separately. For modified code copies, try to get the changes into their proper upstream or the Debian package if it exists. Ok, I'll try it, altough this library doesn't exist in Debian, for now. But I don't understand what I have to do when I have these changes :-( To be honest, I had the same problem as you with Freeplane and JOrtho, and I decided to keep JOrtho as part of the freeplane package, under the binary name libjortho-freeplane-java. The reasons were: - JOrtho was not in Debian either - JOrtho seemed not very active (dead?). - the changes done by the Freeplane developer on JOrtho were already raised to the JOrtho team but still not included though compatible. - by having a separate binary package, I can change the dependencies if required at some point in time, so it doesn't close any future option. Well, in my opinion, these are no good reasons to fold even more nearly unmaintained pieces of code (I admit, I haven't looked at JOrtho) inside source packages targeted to the Debian archive. This would open the door for more burden possibly to be placed on Release Team, Security Team, QA team, possible NMUers, etc shoulders. I believe packages should enter Debian archive whenever 'they are ready' to meet a certain threshold, at least (working with upstream upfront until the issues are resolved is the way to go), instead of getting rot inside the unstable or testing suites or maintained via nmus because the project as a whole approaches a release. Cleaning up or reducing the amount of embedding copies is a daunting task. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105151549.45236.danc...@spnet.net
Re: bt747: doubts on licenses and embedded libraries
On Sunday 15 May 2011 21:01:44 Mònica Ramírez Arceda wrote: Hi, To be honest, I had the same problem as you with Freeplane and JOrtho, and I decided to keep JOrtho as part of the freeplane package, under the binary name libjortho-freeplane-java. The reasons were: - JOrtho was not in Debian either - JOrtho seemed not very active (dead?). - the changes done by the Freeplane developer on JOrtho were already raised to the JOrtho team but still not included though compatible. - by having a separate binary package, I can change the dependencies if required at some point in time, so it doesn't close any future option. Well, in my opinion, these are no good reasons to fold even more nearly unmaintained pieces of code (I admit, I haven't looked at JOrtho) inside source packages targeted to the Debian archive. This would open the door for more burden possibly to be placed on Release Team, Security Team, QA team, possible NMUers, etc shoulders. I believe packages should enter Debian archive whenever 'they are ready' to meet a certain threshold, at least (working with upstream upfront until the issues are resolved is the way to go), instead of getting rot inside the unstable or testing suites or maintained via nmus because the project as a whole approaches a release. Cleaning up or reducing the amount of embedding copies is a daunting task. Ok. So I understand the best way to do it would be packaging this modified library in a separated package. This library is based on swingx-ws (and as far as I see it is an active project). Altough swingx-ws is not in Debian, I suppose I should package the modified libray with a name like libbt747-swingx-ws-java. Is it right? If you think I should throw in the towel, you can tell me sincerely ;-) but I would like to give this package a chance (I contacted with upstream and he is very responsive). I'm not well prepared to comment on that particular set of packages (maybe the Debian Java team would tell better), but: * if swingx-ws is not in Debian yet, and your prospective packages depend on it, package that first (as a separate source package). * if libbt747-swingx-ws-java needs to be a modified library of $something, then questions are: why are these modifications not tried to be pushed upstream in the first place? In case of vanished or irresponsible upstream I guess you should be prepared to effectively become an upstream for it. Package that as well (separate source package too). Thanks for all your answers!!! Welcome. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105160101.36500.danc...@spnet.net
Re: RFS: rsplib-2.7.11 (implementation of the IETF RSerPool framework and example applications)
On Friday 06 May 2011 13:32:41 Mahyuddin Susanto wrote: On 05/06/2011 04:55 PM, Thomas Dreibholz wrote: The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/rsplib - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/rsplib/rsplib_2.7.11-1.dsc I would be glad if someone uploaded this package for me. I'm now DD but here is my review: - debian/control: current Standard-Version is 3.9.2 - debian/copyright: Format-Specification is empty. - debian/changelog: I think its better to use Initial packaging (Closes: #nnn) rather than Closes Debian ITP bug with wnpp and lintian complain: N: Processing binary package librsplib2 (version 2.7.11-1) ... W: librsplib2: syntax-error-in-debian-changelog line 68 found trailer Yes, the debian/changelog could be improved a bit. I'd also like to add that some binaries with too generic names like [1] are being brought to the system by rsplib-tools package. These might look convenient, but are likely to clash (as in a file name conflict) sooner or later on whatever system or distribution. Other than that, the style looks impressive, and I wish we could have more packages like that in the Debian archive. Unfortunately I can't upload that, as I'm not familiar with RSerPool (and that implementation in particular) nor I could perform any sensible testing of it. I really hope you find a proper sponsor(s). [1] /usr/bin/terminal /usr/bin/server -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201105061831.52007.danc...@spnet.net
Re: RFS: frei0r (updated package)
On Friday 29 April 2011 11:46:26 Jaromil wrote: dear George, Hi, On Wed, 27 Apr 2011, George Danchev wrote: The upload would fix these bugs: 459940 Just to let you know, this is a wrong bug number to close. ack. i understand it is an ubuntu bug number. fact is that i see these bugs linked from my QA debian page. is there a notation for fixes to ubuntu bugs in packages, or we really live on different worlds? Surprisingly, there is. From what I've seen from other packages, like freetype for instance, this should work for both Debian BTS (debbugs) and launchpad: Closes: #aaa, LP: #bbb aaa - Debian BTS bug number bbb - Launchpad bug number or just (if there is no corresponding debbugs number) LP: #ccc -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104291236.52512.danc...@spnet.net
Re: RFS: stx-btree (updated package)
On Thursday 28 April 2011 13:55:29 Ury Stankevich wrote: Dear mentors, Hi, The upload would fix these bugs: 624351 http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.3-4.dsc I would be glad if someone uploaded this package for me. Good [1]. Uploaded. Thanks! (JFTR: you push that upstream, if you haven't already) PS: I'm not subscribed to the list, please CC'me on reply. Done. [1] http://gcc.gnu.org/gcc-4.6/changes.html Most libstdc++ standard headers have been changed to no longer include the cstddef header as an implementation detail. Code that relied on that header being included as side-effect of including other standard headers will need to include cstddef explicitly. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: [Fwd] Bug#621966: hasciicam: FTBFS: hasciicam.c
On Wednesday 27 April 2011 10:37:23 Jaromil wrote: On Tue, 26 Apr 2011, George Danchev wrote: to make it really clear let me specify that i'm not bashing Lucas for filing a bug here, nor the maintainers of hasciicam for giving it a very low priority: i'm trying to give an account from below on how things look to an upstream author. Maybe it is about time to be part of the solution. sure! that is my intention. but then once you are inside it's hard to consider how things look from the outside. so i hope at least this discussion served to give such a picture. The picture depends on too many factors, so I'd hesitate to draw any conclusions. i've had the luck to interact with some of the best DD who, given access to upstream git repository, have given shape to some of the most complex yet well working autotools setups i've ever seen :D even becoming software contributors... This shouldn't come as a surprise. so mine is really not a complaint about the human interaction, but about the automatised part, which doesn't presents opportunities for upstream developers to get into the debian flow and interact with its infrastructure, rather than sending them to upload stuff and beg mentors for attention. The largest, tightly integrated free software repository on Earth (which might easily score a Guinness record if you look of the insane amount of the archive or cd/dvd/bd images produced on a weekly basis), has not grown due to frivolous unsanctioned uploads of anything free that flew by... I believe the foundation is merely based on policies, procedures, priorities, and human time of course. Having that said, one of the easiest ways to get into Debian flow and interact as well, is to land a hand to one of the (possibly core) Teams: http://wiki.debian.org/Teams if your contributions are found to be useful (bug fixes, etc ... you could do an upstream job too), chance are you get fast-forwarded in a pretty timely fashion. This shouldn't come as a surprise, too if you look at some of the recommendations sent to debian-newmaint. I'd still suggest you reconsider the DM/DD links. sure i was already. it's my time to get bashed now on http://lists.debian.org/debian-newmaint/2011/04/msg00046.html Good. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104271116.50419.danc...@spnet.net
Re: RFS: frei0r (updated package)
On Wednesday 27 April 2011 12:20:12 Jaromil wrote: Dear mentors, Hi, I am looking for a sponsor for the new version 1.3-1 of my package frei0r. It builds these binary packages: frei0r-plugins - minimalistic plugin API for video effects, plugins collection frei0r-plugins-dev - minimalistic plugin API for video effects, header files The package appears to be lintian clean. The upload would fix these bugs: 459940 Just to let you know, this is a wrong bug number to close. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/f/frei0r - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/f/frei0r/frei0r_1.3-1.dsc I would be glad if someone uploaded this package for me. I don't feel comfortable with multimedia stuff, but you probably want to join Debian pkg-multimedia group, to help and get helped with sponsoring, as you seem to have several multimedia packages. http://wiki.debian.org/DebianMultimedia/DevelopPackaging also linked from there: http://wiki.debian.org/DebianMultimedia/Sponsoring -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104271749.58327.danc...@spnet.net
Re: [Fwd] Bug#621966: hasciicam: FTBFS: hasciicam.c
On Tuesday 26 April 2011 10:35:51 Jaromil wrote: dear Mentors, Dear Jaromil, first and foremost: thanks for your answers! On Mon, 25 Apr 2011, The Fungi wrote: On Tue, Apr 26, 2011 at 02:28:10AM +0900, Charles Plessy wrote: I see that one uploader of hasciicam is Debian Developer. He is the first person to contact for upload or to recommend you as Debian Maintainer--that is, to give you upload privilege. Specifically, according to who-uploads, 1.0-1 was uploaded to unstable by Giunchedi Filippo fili...@debian.org, so he'd be the right place to start asking for a new upload. sure! and so I did, also knowing Filippo personally. In fact, despite the limited amount of time at his hands, he is doing his best to review my other upstream software package, which is arguably more urgent than hasciicam: freej, for which i've also fixed open bugs but had no way to upload them. Chances are, people with rights to upload are usually busy dealing with more core or important issues (both packaging and upstream-related), you are of course encouraged to help, see links below. ultimately what is very frustrating is just the fact of not being able to upload anything and to keep receiving bug notices that i have fixed in upstream months if not years ago, while volunteering to fix them and being an upstream developer for the software, willing to become DM for his packages. It is *possible* to help both yourself and Debian, see links below. i hope i didn't annoy you too much with my mails and if it was so i apologize for my Mediterranean temper (but well, as your next gathering is in Bosnia/Erzegovina then you'd better start get used). Whines towards reviewing and uploading every single pet package out there might drain scarce resources in insignificant direction. If there are free DD resources, and they are able and comfortable to upload, usually, they do upload. You better think of that drama too, but think hard :-) Fixes and package care are very welcome, but I guess you realize there are priorities and procedures established by a broad agreement among the project, and if you want something to improve, try doing it yourself first as in do-ocracy, see links below of how to help. Of course, amusements and mere pestering doesn't help much communicating your point. one could call it just a rand, but i'm trying to give a point of view of an upstream developer willing to enter Debian and some hints why Why it is so hard to just follow: http://wiki.debian.org/DebianMaintainer http://wiki.debian.org/DebianDeveloper and apply accordingly, help yourself and Debian. Debian is not very popular among software developers.. acknowledging such situations is the first step to make things better, no? Sure, it is a well known fact that the Sun never shines... (don't look out of the window) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ce575ef69f00741cfa8504c526a8...@spnet.net
Re: [Fwd] Bug#621966: hasciicam: FTBFS: hasciicam.c
On Tuesday 26 April 2011 11:53:58 Jaromil wrote: dear George, Dear Jaromil, Let's skip mediterranean style dramas. I had a look at it since it is a relatively simple package one can quickly learn to grasp and you fix a FTBFS, though the diff compared to what we have in sid is rather large. I also tested it to the extend 'works for me'. Few pointers: 1) upstream ChangeLog is meager. (new header videodev2.h used ... at least?) 2) debian/changelog does not close the proper bug. you can close the manually, but still. 3) debian/copyright lacks the copyright holders of of ftplib.[h|c] 4) you don't use ftplib already available in Debian, but embed an outdated copy of it instead. Headers seem identical, but you miss a check in ftplib.c (see diff). Not a big deal though, but folding these inside your project places burden to security team to identify and update in case of flaw. The rest seems just fine. Note, the package in sid also lacks 3), but I'd rather have this fixed. While at it, what else do you intend to fix? Thanks for your time. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8c2abc26db46817e7162b9627ba38...@spnet.net
Re: [Fwd] Bug#621966: hasciicam: FTBFS: hasciicam.c
On Tuesday 26 April 2011 17:14:24 Jaromil wrote: On Tue, 26 Apr 2011, George Danchev wrote: I had a look at it since it is a relatively simple package one can quickly learn to grasp and you fix a FTBFS, though the diff compared to what we have in sid is rather large. you mean lots changed? well, if you have a look at the frequency of updates in the past... i've spent 3 or 4 years hearing from people how hasciicam wouldn't work on debian and asking them to compile from source to fix... and this is not just the situation of my package. to make it really clear let me specify that i'm not bashing Lucas for filing a bug here, nor the maintainers of hasciicam for giving it a very low priority: i'm trying to give an account from below on how things look to an upstream author. Maybe it is about time to be part of the solution. I also tested it to the extend 'works for me'. Few pointers: 1) upstream ChangeLog is meager. (new header videodev2.h used ... at least?) ok, i'll repair that in the future, i needs some time to reconstruct that history. Good. 2) debian/changelog does not close the proper bug. you can close the manually, but still. should we edit a past entry now? it was fixed in 1.1.1 so i'd rather close it by hand. I added 'closes' in 1.1.1 entry, and built it so that the last two changelog entries will show up in *.changes. BTW will do the rest for us. This way the changelog alone is also descriptive wrt that bug. 3) debian/copyright lacks the copyright holders of of ftplib.[h|c] 4) you don't use ftplib already available in Debian, but embed an outdated copy of it instead. Headers seem identical, ack! thanks for noticing. i've made a new upstream release and package: both remove ftplib from inside the hasciicam code and link it from shared library. Build-Deps reflect this change. http://apt.dyne.org/debian/pool/main/h/hasciicam/hasciicam_1.1.2-1.dsc upstream release: http://ftp.dyne.org/hasciicam/releases Uploaded. Thanks for taking care of that FTBFS, but I'd still suggest you reconsider the DM/DD links. thanks for the review! Welcome. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/293040a66170c3b82b9f44361ff3f...@spnet.net
Re: RFS: alure (updated package)
On Saturday 23 April 2011 10:03:32 Tobias Hansen wrote:
Am 23.04.2011 05:07, schrieb Paul Wise:
I would suggest adding a symbols file so that stuff using the new
symbols gets the new version and anything else gets the old version.
http://wiki.debian.org/UsingSymbolsFiles
On that wiki page it says:
If you find (on some arches) symbols that are exported which are not
supposed to be public, you must not use symbols versioning at all.
If I'm not mistaken, private symbols are exported in the case of Alure
(see [1]). If I run dpkg-gensymbols myself on libalure1 1.1, I also get
such symbols starting with _Z.
Yes, _Z* are private, and are better to be stripped out.
Can I just create a symbols file containing only the public symbols? If
not, why not? What should I do otherwise?
You can, but that won't fix the object files exporting private symbols.
Instead you better suggest alure upstream to use a linker version script [1]
[2], to control symbols publication.
Trivial example (these are public, the rest are stripped out):
LIBFOO_1 {
global:
public_symbol_1;
public_symbol_2;
local: *;
};
Then you can still use dpkg-shlibdeps symbol files to determine the minimal
required version of each dependency.
[1] http://sourceware.org/binutils/docs/ld/VERSION.html#VERSION
[2] http://www.gnu.org/s/hello/manual/gnulib/LD-Version-Scripts.html
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104231050.51565.danc...@spnet.net
Re: RFS: cppcheck, new upstream version 1.48
On Tuesday 19 April 2011 20:36:46 Reijo Tomperi wrote: Hi, http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.48-1.dsc You don't need libtinyxml2.5.3, libpcre3 explicitly listed in Depends in that Thanks, I was a bit unsure about how the depends work. I removed those and uploaded new version (with the same version number 1.48-1). Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: cppcheck, new upstream version 1.48
On Tuesday 19 April 2011 20:36:46 Reijo Tomperi wrote: Hi, http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.48-1.dsc You don't need libtinyxml2.5.3, libpcre3 explicitly listed in Depends in that Thanks, I was a bit unsure about how the depends work. I removed those and uploaded new version (with the same version number 1.48-1). Good. I'll get back to my key within the next 48 hours, so if anyone is willing to upload it before that, please do so. Thank you. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/311affa3fd1db15643175fc2c...@spnet.net
Re: RFS: cppcheck, new upstream version 1.48
On Tuesday 19 April 2011 00:24:36 Reijo Tomperi wrote:
Hi,
Hi,
New upstream version was released, so I made a new Debian package of it.
I'm again looking for a sponsor for it.
It is lintian clean and builds with cowbuilder.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cppcheck
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget
http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.48-1.dsc
You don't need libtinyxml2.5.3, libpcre3 explicitly listed in Depends in that
case, as they could be automatically calculated. You already have
${shlibs:Depends} in there, and dh_shlibdeps calls dpkg-shlibdeps, which does
the right thing calculating the shared library dependencies.
Please see, debian policy 8.6.2 and C.1.4.
If you were trying to fix a hypothetical problem with dependency list that
way (though I see none), that might not be the right treatment to rectify the
cause. Listing these depends explicitly is not incredibly wrong, but might
leave a wrong impression, that something with the automatic dependency
calculation (of an dynamic executable ELF like cppcheck is, unlike say, a
shell or whatever script where ldd could not be of any help) has went wrong,
while it has not.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201104190926.46541.danc...@spnet.net
Re: RFS: sic (updated package/adoption)
On Thursday 31 March 2011 13:39:16 Jeroen Schot wrote: Dear mentors, Hi, sic- simple irc client (sic) The upload would fix this bug: 606083 (ITA) http://mentors.debian.net/debian/pool/main/s/sic/sic_1.1-4.dsc Looks good. Uploaded. Thanks for taking care of orphaned packages. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: scidavis (updated package) - FTBFS
On Thursday 17 March 2011 17:21:08 Ruben Molina wrote: Dear mentors, I am looking for a sponsor for the new version 0.2.4-3 of my package scidavis. It builds these binary packages: scidavis - application for scientific data analysis and visualization The package appears to be lintian clean. The upload would fix these bugs: 618199 (FTBFS) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scidavis - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scidavis/scidavis_0.2.4-3.dsc Uploaded. Thank you for taking care of the bugs. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: Fw: failed hppa build of roxterm 1.21.4-1
On Friday 18 March 2011 15:54:13 Tony Houghton wrote: I received a message (below) about one of the package builders failing on roxterm. The error is: dh_shlibdeps -a Inconsistency detected by ld.so: dynamic-link.h: 187: elf_get_dynamic_info: Assertion `info[20]-d_un.d_val == 7' failed! dpkg-shlibdeps: error: objdump gave error exit status 127 dh_shlibdeps: dpkg-shlibdeps -Tdebian/roxterm.substvars debian/roxterm/usr/bin/roxterm debian/roxterm/usr/bin/roxterm-config returned exit code 127 That's above my knowledge level and I didn't find much useful from Google, but am I right in thinking it's a problem on the builder machine, not with my packaging? My debian/rules is fairly straightforward, not adding much to a minimal dh 7 template. Certainly, this is not your fault. There are various binutils, kernel, and otherwise toolchain issues on hppa, but due to EOL-hardware, lack of resources and interest, chances are they are unlikely to be resolved [1] [1] http://lists.debian.org/debian-hppa/2011/02/msg3.html -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103181852.47712.danc...@spnet.net
Re: RFS: bashburn
On Monday 14 March 2011 00:28:57 Andreas Noteng wrote: Dear mentors, Hi, I am looking for a sponsor for my package bashburn. * Package name: bashburn Version : 3.0.1-1 Upstream Author : Anders Lindén anders.lin...@gmail.com * URL : http://bashburn.dose.se/ * License : GPL-2 Section : utils It builds these binary packages: bashburn - A utility to simplify cd/dvd burning at the command line The package appears to be lintian clean. The upload would fix these bugs: 497092 My motivation for maintaining this package is: I think this is a neat application that deserves a place in debian. Just to let you know that there is already xorriso in Debian, which is both cmd-line burner and image manipulator tool and it doesn't share any code base with known such tools. Have a look at it (actually, the source packages are libburn, libisofs, libisoburn), and if you like it and want to help with its maintenance, please be my guest :-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103142132.17249.danc...@spnet.net
Re: RFS: cppcheck, 1.47-4
On Monday 07 March 2011 22:11:23 Reijo Tomperi wrote: Hi, Hi, Cppcheck 1.47-3 is already accepted, but it fails to build on some platforms. This version (1.47-4) contains a patch from upstream which tries to fix that bug. * 3rd try fixing FTBFS in multiple architectures. Closes: #613308 My regular sponsor has not answered to my emails for almost two weeks now, so I'm requesting a sponsor. It is lintian clean and builds with cowbuilder. (or at least did so when I created it) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/cppcheck - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.47-4.dsc If no one steps up, I'll try very hard to have a look at that to the end the the week. I just need to steal some free time after that. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103080842.35682.danc...@spnet.net
Re: RFS: stx-btree (updated package)
On Friday 25 February 2011 09:32:30 Ury Stankevich wrote: Dear mentors, Hi, I am looking for a sponsor for the new version 0.8.3-3 of my package stx-btree. http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.3-3.dsc I would be glad if someone uploaded this package for me. Uploaded. Thanks for your work. ps: this package is a long time waiting for progress ( http://thread.gmane.org/gmane.linux.debian.devel.mentors/46102 ) pps: please, CC'me on reply. Done. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: Open RFS lacking (further) response
Quoting Michael Tautschnig m...@debian.org: Hi Michael, I liked the idea of requesting reviews from people whose packages will get sponsored; but I'd just ask for doing that voluntarily. I probably should have taken the chance to ask people for doing so yesterday, maybe I'll even send those people another email. One technical question, however, remains: Could we have some list of packages that remain to be reviewed? Just telling people please review some package is pretty awkward... It seems to me that this technical question is automatically sorted by itself, i.e. any package listed at sponsor-pkglist [1] with 'Needs a sponsor' != 'No, Thanks' would make a good candidate for volunteer reviewing. [1] http://mentors.debian.net/cgi-bin/sponsor-pkglist -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101030113354.38021rtsa2swz...@webmail.spnet.net
Re: RFS: bgoffice (QA upload, RC bugfix)
Yavor Doganov writes: Dear mentors, -- The upload would fix these bugs: 589851 http://mentors.debian.net/debian/pool/main/b/bgoffice/bgoffice_3.0-11.dsc Uploaded. Thank you for the fix. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, I am looking for a sponsor for the new version 1.18.5-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The upload would fix these bugs: 589871 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.5-1.dsc I would be glad if someone uploaded this package for me. Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: scrot (updated package, fix a bug)
William Vera writes: Dear mentors, Hi, I am looking for a sponsor for the new version 0.8-12 of my package scrot. It builds these binary packages: scrot - command line screen capture utility The package appears to be lintian clean. The upload would fix these bugs: 586769 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scrot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scrot/scrot_0.8-12.dsc Looks good. The patch provided by #586769 makes sense and is innocent enough. 1) Please, communicate all of these debian/patches upstream in whatever manner (the general aim, in the long run, is to share and merge with upstream, and not to diverge developing in debian/patches), and if any of them would not be accepted upstream for whatever reason it would make sense reflect that in their headers. 2) 'DM-Upload-Allowed: yes' is set by whoever sponsor, though in your case it would make sense, but don't be that helpful ;-) Let me know the status of 1) and I will sponsor. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: scrot (updated package, fix a bug)
William Vera writes: Hello On Fri, Jul 2, 2010 at 10:59 PM, George Danchev danc...@spnet.net wrote: William Vera writes: Dear mentors, Hi, I am looking for a sponsor for the new version 0.8-12 of my package scrot. It builds these binary packages: scrot - command line screen capture utility The package appears to be lintian clean. The upload would fix these bugs: 586769 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/scrot - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/scrot/scrot_0.8-12.dsc Looks good. The patch provided by #586769 makes sense and is innocent enough. 1) Please, communicate all of these debian/patches upstream in whatever manner (the general aim, in the long run, is to share and merge with upstream, and not to diverge developing in debian/patches), and if any of them would not be accepted upstream for whatever reason it would make sense reflect that in their headers. thanks for the advice, just sent an email to the upstream informing about patches in the package and asking for their comments and suggestions. I will keep you informed of response. :) Good. 2) 'DM-Upload-Allowed: yes' is set by whoever sponsor, though in your case it would make sense, but don't be that helpful ;-) Why not? all my packages with DM Upload Allowed are in better shape that others :P I think it's helpful for small issues and changes (and why not, maybe urgent issues) I'm not claiming that you won't get DMUA=y and I know how useful it is ;-) However, as cited at http://wiki.debian.org/DebianMaintainer cite The DM-Upload-Allowed: yes control field should be set by the sponsor (or by the sponsoree after a request from the sponsor), not silently added by the sponsoree without coordination with the usual sponsor. The field should only added to a source package after the sponsor is satisfied with the sponsoree's ability to handle that specific package, usually this happens after several good-quality uploads. /cite So far, there is only one upload done by me and one by another DD and it seems you are capable to maintain that package yourself alone, thus let us track your record for few more successful uploads, then we will eventually ask you to set DMUA=y or set that ourselves as well. It is not that a big deal, but the whole thing is running on procedures, so in general we are better following them as well, unless we have some very good reasons to dispute on changing them. To summarize: don't get chocked if DMUA=y gets removed by a sponsor, and re- added back after few more uploads. Also, don't get amazed if your sponsors screen how you are following the procedures ;-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, Hi, I am looking for a sponsor for the new version 1.18.4-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.4-1.dsc I would be glad if someone uploaded this package for me. The changes file includes 1.18.3-1 which was not uploaded because my usual sponsor, George Danchev, had reservations http://www.mail-archive.com/debian-mentors@lists.debian.org/msg68488.html . However, due to a bug which can cause roxterm to crash unpredictably (very serious because it can take any number of child processes with it), discussed at http://sourceforge.net/projects/roxterm/forums/forum/422638/topic/3711088 , I think replacement of 1.18.2-1 should be given fairly high priority. It took me some time, and as I understand it, it is rev763, which fixes the above mentioned issue, thus wouldn't be safer to just backport that change (just reflecting connected/disconnected state) to the version in sid? It should also be fairly easy. I should also admit that the subsequent COLORTERM changes look trivial, and very low risk, thus these should also be acceptable, but if you ask me I'd still go for former (rev763 only), unless you have a better reason for the latter (more verbose changlogs are generally more helpful;-), so please let me know. P.S. I no longer intend to use that package, thus you will need another sponsor for it or alternatively complete the DM-state. However I intend to review and upload your urgent 'fixes' until after release of squeeze. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Tony Houghton writes: On Fri, 25 Jun 2010 21:23:46 +0300 Hi, George Danchev danc...@spnet.net wrote: Tony Houghton writes: However, due to a bug which can cause roxterm to crash unpredictably (very serious because it can take any number of child processes with it), discussed at http://sourceforge.net/projects/roxterm/forums/forum/422638/topic/3711 088 , I think replacement of 1.18.2-1 should be given fairly high priority. It took me some time, and as I understand it, it is rev763, which fixes the above mentioned issue, thus wouldn't be safer to just backport that change (just reflecting connected/disconnected state) to the version in sid? It should also be fairly easy. I should also admit that the subsequent COLORTERM changes look trivial, and very low risk, thus these should also be acceptable, but if you ask me I'd still go for former (rev763 only), unless you have a better reason for the latter (more verbose changlogs are generally more helpful;-), so please let me know. You're quite right, I need to get in a habit of being more verbose in my commit messages to generate a better ChangeLog. Reviewing the other changes myself: I've improved the documentation, including changing a bit about how to enable configurable keyboard shortcuts in GNOME, which had become out of date. Documentation changes shouldn't give cause for concern about stability? Looking at r747 again, I can't find the bug report which triggered that, but ISTR there was a visible problem. I think there's the possibility of a divide by zero error, and it's a one line fix, so I really think I should include that. r746 is a one-liner which fixes two not quite correct behaviour bugs https://sourceforge.net/tracker/?func=detailaid=2997666group_id=124080a tid=698428 and https://sourceforge.net/tracker/?func=detailaid=2997661group_id=124080a tid=698428. r745 is more complicated and most people wouldn't notice the problem https://sourceforge.net/tracker/?func=detailaid=2999166group_id=124080a tid=698428 so I'm happy to leave that out. But with all the above that I think should go in, plus you accepting the new *TERM feature, it seems like we might just as well release 1.18.4-1. After thinking about it for a while, I decided to agree with your recommendation, and uploaded 1.18.4-1 as is. Let's hope it brings more benefits to the users, than eventual regressions. If you disagree and just want the important fixes, do you suggest merging them into one backported-bugfixes patch or use a separate one for each feature? If something goes wrong (i.e. regression is found) with 1.18.4-1, I'd appreciate if separate bug fixes (against that same version) are splitted in separate patches. P.S. I no longer intend to use that package, thus you will need another sponsor for it or alternatively complete the DM-state. However I intend to review and upload your urgent 'fixes' until after release of squeeze. Can I ask why you no longer intend to use it? It shouldn't matter if you Well, it is no longer the lightweight terminal emulator, as it used to be, its ldd score is basically the same as the one of gnome-terminal or konsole. I also consider 'no dbus support' a feature. However, these are really a matter of personal preferences, both as: package already has its user base and tons of other software uses dbus, so it is already useful for someone else. This basically leads us to the consequence that someone else using it should take care of reviewing and uploading. However, as an interim solution, I intend to spend few of my time uploading it, until you manage to find another sponsor or complete the DM. It is worth, since your efforts/time won't be left unaddressed/wasted, and hopefully roxterm users won't be left in the cold. stop sponsoring it, because at least one other DD has expressed interest, and I am going to apply for DM. I've already had my key signed but the signer is soon going to replace his key with a more secure one and I thought maybe I should wait until he's signed mine with his new key. Or does that not really matter at all and I should forge ahead ASAP? Well, you should wait for him to sign your key with his newer one and then proceed with DM. Take your time, I don't intend to vanish abruptly, especially in the case of any hypothetical regressions being found. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: egroupware (fixes critical bug)
Thomas Koch writes: Hi Lars, I know you'll hate me for this, but I'd like to suggest to drop eGroupWare from Debian. You may have invested a lot of time in the package by now. It has been dropped for some months now: #574186, though an old version still left in stable. eGroupWare has been the first Open Source project I've been involved with back in 2006. I stopped working with eGroupWare because the code quality of the project was unbearable. Some time later two core contributors founded the tine project for the same reason. - eGroupWare itself started as a fork from the ancient phpGroupWare, also in some conflict I don't know enough about. eGroupWare is an ancient codebase from the beginnings of PHP (version 3?). For everything that people hate about PHP you can find examples in eGroupWare's codebase. It's a pain to develop or maintain this. Nobody should recommend eGroupWare to anyone. Debian should not ship it. I couldn't find the current eGroupWare SVN repo on the new homepage to look if the code has changed since I last saw it. - Why is the whole developer section dropt from the current homepage? It is also my own belief that the only way to fix it is to rewrite it, from scratch and whoever intends to reupload once again should better think of it thrice ;-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: myscreen
Clément Mondon writes: Dear mentors, Hi, some pointers you may want to address: * [lintian ] you want to copy the 'name address' from debian/control to the tail of your last entry in debian/changelog (or contrariwise), since they differ in the spelling of the first name and lintian rigthfully assumes this is an NMU, and insists on seeing debian revision of -x.y, which you don't want since you are not preparing an NMU as I can see it. * [me] the *orig* tarball name should not include the debian-revision (-7 in your case), but .orig: you want: myscreen_0.7.8.orig.tar.gz instead of: myscreen_0.7.8-7.tar.gz. * [cppcheck] you want that initialized or the 'user time' won't be valid: [./cpu/cpu.c:59]: (error) Uninitialized variable: _cpu_u I am looking for a sponsor for my package myscreen. * Package name: myscreen Version : 0.7.8-7 Upstream Author : Clement Mondon clement.mon...@gmail.com * URL : http://www.clement-mondon.fr/myscreen * License : GPL Section : misc It builds these binary packages: myscreen - A tab system and display system statistics for screen. My motivation for maintaining this package is: Make other people benefit from my work. MyScreen is expected to consume very few resources and it is particularly suitable for systems with limited resources. MyScreen include screen configuration file and a program includes that provides several statistics. Configuration file of screen allows to enable hardstatus bar in the manner of a tab system of graphical terminal. The program myscreen-stats provides several informations : [lintian] is picky about 'informations', maybe you want: ... provides the following information: number of users connected, uptime, upload and download rate, wifi quality, loadaverage, number of processes, cpus, disks, ram and swap. MyScreen is much lighter than byobu. MyScreen will not allow [my own opinion] such comparisons are best to be avoided in package descriptions, Otherwise, the package looks good, though I didn't have enough of time to test it, but I hope you will find a sponsor. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: rush
Tim Retout writes: On 4 June 2010 10:45, Mats Erik Andersson mats.anders...@gisladisker.se wrote: I am seeking an __active__ sponsor for this package. I'm afraid it seems you're stuck with me. ;) At DebConf we (the project) shall have to discuss the sponsoring situation. I will not be attending debconf10, but here are my pointers: * the easy part: there is nothing wrong for non-DD to ask in advance if there are interested sponsor(s) of the piece of software they intend to package or adopt, especially with large and complex pieces. That would avoid wasting their time. * the hard part: DD-body should define a clear priority list of what they are most interested in (in no particular order): + fixing bugs (especially RC) in existing packages + co-maintaining new or existing packages, so that non-DD gather experience and DD are able to track their progress and eventually trust. + advocating new candidates when ready so that they share the sponsorship load (the hardest part: I'm not sure whether this is best to be implemented as a static common source of pointers or dynamically instantiated on per DD or packaging team basis) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFC: Using git/collab-maint/PET for debian-mentors.
Quoting Tim Retout dioc...@debian.org: [Please excuse the long email. I welcome comments.] Hi, a lot of helpful technical details, already used for years [1] (though I don't know what PET is), however I still can't see how the 'splitted brain syndrome' is dealt with, the logical problem, i.e. mentee X spends tons of time on package X, and no sponsor addresses their work, otoh mentee's work on package Y (if spent that way) would be processed in a timely fashion. The keyword in my opinion, is 'sensible communication' beforehand, so that mentees have better view how to spend their time, on what packages, bugs, teams, etc. P.S. I have been co-sponsoring (together with another fellow DD) a handful of c++ dev packages by a non-DD dutch researcher for several years, already. Communication happens completely off-list and without uploads to mentors source package repo, just private mails and vcs. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100613174453.20924ozp3a47i...@webmail.spnet.net
Re: A lot of pending packages
Quoting Klaus Grue g...@diku.dk:
Perhaps maintainers should stand up and review some packages of
their peers?
Absolutely. This already happens a little bit. It would be excellent
if more people could do it.
Maybe my experience with Fedora and Cygwin could be of interest. As
a new packager, I made my first package ('logiweb') and submitted it
to Debian, Fedora, and Cygwin:
Aug 2009 Submitted http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=543550
Sep 2009 Submitted https://bugzilla.redhat.com/show_bug.cgi?id=523715
Mar 2010 Package pushed to Fedora stable
May 2010 Sent ITP to Cygwin
May 2010 Package uploaded to Cygwin
Sep-Mar I corrected the package under guidance of a Fedora sponsor
(thanks). I was also lucky enough that a DD looked at my Debian
package and gave guidance (thanks). But it seems that DD's are
overloaded. At least my package is not in Debian yet.
Once my Fedora package was in shape, I was asked to demonstrate my
technical skills by either preparing one more Fedora package or do a
pre-review of some other package. So I chose to do a pre-review.
I picked a package, but somebody else was faster, and the package
was processed before I could get started. Then I shortlisted ten
packages
I found I was competent to pre-review, waited a few days, three
packages were taken, picked one of the remaining packages, assigned
it to myself, and did the pre-review. When my pre-review was
accepted by my sponsor, my package was uploaded.
Once accepted in Fedora, uploading to Cygwin went very smoothly (thanks).
So this is my experience with Fedora: When I came with my package,
the Fedora community did something for me (reviewed the package)
then required me to do something for them (do a pre-review), and the
package was accepted. That seems quite fair.
Furthermore, Fedora had a list of packages waiting for review, and
it was easy to find one to pick.
I am not saying Fedora is ideal. On a Fedora mailing list, I just
saw an invitation to come and celebrate the one-year anniversary of
a Fedora review request.
My point, however, is that having some sort of formalized way in
which maintainers can unload DDs could be a good thing.
This is really nice experience, however I strongly believe that all of
that is also possible with Debian in its current form. You are allowed
to do any tech work DDs are allowed, except uploading, voting and
reading -private list until you gain DD (or resp. DM status), and it
would be helpful indeed. Simply reviewing and/or uploading packages
for the sake of it does not seem very efficient way to spend human
time and archive space to me, otoh helping neglected packages or
co-reviwing new hot or interesting packages makes sense and is
absolutely possible, but then again people have different interests
sometimes, so finding a match could be an issue, and it actually is
most of the time.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100612161203.93483yyfen7el...@webmail.spnet.net
Re: Replacing my key
Tony Houghton writes: I'm a sponsored maintainer (of roxterm) and I've just approached a local DD to have my key signed. He pointed out that SHA1-generated keys are deprecated so I should probably generate a new, more secure, key. As my old key is already presumably in the system due to existing versions of roxterm, how should I go about replacing it with a new one? Hi, There is nothing to replace. Your source package always gets rebuilt by your sponsors and signed by their own gpg key, i.e. they are responsible for the upload in the same way they are responsible for their own packages uploads. You can check that out with 'who-uploads source_package_name'. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Tony Houghton writes: On Sun, 23 May 2010 16:06:40 +0300 Hi, George Danchev danc...@spnet.net wrote: Tony Houghton writes: I am looking for a sponsor for the new version 1.18.3-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.3-1.d sc I would be glad if someone uploaded this package for me. When I released the previous version I was contacted by a DD offering to sponsor roxterm and help me become a DM, but when I told him George Danchev had already uploaded it he said I didn't need his help after all. This is true. Count me as second advocate, if needed. However, should I try for DM status anyway? Yes, that would speed up the uploads and avoid some time dups: http://wiki.debian.org/DebianMaintainer Hi, This still hasn't been uploaded. Are you waiting for me to become a DM and upload it myself? I've been a bit too preoccupied for that lately, but could probably start now. Well, have your time, and start at your convenience, of course. Or did you send me an email about it to which I haven't replied? I got a notification from the list server last week that my address had been bouncing; hopefully just retry later bounces because it had been down for a few hours. Ops, apparently I forgot to reply to that (i.e. previous) mail for some reason a week ago, sorry about that. I had a look at the src diff against the version in sid, got lost into that, and decided that large change like that to fix few decorative bugs does not justify the risk to eventually introduce fresh bugs to the package already found in sid for a month, while Debian is approaching a release. I'd be glad if a more capable reviewer give it a try., and eventually upload, if necessary. Do we really have good reasons, to worry about roxterm 1.18.2-1 in testing and sid? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: sqlitebrowser (updated package)
Quoting Stefan Haller hali...@googlemail.com: Dear mentors, I upgraded the package “sqlitebrowser” to a new upstream release. The latest release is 2.0b1. That’s why I’ve choosen “1.9+2.0b1-1” as Debian version number. The package uses now the the new dpkg-source format “3.0 quilt”, so I’ve changed many files in the debian/-directory. (I hope this is ok?) The package is not my own package, so if this not the right place to ask, please give me a hint ;) Lintian also complains, because it’s a NMU, but the version number doesn’t reflect this. But I packaged a new upstream release, I don’t know how the version number should look like in such a case.# The pair of maintainer name and the email address given in the last entry in debian/changelog could not be found in Maintainer nor Uploaders fields in debian/control, thus lintian correctly assumes you are trying to prepare an NMU, and insists on seeing a proper NMU version numbering. Either you add yourself as Maintainer or Uploders (lintian is not picky about spaces), with the acceptance of the current maintainer (I can't see any feedback from them in 561643), or prepare a proper NMU (see Debian Developers Reference). However a new upstream version, with so many changes applied, without fixing any RC-bugs does not justifies an NMU. If I were you, I'd probably ping the maintainer, once again via 561643 (though they only had few days to react according to the last entry), and discuss with them if a new upstream version is really warranted (perhaps it fixes important issues?) while the project is trying to approach a release. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524132052.13471tyxk03v3...@webmail.spnet.net
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, Hi, I am looking for a sponsor for the new version 1.18.3-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.3-1.dsc I would be glad if someone uploaded this package for me. When I released the previous version I was contacted by a DD offering to sponsor roxterm and help me become a DM, but when I told him George Danchev had already uploaded it he said I didn't need his help after all. This is true. Count me as second advocate, if needed. However, should I try for DM status anyway? Yes, that would speed up the uploads and avoid some time dups: http://wiki.debian.org/DebianMaintainer -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: Possible trimming of build dependencies
Jakub Wilk writes: Hi, * Tony Houghton h...@realh.co.uk, 2010-05-16, 16:06: override_dh_auto_build: xsltproc --nonet \ --param make.year.ranges 1 \ --param make.single.year.ranges 1 \ --param man.charmap.use.subset 0 \ -o debian/ \ http://docbook.sourceforge.net/release/xsl/current/manpages /docbook.xsl \ debian/gentoo.1.xml dh_auto_build What do those --param options do? make.year.ranges and make.single.year.ranges affect how consequent year elements are rendered; when you turn them on, you'll get: Copyright © 2039-2042 J. Random Hacker istead of Copyright © 2039, 2040, 2041, 2042 J. Random Hacker DocBook XSLs can convert ca. 800 Unicode character into roff sequences. However, for efficiency reasons, only a small subset of these character is used by default. AFAIR this subset doesn't include e.g. the copyright sign, so man.charmap.use.subset=0 is needed to make the conversion sane. Tony, JFTR: for complete parameters reference, see one of docbook-xsl-doc packages, say the -html: file:/usr/share/doc/docbook-xsl-doc- html/doc/manpages/man.charmap.use.subset.html As a reference, cppcheck package does: xsltproc -''-nonet -''-param man.charmap.use.subset 0 \ /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl man/cppcheck.1.xml (which reminds me that /share/xml/docbook/stylesheet/nwalsh/ should be changed to /usr/share/xml/docbook/stylesheet/docbook-xsl/) Also, it seems to me that build-depending on xsltproc docbook-xsl docbook-xml would not extremely trim the bits to be pulled as compared to those pulled in the xmlto case, so don't expect big wins here ;-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005161939.01103.danc...@spnet.net
Re: Possible trimming of build dependencies
Tony Houghton writes: On Sun, 16 May 2010 19:38:59 +0300 George Danchev danc...@spnet.net wrote: Also, it seems to me that build-depending on xsltproc docbook-xsl docbook-xml would not extremely trim the bits to be pulled as compared to those pulled in the xmlto case, so don't expect big wins here ;-) AFAICT the above trio don't depend on the (la)tex packages that xmlto does, and they take a long time to install. Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder --login test says dice wrt build-dependencies drag: # apt-get install xmlto Need to get 468kB/3592kB of archives. After this operation, 20.6MB of additional disk space will be used. Do you want to continue [Y/n]? n # apt-get install xsltproc docbook-xsl docbook-xml Need to get 345kB/3469kB of archives. After this operation, 20.1MB of additional disk space will be used. Do you want to continue [Y/n]? n Both approaches would do, imho. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005162051.47592.danc...@spnet.net
Re: Possible trimming of build dependencies
George Danchev writes: Tony Houghton writes: On Sun, 16 May 2010 19:38:59 +0300 George Danchev danc...@spnet.net wrote: Also, it seems to me that build-depending on xsltproc docbook-xsl docbook-xml would not extremely trim the bits to be pulled as compared to those pulled in the xmlto case, so don't expect big wins here ;-) AFAICT the above trio don't depend on the (la)tex packages that xmlto does, and they take a long time to install. Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder --login test says dice wrt build-dependencies drag: # apt-get install xmlto Need to get 468kB/3592kB of archives. After this operation, 20.6MB of additional disk space will be used. Do you want to continue [Y/n]? n # apt-get install xsltproc docbook-xsl docbook-xml Need to get 345kB/3469kB of archives. After this operation, 20.1MB of additional disk space will be used. Do you want to continue [Y/n]? n Both approaches would do, imho. A slight correction: my main system's apt cache /var/cache/apt/archives/ wasn't perfectly clean, however the drag it is still 3592kB (xmlto) vs.3469kB (trio). -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005162104.33236.danc...@spnet.net
Re: Possible trimming of build dependencies
Jakub Wilk writes: * George Danchev danc...@spnet.net, 2010-05-16, 20:51: Also, it seems to me that build-depending on xsltproc docbook-xsl docbook-xml would not extremely trim the bits to be pulled as compared to those pulled in the xmlto case, so don't expect big wins here ;-) AFAICT the above trio don't depend on the (la)tex packages that xmlto does, and they take a long time to install. Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder --login test says dice wrt build-dependencies drag: # apt-get install xmlto Need to get 468kB/3592kB of archives. After this operation, 20.6MB of additional disk space will be used. Do you want to continue [Y/n]? n # apt-get install xsltproc docbook-xsl docbook-xml Need to get 345kB/3469kB of archives. After this operation, 20.1MB of additional disk space will be used. Do you want to continue [Y/n]? n You don't need docbook-xml if you use --nonet or --novalid: # apt-get install xsltproc docbook-xsl [...] Need to get 0B/2840kB of archives. After this operation, 15.8MB of additional disk space will be used. With --nonet alone and without docbook-xml installed I get a minor nuisance, which might be innocent, since the man-page looks correctly generated to me. xsltproc -''-nonet -''-param man.charmap.use.subset 0 /usr/share/sgml/docbook/stylesheet/xsl/nwalsh/manpages/docbook.xsl man/XXX.1.xml I/O error : Attempt to load network entity http://www.oasis- open.org/docbook/xml/4.5/docbookx.dtd man/XXX.1.xml:62: warning: failed to load external entity http://www.oasis- open.org/docbook/xml/4.5/docbookx.dtd ] ^ OTOH, --novalid (if applicable in that case, of course, well we can always have several invocations of xsltproc with different option sets) really prevents loading dtd, and not having to pull docbook-xml looks like a decent cut, indeed, I agree. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005162131.11002.danc...@spnet.net
Re: Possible trimming of build dependencies
Tony Houghton writes:
On Sun, 16 May 2010 20:51:45 +0300
George Danchev danc...@spnet.net wrote:
Tony Houghton writes:
On Sun, 16 May 2010 19:38:59 +0300
George Danchev danc...@spnet.net wrote:
Also, it seems to me that build-depending on xsltproc docbook-xsl
docbook-xml would not extremely trim the bits to be pulled as
compared to those pulled in the xmlto case, so don't expect big wins
here ;-)
AFAICT the above trio don't depend on the (la)tex packages that xmlto
does, and they take a long time to install.
Well, xmlto does not pull any latex packages AFAICS, and my cowbuilder
--login test says dice wrt build-dependencies drag:
# apt-get install xmlto
Need to get 468kB/3592kB of archives.
After this operation, 20.6MB of additional disk space will be used.
Do you want to continue [Y/n]? n
# apt-get install xsltproc docbook-xsl docbook-xml
Need to get 345kB/3469kB of archives.
After this operation, 20.1MB of additional disk space will be used.
Do you want to continue [Y/n]? n
Looks like you're right.
Yeah, I was, but Jakub changed the rules: xsltproc --novalid and no docbook-
xml is to be dragged. See, the rest of mails in that thread.
I uninstalled a load of tex packages and tried
apt-get build-dep roxterm again and it didn't want to install anything
beyond xmlto. But I'm sure when I ran apt-get build-dep roxterm recently
it downloaded lots of tex packages, and there are no other likely
looking candidates. Perhaps those dependencies have been removed from
xmlto (or moved to Suggests: by the look of it). And it might have been
on one of the Ubuntu machines I sometimes use.
Ahem, I see, mistakes happen, thus clean chroots (and note to myself: clean
apt caches;-) are to be used for such tweaking. In fact, other packages'
{Build-}dependencies change over time, it is pretty common since new versions
are uploaded, improvements are introduced, etc, so we always check when we
need to. To be honest, xmlto's own dependencies (in Debian unstable) look sane
to me, so you might be witnessed some transient inefficiency which has been
subsequently corrected lately.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201005162143.24292.danc...@spnet.net
Re: RFS: cppcheck, new upstream version 1.43
Joachim Reichel writes: Hi, Hi, http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.43-1.dsc Now, a few things worth mentioning: - This version is not compatible with previous version, because: --enable=possibleError prints out error message with this version (possibleError feature is complitely disabled in this version, so to fix it one should just remove that option if it is used) - Man page (which comes from upstream) is not up-to-date considering the above change (I filed a ticket about it to upstream and will probably fix it myself for the next release). Should this version still be uploaded? I checked the package and found no problems. Can't you just remove the --enable=possibleError option from the manpage (it's not listed in the -h output)? Then I'll upload the package right away. Having more sponsors of cppcheck is just great, since I think it requires at least few minutes/hours walking through hopefully unusual sources (think of the worst project you have ever seen, and cppcheck authors eventually never seen;-) before uploading. Although this release fixes a bug I reported and halfway 557045, both are low priority and I hesitate to judge they worth the risk upon release [1]. OTOH, to be honest I haven't seen cppcheck 1.42-1 (from unstable and testing) to choke on or to omit any blatant programming error, but perhaps I was just being lucky. I don't mind an upload, I'm just unsure of gain/risk ratio with 1.43. [1] http://lists.debian.org/debian-devel-announce/2010/05/msg0.html -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005102113.38468.danc...@spnet.net
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, Hi, http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.2-1.dsc Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: Only in pbuilder: CMake can't find FLTK
Hi, Gary Briggs writes: I've been spending the last few days packaging up my pet project. I finally submitted it to the mentors website last night, but I'm aware of one problem building it, that I'm hoping someone knows how to solve. In one sentence, like the subject says: When building in pbuilder, CMake can't find FLTK. It isn't a problem on any of the other systems I support; various ubuntu flavors. Debian lenny, squeeze or sid, either on metal or in VMs. Opensolaris. Arch Linux. OSX. MinGW/MSYS. I've run it on armv5, amd64, x86, sparc, ppc [not that architecture usually has any bearing on build systems, but still...] - somehow, it only occurs at the intersection of pbuilder and sid. I have a complete buildlog here: http://icculus.org/~chunky/stuff/buildlog.txt Note that cmake, libfltk1.1-dev, fluid, pkg-config are all pulled in. But down in the cmake run, I see this line: -- Could NOT find FLTK (missing: FLTK_INCLUDE_DIR) I found someone online who has what sounds like a similar problem: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/ b85232f8026ed347/dea38cd2422a846f?lnk=raotpli=1 I've used exactly that fix for past projects [setting FLTK_INCLUDE_DIR manually-ish], but that doesn't seem to fix it for me; neither when I put it in CMakeLists.txt [as they do], nor when I set it on the command-line [using dh_autoconfigure override, pass -DFLTK_INCLUDE_DIR=/usr/include to cmake]. My project's svn is here [the debian packaging is in trunk]: svn co svn://svn.icculus.org/obdgpslogger/trunk obdgpslogger-0.14 If anyone has any deep thoughts or otherwise general mentor-ish pearls of wisdom, I'm very open to suggestion I think your problem is related to bug #196003. You can temporary test it as you allow the compatibility symlinks to the header files (lowercase FL/*.h) dpkg-reconfigure -plow libfltk1.1-dev and answer 'yes'. if it succeeds, the ultimate solution would be to fix the cmakefiles of your project to look for capitalcase FL/*.H. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201005070811.13464.danc...@spnet.net
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, Hi, (excuse moi for the delay) It doesn't fix any Debian bugs, but it addresses an Ubuntu LP feature request and several upstream feature requests and bugs. http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.18.1-1.dsc Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: cppcheck, new upstream version 1.42
Reijo Tomperi writes: http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.42-1.dsc Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: cppcheck, new upstream version 1.41
Reijo Tomperi writes: http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.41-2.dsc The upload would fix these bugs: #566604 #567759 Uploaded. Your latest two changelog entries are both included. Thanks! -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: ncmpcpp (updated package)
Damien Leone writes: Hello, Hi, I am looking for a sponsor for the new version 0.5.2 of my package ncmpcpp [0] (currently uploaded version is 0.4.1). It builds this binary package: ncmpcpp - ncurses-based client for the Music Player Daemon (MPD) The package appears to be lintian clean. The upload would fix these bugs: 566162 [1], 553382 [2] The package can be found here: - URL: http://debian.fensalir.fr/ncmpcpp/ - dget http://debian.fensalir.fr/ncmpcpp/ncmpcpp_0.5.2-1.dsc Thanks, Regards, [0] http://unkart.ovh.org/ncmpcpp/ [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=566162 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553382 Looks good, some notes: * you didn't Close: #XX these bugs from debian/changelog. * you didn't pass --enable-visualizer flag to configure as suggested in 553382, though it is autodetected, but better stay on the safe side. * as caught by cppcheck [charset.cpp:103]: (error) Mismatching allocation and deallocation: tmp [charset.cpp:120]: (error) Mismatching allocation and deallocation: tmp i.e. whatever is allocated by strdup(3) should be released by free(3), and not by delete[], even if it works by pure luck (since delete op might be implemented by free with some implementations) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: ncmpcpp (updated package)
Damien Leone writes: Hello, First, thanks for your review. On 03 Mar - 20:11, George Danchev wrote: * you didn't Close: #XX these bugs from debian/changelog. It has been done in a previous package version (0.5-0.1) but my sponsor did not have the time to upload it. The provided package is for 0.5.2, the current debian version is 0.4.1, but my package includes versions 0.5.0 and 0.5.1 between (they have never been uploaded). * you didn't pass --enable-visualizer flag to configure as suggested in 553382, though it is autodetected, but better stay on the safe side. I don't understand, the rules file is not good? From the rules file: DEB_CONFIGURE_EXTRA_FLAGS := --enable-clock \ --enable-unicode \ --without-iconv \ --enable-outputs \ --enable-visualizer \ --with-curl \ --with-taglib Disregard these two, I actually overlooked. * as caught by cppcheck [charset.cpp:103]: (error) Mismatching allocation and deallocation: tmp [charset.cpp:120]: (error) Mismatching allocation and deallocation: tmp i.e. whatever is allocated by strdup(3) should be released by free(3), and not by delete[], even if it works by pure luck (since delete op might be implemented by free with some implementations) Ok, I will take a look a this. Good. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003032030.38593.danc...@spnet.net
Re: RFS: ncmpcpp (updated package)
Damien Leone writes: Hello, On 03 Mar - 20:11, George Danchev wrote: i.e. whatever is allocated by strdup(3) should be released by free(3), and not by delete[], even if it works by pure luck (since delete op might be implemented by free with some implementations) I included a patch to the package. It should be cppcheck clean now. Url: http://debian.fensalir.fr/ncmpcpp/ dget http://debian.fensalir.fr/ncmpcpp/ncmpcpp_0.5.2-1.dsc I will notify upstream about this. Okay, uploaded, thanks! P.S. I didn't forget to pass the proper -v so that the relevant entries get included in the *.changes file, and BTS magic to close these up for you. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: mbuffer (updated package)
Peter Pentchev writes: mbuffer (20091227-1) unstable; urgency=low This is also uploaded. Thank you. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: s5 (updated package)
Peter Pentchev writes: Dear mentors, Hi, s5 (1.1.dfsg.2-2) unstable; urgency=low Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201002252033.45293.danc...@spnet.net
Re: RFS: jansson (updated package)
Petri Lehtinen writes:
Dear mentors,
Hi,
I am looking for a sponsor for my package jansson.
* Package name: jansson
Version : 1.2-1
Upstream Author : Petri Lehtinen
* URL : http://www.digip.org/jansson/
* License : MIT
Section : devel
It builds these binary packages:
libjansson-doc - C library for working with JSON data - documentation
libjansson0 - C library for working with JSON data
libjansson0-dev - C library for working with JSON data - development files
The package appears to be lintian clean.
The upload would fix these bugs: 561051
Update: I shortened the package descriptions from the previous
version, as suggested by Ben Finney. Also, the previous RFS mail
wasn't as verbose as this one. See below.
My motivation for maintaining this package is: I am the upstream
author, and would like to see Jansson in Debian to make its users
happy! There are not many C libraries for JSON manipulation in Debian,
in fact I can only see libjson-glib, which depends on glib. Jansson
depends on no external libraries. Moreover, I think Jansson's API is
superior. This should be apparent as I wrote it! :)
There is also yajl which is in Debian proper and imo it is not that easy to
compete it, though I for one always bet on fair competition ;-)
This is my first attempted upload to Debian. I tried to follow the
policy manual and library packaging guide as well as possible, and I
also have discussed with some Ubuntu MOTUs about the package. I
decided to go for Debian instead of Ubuntu, as Debian is the ultimate
upstream for many distributions, not just Ubuntu.
My only real concern right now is that should the -dev package be
named libjansson0-dev (as the library packaging guide suggests) or
just libjansson-dev. In the (distant) future, there will be version
2.0 of the library, which is API incompatible, so that would justify
including the SONAME in the -dev package name. OTOH, I don't see many
packages use this convention. Does it only make things complicated?
Yes, this is doable, but this also makes things (unnecessarily) complicated.
Well maintained libraries provide stable API (public symbols never disappear,
only newly added ones appear over time), so I find it unnecessarily complicated
to upload a library package which is already *known* to change incompatibly in
the distant (or not so distant?) future, and then eventually handle a painful
library transition. Generally, well maintained libraries don't go that way, so
they don't need such complicated schemes like libpkgABI-API{-dev}. When your
library reaches (planned) API stability (that is what libraries are for by the
way;-), then it would make sense to encode SONAME only in the library package,
and leave the -dev one SONAME free.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: cppcheck, new upstream version 1.40
Reijo Tomperi writes: http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.40-1.dsc Uploaded. Thanks. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian + Home automation packages
Marc Leeman writes: Dear mentors, Hi, I'm looking for someone that would be interested in sponsoring a number of packages related to home automation: see: http://plugcomputer.org/plugforum/index.php?topic=824.0 Though it is described to run on armel; I've ran it on arm, mips, powerpc, i386 and amd64 too (etch, lenny, sid, openwrt and custom uclibc embedded systems). I have this particular system and configuration up and running for quite some months and since Marvell seems to actively push this application domain forward in their latest press release about the plug computer; I thought it'd be best to bite the bullet and get it in Debian. eibd-server and eibd-clients have been running for 2 years on Debian based systems. All but one ITPs are in place (pthsem). All this sound very nice, however: * Where are your source packages located? * Generally, your sponsor(s) would want to test the packages, however that would need certain home automation infrastructure to be in place which is not available everywhere, so you might need to suggest a way to simulate their operation if that is easily possible. I've been maintaining a number of debian packages for over 10 years now, mostly in combination with a dedicated sponsor. Please reply to me in Cc, since I am no longer subscribed to the list itself. Done. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian + Home automation packages
Eric Lavarde writes: Hello, George Danchev wrote: * Generally, your sponsor(s) would want to test the packages, however that would need certain home automation infrastructure to be in place which is not available everywhere, so you might need to suggest a way to simulate their operation if that is easily possible. I'm not a DD but I would tend to reduce the problem to a nice-to-have and not see it as a show-stopper: when I package a library, I'm pretty sure that my sponsors don't check that they work, but only that they compile properly and are in accordance with the Debian policy(ies). Well, that might really depends across the sponsors, however, here are some points to consider: * people usually sponsor stuff they are using one way or another (example: I for one do not sponsor java packages, since I don't use them) * in the case of libraries, chances are that there might be examples to check some basic functionality the library provides or writing a really short app just to call some functions shouldn't be that involving anyway. And it is fairly easy since the library package is actually provided and ready to install/remove/whatever (example: yajl, stx-btree) * chances are that your sponsor actually uses that library with their own packages and/or in their own software (same examples apply) Anyway, as maintainer, it's me receiving the bug reports, so I better make sure that it works ;-) http://www.debian.org/doc/developers-reference/beyond-pkging.html#sponsoring Sponsoring a package also means accepting responsibility for it, and there are no reasons to believe that sponsored packages should convey less responsibility than sponsor's own packages. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: need help with bug
Ury Stankevich writes: I would suggest removing the parallel support altogether, since this is only a smallish package and fighting the target dependencies will not bring too much of benefits. Agreed? Hello, can you check the fixed package ? - URL: http://mentors.debian.net/debian/pool/main/s/stx-btree - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/stx-btree/stx-btree_0.8.3-2.d sc Uploaded. Thank you! -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: need help with bug #564394
Ury Stankevich writes: Hi, Hi, i can't repeat this bug.. You can try with: DEB_BUILD_OPTIONS='parallel=4' dpkg-buildpackage ... and maybe you need to try that several times to reproduce. I suspect it can be caused by errors in debian/rules, since in current version of stx-btree i use `dh_prep` from both `install-arch` and `install-indep` targets, can they interfere on multicore box ? This is absolutely possible, yes. Maybe i should make some pre-install target and do all this stuff (dh_testdir dh_installdirs) from it ? I would suggest removing the parallel support altogether, since this is only a smallish package and fighting the target dependencies will not bring too much of benefits. Agreed? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: s5 (more DFSG free, refreshed Debian packaging)
Peter Pentchev writes: On Thu, Jan 07, 2010 at 06:18:07PM +0100, Cyril Brulebois wrote: Peter Pentchev r...@ringlet.net (07/01/2010): Dear mentors, Hi, I would be glad if someone uploaded this package for me. if nobody beats me to it, I could have a look tonight (UTC+1). IRC ping (KiBi) or private mail ping appreciated, I only read -mentors from time to time these days. Oops, sorry, I wasn't online at all last night, couldn't ping you :\ Thanks for expressing an interest though :) Uploaded. Thanks for your work. Neither I nor Cyril have further comments. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: procserv
Ralph Lange writes: Hi, On Sat 02 Jan 2010 3:42:49 George Danchev wrote: Good. There are some minor nuisances left, non of them critical, but I'd guess it would be kind of a shame to upload a simple package like that with these left in place: dh_testroot rmdir build rmdir: failed to remove `build': No such file or directory make: [cleanbuilddir] Error 1 (ignored) /usr/bin/make -C build -k distclean make: *** build: No such file or directory. Stop. make: [makefile-clean] Error 2 (ignored) ... and later: configure: creating ./config.status mv: cannot stat `Makefile.in': No such file or directory mv: cannot stat `Makefile.Automake.in': No such file or directory I didn't actually dig into them, but in my impression just using just debhelper + dh would be enough, e.g. simpler and sufficient, though I don't want to impose my personal view with these decisions. Issue found and fixed: CDBS starts doing semi-weird things if you set the build directory to something else that the default (current dir). Just leaving the default did the trick. One warning remains: the package build runs make distclean at the beginning, but in an autotools package the Makefile does not exist at that time. (Any subsequent builds don't show the warning.) I guess there's no way around that issue. oh, this is #441020 and it is well below your feet, indeed. You can still make your (and your sponsor's) life easier, but doing it the hard way is also an option ;-) To give you an impression: cdbs is like putting square tyres to a BMW, then you put it on your back and run with it, since there is no other way out... hint: eventually you may want to drop these tyres, since they are making you tired. Thanks for pointing me to Alioth. I created an account, hosted my packaging repo, and added matching Vcs-* fields to the control file. I also added a watch file pointing to the upstream download area on SF. New locations: - URL: http://mentors.debian.net/debian/pool/main/p/procserv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/procserv/procserv_2.5.0-5.dsc So ... do you think we're getting closer? ;-) I would be glad if someone uploaded this package for me. Uploaded. Thanks! -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: procserv
Ralph Lange writes: Hi, Hi, Turned out that a build-gone-wild had messed up my build directory and my cleanup was incomplete. Everything's nice when done in a clean environment: no Makefile, no .deps remain. I removed the .hg* stuff (inherited from upstream repo, it's actually not in the tarball). Good. There are some minor nuisances left, non of them critical, but I'd guess it would be kind of a shame to upload a simple package like that with these left in place: dh_testroot rmdir build rmdir: failed to remove `build': No such file or directory make: [cleanbuilddir] Error 1 (ignored) /usr/bin/make -C build -k distclean make: *** build: No such file or directory. Stop. make: [makefile-clean] Error 2 (ignored) ... and later: configure: creating ./config.status mv: cannot stat `Makefile.in': No such file or directory mv: cannot stat `Makefile.Automake.in': No such file or directory I didn't actually dig into them, but in my impression just using just debhelper + dh would be enough, e.g. simpler and sufficient, though I don't want to impose my personal view with these decisions. I will add the Vcs-* tags when the repo I'm doing the packaging in is publicly available. (Do you have a suggestion where to put it? I'm using darcs right now, but could switch.) I'd refrain from recommending which VCS to use, but in case you don't have a handy public place you can have a look at (for almost any kind of VCS): http://wiki.debian.org/Alioth/FAQ (item 4) I added Suggests: telnet. Okay. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
Tony Houghton writes: Dear mentors, Hi, I am looking for a sponsor for the new version 1.17.1-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.17.1-1.dsc I would be glad if someone uploaded this package for me. I decided to test the new option as mentioned in the changelog Added always_show_tabs option, however I got lost in how the user is supposed to change that option, since it is neither command line nor menu one. Sure, I can stop the app here and there (roxterm.c:2922, multitab.c:1953), but the control never reaches multitab.c:1958 for me. So, the question is: how to change that option from user POV, and what to expect, since multiple tabs are always shown to me even with the previous version? Thanks ;-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
Tony Houghton writes: On Sat, 2 Jan 2010 23:44:40 +0200 George Danchev danc...@spnet.net wrote: I decided to test the new option as mentioned in the changelog Added always_show_tabs option, however I got lost in how the user is supposed to change that option, since it is neither command line nor menu one. Sure, I can stop the app here and there (roxterm.c:2922, multitab.c:1953), but the control never reaches multitab.c:1958 for me. So, the question is: how to change that option from user POV, and what to expect, since multiple tabs are always shown to me even with the previous version? Thanks ;-) It's a profile option which can be set with the GUI (Edit Current Profile, in the Window/Tabs section). In previous versions the tab bar was only shown when a window contained more than one tab; now you can optionally show the tab bar even when there's only one terminal in a window. This solves a small problem when adding a tab to a maximised window https://sourceforge.net/tracker/?func=detailatid=698431aid=2921009group _id=124080 and also makes it easier to drag a lone terminal into another window. I knew I was missing something, and now I can see it working. Thanks for implementing and explaining it for me. Uploaded. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: procserv
Ralph Lange writes: Dear mentors, Hi, I am looking for a sponsor for my package procserv. * Package name: procserv Version : 2.5.0-3 Upstream Author : Ralph Lange ralph.la...@bessy.de * URL : http://sourceforge.net/projects/procserv/ * License : GPLv3 Section : utils It builds these binary packages: procserv - A process server with telnet console and log access The package appears to be lintian clean. My motivation for maintaining this package... procServ origins as a tool for the open source accelerator and physics control system software EPICS (http://www.aps.anl.gov/epics). In that context it is mainly used to run soft I/O controller processes in the background, while giving access to the console (stdin/stdout) of the process through a local telnet port. A ssh/screen combination was initially used to achieve this, but using the rich feature set of screen turned out to be sometimes crashing the child process. Also screen sends VT100 escape sequences, which clog up log files pretty much when used under a generic console access package. So procServ was created as a small, simple, stable, generic system-level tool to just run a command line process in the background and connect its stdin/stdout to a telnet port. Plus restarting the child (manually or automatically), PID file handling, blocking potentially dangerous input characters, etc. It does not implement multi-user modes, authorization, authentication etc - all this is left to the next layer console server, e.g. the conserver package. For security reasons, procServ restricts r/w connections to localhost. It optionally provides r/o access from outside (for central logging services). I think this tool is mature, simple, and useful enough to be in the distribution. I am willing to maintain it and keep it there. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/procserv - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/procserv/procserv_2.5.0-3.dsc I would be glad if someone uploaded this package for me. This looks good, perhaps except the capital 'S' in the middle of the application name and the man-page, but I can imagine they had their reasons and it has already been established that way for years. A couple of things you may want to address: - You should not touch the Makefile directly (since it could be re-generated), but patch the Makefile.in instead preferably via quilt, see wiki.debian.org. - Eventually you can give 3.0 (quilt) a try (i.e. it should be easier for you) http://wiki.debian.org/Projects/DebSrc3.0 - You want to get rid of .hg* in the tarball and .deps in the clean target - If you maintain your packaging in a version control system, you could also add Vcs-* fields as described in debian policy. - Binary package procserv could also Suggests: telnet -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: procserv
Ralph Lange writes: Hi, thanks for having a look. On Thu 31 Dec 2009 4:26:04 George Danchev wrote: This looks good, perhaps except the capital 'S' in the middle of the application name and the man-page, but I can imagine they had their reasons and it has already been established that way for years. Correct. I don't like the capital letter either, and was considering changing everything to all lowercase (as I am the current upstream author), but dropped the idea for exactly that reason. - You should not touch the Makefile directly (since it could be re-generated), but patch the Makefile.in instead preferably via quilt, see wiki.debian.org. Hm. I didn't touch the Makefile. The ...diff shows the complete Makefile, probably *because* it was generated. I thought this was normal, because I'm using plain cdbs automake rules, and this is what I get. What am I missing? Okay, I just piped the diff.gz to diffstat and the Makefile popped up there which is an indication for a trouble, regardless whether it is being added as new or simply modified. That should be enough to debian/rules: clean:: rm -f Makefile Please, have your time, we have better things to do these days ;-) Happy New Year to all. P.S. I'm subscribed to the list, so CC is not needed. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: yajl (updated package)
John Stamp writes:
Dear mentors,
I am looking for a sponsor for the new version 1.0.8-1
of my package yajl.
It builds these binary packages:
libyajl-dev - Yet Another JSON Library - development files
libyajl-doc - Yet Another JSON Library - library documentation
libyajl1 - Yet Another JSON Library
libyajl1-dbg - Yet Another JSON Library - debugging symbols
yajl-tools - Yet Another JSON Library - tools
The package appears to be lintian clean.
The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/y/yajl
- Source repository: deb-src http://mentors.debian.net/debian unstable main
contrib non-free - dget
http://mentors.debian.net/debian/pool/main/y/yajl/yajl_1.0.8-1.dsc
I would be glad if someone uploaded this package for me.
Uploaded. Thanks.
P.S. next time please add Depends: ${misc:Depends} to -dev and -doc binary
package sections, though its lack is currently harmless, but good to be there
just in case.
--
pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: poco (updated package)
Patrick Roland Gansterer writes: George Danchev: I also uploaded a new upstream version 1.3.6p1. Uploaded with the last two changelog entries of yours included. Can you please upload poco-doc too. Thanks! Sure, thanks for the poke. Uploaded with the following change: I moved your name/address from maintainer to uploaders for the same reasons as done with poco source package. P.S. I saw that you've added Vcs fields for poco, but not for poco-doc, when done for both I can pull from your VCS if you prefer it that way. P.S.2, I would also prefer one package upload poke in a separate RFS mail, in order not to overlook the second one once again... if that is not too much of hassle for you. P.S.3 If you are subscribed to -mentors list, I'd suggest we drop the CC. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to handle source code dependencies?
Matthias Klumpp writes: On Mon, 28 Dec 2009 15:21:10 -0300, Nicolas Alvarez nicolas.alva...@gmail.com wrote: Does Pascal have no notion of a shared library? It has, but the GLScene solution does not use it. Nope, that set of components would be in a separate shared library and the application would dynamically link to it *and* PulseAudio. Unless that library happens to be header-only (very rare in C, more common with C++ template libraries). Could be done in this way, but in the case of GLScene it is some kind of IDE plugin. It contains a set of classes, not only a header for a library. Also, the C ABI does not allow classes, so if the GLScene team would move all relevant parts to a shared library, they would need to create a flat API without direct use of objects. I'm not quite sure what a flat API means and whether you mean objects as instances and classes as types here, but if that could not be explored in the sense of separate compilation and further dynamic linkage, then it is not that helpful. I never used GLScene. GLScene integrates directly into the IDE, but it can also be used without it. I've seen a similar behavior in Java applications which included the whole code for a 3D engine directly into the application. ... which does not mean it is a very good idea to do so. I don't know what to suggest, but chances are you spend your time with that approach, and then you realize that no sponsor would upload it the way it is. Not any DFSG-compliant software worth packaging, in my opinion. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: poco (updated package)
Patrick Roland Gansterer writes: George Danchev: I'm still waiting for an answer to this: http://lists.debian.org/debian-mentors/2009/12/msg00300.html Do you think that a symbols file will be the correct solution? I didn't check the ABI history of poco, so i don't know if it is backward compatible and if this is a goal of upstream. Well, adding symbols files is meant to control what symbols appear and disappear with new releases. OTOH, apparently upstream bumps the soname, since they break the binary compatibility (at least) in the first place, so the question is why they break the it with their library effectively obliterating one of the contracts a well maintained production library should provided -- stable binary and programing interfaces (for instance we don't want libc doing so with each new release). Krzysztof, clamfs needs to be rebuilt (binNMU [1]) against the latest poco library, too, since it now depends on libpocofoundation8 and libpoconet8 which will automatically disappear from the archive (deemed as cruft [2]). [1] http://wiki.debian.org/binNMU [2] http://ftp-master.debian.org/cruft-report-daily.txt You are violating what is allowed in policy wrt Maintainer: field [1]. As a result, that confuses lintian believing your upload is meant to be NMU I corrected it. Is the original maintainer (CC'ed) aware of you being a co-maintainer? Yes, he is. Okay, thanks. I also uploaded a new upstream version 1.3.6p1. Uploaded with the last two changelog entries of yours included. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: poco (updated package)
Patrick Roland Gansterer writes: Dear mentors, Hi, I'm still waiting for an answer to this: http://lists.debian.org/debian-mentors/2009/12/msg00300.html I am looking for a sponsor for the new version 1.3.6-1 of package poco and poco-doc. It builds these binary packages: libpoco-dev - Development files for POCO - The C++ Portable Components libpococrypto9 - The C++ Portable Components Crypto library libpococrypto9-dbg - The C++ Portable Components Crypto library, debug version libpocodata9 - The C++ Portable Components Data library libpocodata9-dbg - The C++ Portable Components Data library, debug version libpocofoundation9 - The C++ Portable Components Foundation library libpocofoundation9-dbg - The C++ Portable Components Foundation library, debug version libpocomysql9 - The C++ Portable Components MySQL library libpocomysql9-dbg - The C++ Portable Components MySQL library, debug version libpoconet9 - The C++ Portable Components Network library libpoconet9-dbg - The C++ Portable Components Network library, debug version libpoconetssl9 - The C++ Portable Components Network library with SSL libpoconetssl9-dbg - The C++ Portable Components Network library with SSL, dbg version libpocoodbc9 - The C++ Portable Components ODBC library libpocoodbc9-dbg - The C++ Portable Components ODBC library, debug version libpocosqlite9 - The C++ Portable Components SQLite library libpocosqlite9-dbg - The C++ Portable Components SQLite library, debug version libpocoutil9 - The C++ Portable Components Util library libpocoutil9-dbg - The C++ Portable Components Util library, debug version libpocoxml9 - The C++ Portable Components XML library libpocoxml9-dbg - The C++ Portable Components XML library, debug version libpocozip9 - The C++ Portable Components Zip library libpocozip9-dbg - The C++ Portable Components Zip library, debug version The upload would fix these bugs: 545854, 548113, 560936 Thanks for taking care of these. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/poco - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.6-1.dsc I would be glad if someone uploaded this package for me. Sorry, it took some time to have a look at that. You are violating what is allowed in policy wrt Maintainer: field [1]. As a result, that confuses lintian believing your upload is meant to be NMU which is given an incorrect version. (Several) co-maintainer must be listed in Uploaders:, Maintainer's value is a `single item' filed. Is the original maintainer (CC'ed) aware of you being a co-maintainer? W: poco source: changelog-should-mention-nmu W: poco source: source-nmu-has-incorrect-version-number 1.3.6-1 [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f- Maintainer -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: poco (updated package)
Patrick Roland Gansterer writes: Dear mentors, Hi, (I'm the usual sponsor of poco and poco-doc, and I'm looking for co- sponsors;-) Some preliminary comments follow: I am looking for a sponsor for the new version 1.3.6-1 of package poco and poco-doc. It builds these binary packages: libpoco-dev - Development files for POCO - The C++ Portable Components libpococrypto9 - The C++ Portable Components Crypto library libpococrypto9-dbg - The C++ Portable Components Crypto library, debug version libpocodata9 - The C++ Portable Components Data library libpocodata9-dbg - The C++ Portable Components Data library, debug version libpocofoundation9 - The C++ Portable Components Foundation library libpocofoundation9-dbg - The C++ Portable Components Foundation library, debug version libpocomysql9 - The C++ Portable Components MySQL library libpocomysql9-dbg - The C++ Portable Components MySQL library, debug version libpoconet9 - The C++ Portable Components Network library libpoconet9-dbg - The C++ Portable Components Network library, debug version libpoconetssl9 - The C++ Portable Components Network library with SSL libpoconetssl9-dbg - The C++ Portable Components Network library with SSL, dbg version libpocoodbc9 - The C++ Portable Components ODBC library libpocoodbc9-dbg - The C++ Portable Components ODBC library, debug version libpocosqlite9 - The C++ Portable Components SQLite library libpocosqlite9-dbg - The C++ Portable Components SQLite library, debug version libpocoutil9 - The C++ Portable Components Util library libpocoutil9-dbg - The C++ Portable Components Util library, debug version libpocoxml9 - The C++ Portable Components XML library libpocoxml9-dbg - The C++ Portable Components XML library, debug version libpocozip9 - The C++ Portable Components Zip library libpocozip9-dbg - The C++ Portable Components Zip library, debug version The upload would fix these bugs: 545854, 548113, 560936 I'll have a look at these these days. However, clamfs package would require a rebuild, at least, so maintainer CC'ed (who is also a co-maintainer of poco). As a side note: poco is still breaking the binary compatibility with each new upstream release. I understand that while a library is still young and evolving that could be really needed sometimes to properly fix improper design decisions being made in the past. However, poco seems to be well established already, and I imagine it would follow the 'good library management' practices for instance as described in dpkg-gensymbols(1) under the section of 'Good library management'. Otherwise, we lose one of the key features of libraries, adherence to the interface contract it already published, which just makes the thing harder to reuse. Yes, I know boost is in the same boat, but at least they claim they are researching, and don't care too much for practical consequences which arise with distributing the product. So, the main question being: poco is going to perform good library management in the future, or they are going to be like boost camp? With poco we are lucky that we don't have so many packages to depends on it, however that might change in the future, and we certainly face a trouble with it. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/poco - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/poco/poco_1.3.6-1.dsc I would be glad if someone uploaded this package for me. I'll take care. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: dma (bugfixes, debconf, 3.0 (quilt))
Peter Pentchev writes: On Sat, Dec 12, 2009 at 04:56:45PM +0200, George Danchev wrote: Dear mentors, I am looking for a sponsor for the new version 0.0.2009.07.17-3 of my package dma, the DragonFly Mail Agent. This version fixes a couple of bugs, updates the debconf translations, and converts the package to the 3.0 (quilt) source format. [snip] I've uploaded a new package with the same version number, 0.0.2009.07.17-3; the mentors.d.n URL is the same, http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc The changes are: - the postinst script does an additional chown/chmod if necessary (see below) - the smarthost and dbounceprog are always taken from the debconf database, never from the (possibly modified by hand) dma.conf file; this fixes #544663, since there is no way to tell if the dma.conf contents are from a modification by hand or from an earlier debconf run with the default mail.example.com value! - the debian/config script mistakenly looked for defer instead of dbounceprog See below for more comments. * Really install the files in /etc/dma/ as root/mail/640. Closes: #544664 That only works for a newly installed dma package, and won't work for upgrading from older versions. My best bet on that would be a debconf question asking the user to perform the above actions on files at /etc/dma/. Well, actually, upon thinking about it a bit more, it turns out that a debconf question is never really needed. The dma executable binary is always installed setgid mail, so root/mail/640 for /etc/dma/* Should Be Enough For Everyone(tm) :) That is also true, and actually preferred way to go in that case. I've added a snippet to the postinst script, checking whether we're upgrading from an earlier version and doing the chown/chmod if so. IMHO, this should cover all cases. * Install the /usr/bin/mailq and /usr/bin/newaliases symlinks. Closes: #558421 * Switch to the 3.0 (quilt) source format. * Update the debconf translations: - add German. Closes: #552754 - add Japanese. Closes: #554515 - remove a double space and unfuzzy the translations. Closes: #552586 * Fix a crash when the SMTP server does not support STARTTLS. Closes: #547594 I had a look at 25-unsupported-starttls.patch, which looks good to me, however I was not able to test it, so I assume you have tested that as well. Yes, it's really easy to test - just point dma to any mailserver that does not recognize the STARTTLS command on port 25 :) But, yes, I've tested it and it seems to work. Yeah, time (check on the run;-) now upon upload, I tested with and without STARTTLS. By the way, IMO having so many patches in debian/patches (in fact much more than source files;-) looks like you are trying to develop there, nothing wrong with that, but it is not the most suitable place for that purpose. For instance, 9K 20-parse-recipient.patch is suitable for a new feature branch. IMO you either push that harder upstream [1], slow down pushing such feature patches with the package or fork the whole thing upstream and form a new project. Actually you have already diverged that enough to do the latter. IMO, debian/patches should be only for patches specific to Debian, feature explosions should be evolved upstream ;-) [1] though I don't see that rejected at (as written in the patch header): http://bugs.dragonflybsd.org/issue1321 Well, I wrote most of those patches because without them, dma either simply could not replace a local MTA (e.g. the sendmail -t mode tha many, many programs use to send e-mail messages in a really simple way), or did some really weird things (e.g. the seen patch that was later integrated and without which dma would list the same message several times when listing the queue with no indication whether it was needed or not). Most of the patches were accepted upstream, and some (like -t processing) were not explicitly rejected, but implemented in a different way in later versions. When I finish integrating a later snapshot of dma in my local repository, you'll see the next Debian upload with a lot less non-Debian-specific patches :) Okay, I'd really like that. Yes, I know debian/patches is not intended as a development repository, especially on a project with a very active and responsive upstream, as dma happens to be. I don't do this with other packages, but this particular case was special - in order to be an easily-usable MTA, dma needed a couple of nudges in the right direction, but definitely not enough to warrant a full-scale fork on my part. Good. My whole point was not to silently grow a thoroughly different/deviated dma while packaging it for Debian ;-) Thanks for taking a look at it and for the comments; and thanks in advance should you decide to also take a look at the new version :) Welcome. -- pub 4096R
Re: RFS: dma (bugfixes, debconf, 3.0 (quilt))
Dear mentors, Hello Peter, I am looking for a sponsor for the new version 0.0.2009.07.17-3 of my package dma, the DragonFly Mail Agent. This version fixes a couple of bugs, updates the debconf translations, and converts the package to the 3.0 (quilt) source format. It builds a single binary packages: dma- lightweight mail transport agent The package has been tested with lintian and pbuilder. The upload would fix these bugs: 544664 (file permissions), 547594 (fix a crash), 552586 (fix a debconf template), 552754 (debconf German translation), 554515 (debconf Japanese translation), and 558421 (install mailq and newaliases). The package can be found on mentors.debian.net: dget http://mentors.debian.net/debian/pool/main/d/dma/dma_0.0.2009.07.17-3.dsc I would be glad if someone uploaded this package for me. JFYI, here's the changelog entry: dma (0.0.2009.07.17-3) unstable; urgency=low * Really install the files in /etc/dma/ as root/mail/640. Closes: #544664 * Install the /usr/bin/mailq and /usr/bin/newaliases symlinks. Closes: #558421 * Switch to the 3.0 (quilt) source format. * Update the debconf translations: - add German. Closes: #552754 - add Japanese. Closes: #554515 - remove a double space and unfuzzy the translations. Closes: #552586 * Fix a crash when the SMTP server does not support STARTTLS. Closes: #547594 Sounds good, however I would certainly need some more time to have a decent look at the bug logs, and their resolution, which might happen during the weekend. It is not I don't trust you, on the contrary, I truly believe you need DM asap + Dm-Upload-Allowed=yes on all your packages (and start NM as well). And of course, if anyone else manage to review that before I can, well I'd be glad to see it ;-) -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: cppcheck, new upstream version 1.39
Reijo Tomperi wrote: http://mentors.debian.net/debian/pool/main/c/cppcheck/cppcheck_1.39-1.dsc The upload would fix these bugs: #554448 false positive resource leak Uploaded. Thank you. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Dear mentors, Hi, I am looking for a sponsor for the new version 1.16.3-1 of my package roxterm. The upload would fix these bugs: 559126 http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.3-1.dsc Uploaded. Thank you. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: shc
Dear mentors, Hi, I am looking for a sponsor for my package shc. * Package name: shc Version : 3.8.6-1 Upstream Author : Francisco Javier Rosales García fro...@fi.upm.es * URL : http://www.datsi.fi.upm.es/~frosal/ * License : GPL2 Section : utils It builds these binary packages: shc- a generic shell script compiler The package appears to be lintian clean. The upload would fix these bugs: 559134 My motivation for maintaining this package is: I ocasionally use it. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/shc - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/shc/shc_3.8.6-1.dsc I would be glad if someone uploaded this package for me. This package is not for us ;-) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=327263 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508109 -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
On Sat, 28 Nov 2009 09:53:09 +0200 --cut-- Adding autotools-dev back to build-dependencies fixes it, OK, I've added that dependency back. I've duploaded a replacement, but I haven't changed the version number because I think it's better not to when it hasn't been released yet. This is fine with me, this is now uploaded. Thank you. I also tried running autotools-dev's autogen.sh, but that resulted in a lintian report: P: roxterm source: direct-changes-in-diff-but-no-patch-system po/Makevars.template Because your diff.gz directly touches files outside debian/. I guess lintian does something like: lsdiff -z -x '*/debian/*' *.diff.gz so I thought I'd better avoid that for now. I'll replace my bootstrap.sh with it in future upstream versions though. Okay, however I wonder what were your considerations to remove it in the first place from there? I thought the autotools were supposed to generate self-contained tarballs. I must have got the wrong idea. They are self-contained unless config.sub and config.guess helper scripts got unexpectedly outdated. Rf: /usr/share/doc/autotools-dev/README.Debian.gz. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu signature.asc Description: This is a digitally signed message part.
Re: RFS: roxterm (updated package)
Dear mentors, Hi, I am looking for a sponsor for the new version 1.16.1-1 of my package roxterm. It builds these binary packages: roxterm- Multi-tabbed GTK/VTE terminal emulator The package appears to be lintian clean. The upload would fix these bugs: 557049 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.1-1.dsc I would be glad if someone uploaded this package for me. Package looks good and 557049 seems to be addressed as well, at least works for me;-). JFYI I just run into some leftovers in the roxterm(1) and roxterm- config(1) manpages -- they both contain [FIXME: manual] and [FIXME: source], and these are also shown in the man browser too. This is not a huge problem per se, and the package in sid also has it, but I think you might want to know about it and address it further. I use that package and I'm willing to upload. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: roxterm (updated package)
On Fri, 27 Nov 2009 21:39:25 +0200 George Danchev danc...@spnet.net wrote: Package looks good and 557049 seems to be addressed as well, at least works for me;-). JFYI I just run into some leftovers in the roxterm(1) and roxterm- config(1) manpages -- they both contain [FIXME: manual] and [FIXME: source], and these are also shown in the man browser too. This is not a huge problem per se, and the package in sid also has it, but I think you might want to know about it and address it further. I use that package and I'm willing to upload. Thanks. I've added the missing elements to the DocBook files the man pages are generated from, I hope they're OK now. This was an upstream change so I've uploaded a new version: - URL: http://mentors.debian.net/debian/pool/main/r/roxterm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_1.16.2-1.dsc Good. It turns out that yesterday I had installed autotools-dev by accident in my supposed to be clean chroot, so I failed to spot the following failure (and manage to complete the whole check cycle including install/deinstall/running). checking whether i486-linux-gnu-gcc and cc understand -c and -o together... yes configure: error: cannot run /bin/sh ./config.sub make: *** [config.status] Error 127 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Adding autotools-dev back to build-dependencies fixes it, however I wonder what were your considerations to remove it in the first place from there? -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
