Re: RFS: abiword (updated package)
The license of plugins/opendocument/common/xp/crypto/blowfish/ looks like it is the original BSD license with obnoxious advertising clause, which is incompatible with the GNU GPL IIRC. This is the blocker for uploading it. Please talk to upstream about that. http://www.gnu.org/licenses/license-list.html#OriginalBSD In addition it is an embedded code copy of part of OpenSSL, the security team does not like those. Are there any changes that need to be cherry-picked for squeeze? The memory leak fixes might be one. The version of libloudmouth required has been bumped, please add that to debian/control. Some of the copyright holder info has changed, best update debian/copyright. No need for the extra .0 in Standards-Version, 3.9.1.X versions are compatible. Please work with the Xubuntu maintainers to reduce the delta with Debian. Maybe you will get some co-maintainers out of it. Since abiword gets a lot of bug reports in Debian and Ubuntu, you might want to organise a bug triage session. I'd suggest involving the Xubuntu maintainers, Abiword upstream, and Debian GNOME/Xfce folks. You could also announce it on debian-devel and Planet Debian. Maybe you will get some co-maintainers out of it. You may want to move the git repo to collab-maint in case the above two things get you some co-maintainers. topgit seems to introduce some spurious changes to the patches that show up when I do debdiff to review the changes. Any way you can turn that off? If you haven't already, please attempt to get the Debian abiword patches, mine/desktop files and manual page accepted upstream. #526392 is long fixed, maybe you don't need the workaround in debian/rules. You may want to consider moving to debhelper 7 dh rules.tiny style debian/rules. You may want to switch from debian/patches/debian/rerun-automake.diff to dh-autoreconf. You may want to tag your patches with DEP-3 headers: http://dep.debian.net/deps/dep3/ When using dpkg-source v3 you do not need quilt in the build-depends. You may want to wrap the Build-Depends line since it is really long. I usually put one build-dep per line. Possibly the same for Depends/Recommends/etc. You can probably drop the defoma stuff since that is from 2003. Please check if all of debian/README.Debian still applies. The first paragraph of debian/README.source is not needed for dpkg-source v3 packages. configure warnings: configure: WARNING: unrecognized options: --disable-silent-rules, --enable-dynamic gcc warnings: ut_go_file.cpp:1645: warning: 'char* check_program(const char*)' defined but not used ut_jpeg.cpp: In function 'bool UT_JPEG_getRGBData(const UT_ByteBuf*, UT_Byte*, UT_sint32, bool, bool)': ut_jpeg.cpp:197: warning: unused variable 'buffer' xap_UnixApp.cpp: In constructor 'XAP_UnixApp::XAP_UnixApp(const char*)': xap_UnixApp.cpp:81: warning: unused variable 'fc_inited' fl_SectionLayout.cpp: In member function 'void fl_HdrFtrSectionLayout::addPage(fp_Page*)': fl_SectionLayout.cpp:3595: warning: suggest braces around empty body in an 'else' statement fp_Line.cpp: In member function 'bool fp_Line::findNextTabStop(UT_sint32, UT_sint32, eTabType, eTabLeader)': fp_Line.cpp:2922: warning: unused variable 'bRes' fp_Line.cpp: In member function 'bool fp_Line::findPrevTabStop(UT_sint32, UT_sint32, eTabType, eTabLeader)': fp_Line.cpp:2951: warning: unused variable 'bRes' fp_Line.cpp: In member function 'void fp_Line::addDirectionUsed(UT_BidiCharType, bool)': fp_Line.cpp:3811: warning: comparison between signed and unsigned integer expressions fp_Line.cpp: In member function 'void fp_Line::removeDirectionUsed(UT_BidiCharType, bool)': fp_Line.cpp:3831: warning: comparison between signed and unsigned integer expressions fp_Line.cpp: In member function 'void fp_Line::changeDirectionUsed(UT_BidiCharType, UT_BidiCharType, bool)': fp_Line.cpp:3866: warning: comparison between signed and unsigned integer expressions fp_Run.cpp: In member function 'void fp_Run::setBlockOffset(UT_uint32)': fp_Run.cpp:998: warning: unused variable 'iOff' fv_View_cmd.cpp:5637: warning: unused parameter 'pos' fv_View_protected.cpp: In member function 'UT_Error FV_View::_deleteBookmark(const char*, bool, PT_DocPosition*, PT_DocPosition*)': fv_View_protected.cpp:5672: warning: suggest braces around empty body in an 'else' statement pt_PT_DeleteSpan.cpp: In member function 'bool pt_PieceTable::_deleteComplexSpan(PT_DocPosition, PT_DocPosition, UT_Stack*)': pt_PT_DeleteSpan.cpp:1267: warning: comparison of unsigned expression = 0 is always true pt_PT_DeleteStrux.cpp: In member function 'void pt_PieceTable::_deleteHdrFtrStruxWithNotify(pf_Frag_Strux*)': pt_PT_DeleteStrux.cpp:663: warning: unused variable 'HdrFtrPos' abiwidget.cpp:1042: warning: unused parameter 'pTimer' ap_UnixDialog_Lists.cpp:154: warning: unused parameter 'widget' ap_UnixDialog_Lists.cpp: In member function 'virtual void AP_UnixDialog_Lists::runModal(XAP_Frame*)': ap_UnixDialog_Lists.cpp:198: warning: unused variable 'unixapp'
RFS: visolate
Dear mentors, I am looking for a sponsor for my package visolate. * Package name: visolate Version : 2.1.6~svn8-1 Upstream Author : Marcus Wolschon * URL : https://sourceforge.net/projects/visolate/ * License : GPL Section : x11 It builds one binary package: visolate - tool for engraving PCBs using CNCs The package appears to be lintian clean except for wishlist and pedantic. I am motivated to maintain the package as I use it myself. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/v/visolate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/v/visolate/visolate_2.1.6~svn8-1.dsc I would be glad if someone reviewed the java packaging (it's my first java package) and, if appropriate, uploaded this package for me. Please keep me in CC when replying as I'm not subscribed to mentors. Kind regards chrysn -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom signature.asc Description: Digital signature
Time of a package to be processed by FTP-masters
Hello, I don't know if the question is very appropriate in this list, but since it will be useful for new maintainers whose packages are uploaded to the archives, I figured out that it might be appropriate. If not, please point me to the correct place to ask. The matter is that I got a new version of an existing package compiled and uploaded by a sponsor (I'm just DM so I can't directly upload my stuff), and the package is stuck in the new queue of the ftp masters machine for two weeks. I realize that there are a lot of packages to be processed, some in the queue older than mine, but most of those have several versions uploaded which indicate that maybe they have packaging problems, and many packages newer than mine were already processed in this time lapse. The previous packages that I had created and needed to go in the new queue were processed within a couple of days. So I am wondering whether my package has a specific problem (though I was not contacted by ftp masters in any way), or it's just a matter of time before it gets processed (e.g. they are busy with updates related with the freeze), or what. What I would want to know, in particular: 1- If this is normal, or if having to wait for 1 week indicates that the package has some kind of problem. 2- In the latter case, do FTP contact you (even by receiving some kind of REJECT notification), or are you supposed to ask them what's the problem after some time? 2.1- If so, what's would be the time appropriate to ask? 1 month for example? 2.2- What would be the correct way to contact them -- some email emailing list or a bug report to the pseudo-package? I'd gladly accept any other suggestion to try to find out why my package takes so long to be processed. Thanks and cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- 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/201010271550.17221.manuel.montez...@gmail.com
Re: Time of a package to be processed by FTP-masters
On Wed, Oct 27, 2010 at 9:50 PM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: 1- If this is normal, or if having to wait for 1 week indicates that the package has some kind of problem. It is normal, especially during the freeze. The oldest package in new has been waiting 11 months. 2- In the latter case, do FTP contact you (even by receiving some kind of REJECT notification), or are you supposed to ask them what's the problem after some time? Yes, you'll either get a request for clarification or a REJECT. No need to contact them until that happens. 2.1- If so, what's would be the time appropriate to ask? 1 month for example? Maybe after squeeze is released and they've processed the backlog. Outside of a freeze maybe 2 months. 2.2- What would be the correct way to contact them -- some email emailing list or a bug report to the pseudo-package? http://www.debian.org/intro/organization -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikshdthblzfccvzyiepc=whx-xve86jg+tkb...@mail.gmail.com
Re: Time of a package to be processed by FTP-masters
Dear Manuel, accumulation of packages in the NEW queue is not uncommon, see: http://people.debian.org/~corsac/ Although a modest help, you may try to review some packages by yourself when a public copy is available, for instance on mendors.d.n or a VCS. The maintainers will probalby have enough time to upload a corrected update (this does not move the package back in the queue), hence saving some time from the people who will do the final inspection, and shortening the waiting time for your own package. On the following wiki page, here is a workflow that I have proposed some time ago. The goal is to trigger an chain reaction of package reviews: http://wiki.debian.org/CopyrightReview Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101027140419.ga2...@merveille.plessy.net
Re: Time of a package to be processed by FTP-masters
Hi! /me takes his ftp-assistant hat on. Am 27.10.2010 15:50, schrieb Manuel A. Fernandez Montecelo: So I am wondering whether my package has a specific problem (though I was not contacted by ftp masters in any way), [..] If you have a working e-mail address, we'll contact you, if there is a problem ;) or it's just a matter of time before it gets processed (e.g. they are busy with updates related with the freeze), or what. Part of us busy preparing the archive software for the release, yes. An other part of us is working on other improvements of said software, but mostly NEW processing isn't top priority during a freeze, as these packages won't end up in the release anyway (and some of them might even hinder the release), so we currently mostly process NEW packages fixing RC bugs or upon request of release mangagers / d-i developers / kernel developers or packages ending up in experimental anyway. What I would want to know, in particular: 1- If this is normal, or if having to wait for 1 week indicates that the package has some kind of problem. In general: No. Even if there isn't a freeze, packages might need to wait longer than a week on NEW before getting processed. 2- In the latter case, do FTP contact you (even by receiving some kind of REJECT notification), or are you supposed to ask them what's the problem after some time? You'll get a mail if your package get's rejected, or if we see a problem which needs to be addressed / clarified before it can be accepted. 2.1- If so, what's would be the time appropriate to ask? 1 month for example? 1 Month sounds reasonable to me under normal circumstances. 2.2- What would be the correct way to contact them -- some email emailing list or a bug report to the pseudo-package? Per e-mail or via irc in #debian-ftp on irc.debian.org. Best regards, Alexander -- 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/4cc83626.2040...@debian.org
suscribe
-- 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/29152258.36285.1288188738124.javamail@wwinf1j34
Re: Time of a package to be processed by FTP-masters
Hi Dne Wed, 27 Oct 2010 15:50:16 +0200 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com napsal(a): The matter is that I got a new version of an existing package compiled and uploaded by a sponsor (I'm just DM so I can't directly upload my stuff), and the package is stuck in the new queue of the ftp masters machine for two weeks. I realize that there are a lot of packages to be processed, some in the queue older than mine, but most of those have several versions uploaded which indicate that maybe they have packaging problems, and many packages newer than mine were already processed in this time lapse. The previous packages that I had created and needed to go in the new queue were processed within a couple of days. I guess the problem is that people are now more focused on getting release out than on adding more packages. So for now try to help with that as well, find some RC bug and fix it. Once the release is out, your packages in NEW will get processed faster :-). 1- If this is normal, or if having to wait for 1 week indicates that the package has some kind of problem. AFAIR the wait time was most time much above 1 week, it only got improved in last year. Actually see yourself how the size of NEW queue changes: http://molly.corsac.net/~corsac/debian/new/ 2- In the latter case, do FTP contact you (even by receiving some kind of REJECT notification), or are you supposed to ask them what's the problem after some time? You get a REJECT notification or even just a question to clarify some things. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
RFS: mediadownloader
Dear mentors, I am looking for a sponsor for my package mediadownloader. * Package name: mediadownloader Version : 1.4.2-1 Upstream Author : Marco Bavagnoli lil.dei...@gmail.com * URL : http://mediadownloader.cz.cc * License : GPL3 Section : graphics It builds these binary packages: mediadownloader - Search, preview, download with Google Image and YouTube The package appears to be lintian clean. My motivation for maintaining this package is: the annoyance to search images with Google, browse into the web page, see the image if its worth a download, pointed me to start to develop this application that can do a preview of original images and also download all at once with a nice GUI. In the meantime, I also added searches with youTube and some other features. I find this is useful application, I still use it for job, maybe could be the same for others. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mediadownloader - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mediadownloader/mediadownloader_1.4.2-1.dsc I would be glad if someone uploaded this package for me. Kind regards Marco Bavagnoli -- 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/4cc870a5.4070...@gmail.com
Re: Time of a package to be processed by FTP-masters
Hi again, Thanks all for your informative and quick replies. You've covered all bases so I don't have any questions left, just one comment: On Wednesday 27 October 2010 16:04:19 Charles Plessy wrote: Although a modest help, you may try to review some packages by yourself when a public copy is available, for instance on mendors.d.n or a VCS. The maintainers will probalby have enough time to upload a corrected update (this does not move the package back in the queue), hence saving some time from the people who will do the final inspection, and shortening the waiting time for your own package. On the following wiki page, here is a workflow that I have proposed some time ago. The goal is to trigger an chain reaction of package reviews: http://wiki.debian.org/CopyrightReview Have a nice day, I've been hanging around in this list for a while, I think that I only reviewed a package once (and replied to one question from your about the correct way to test man pages :) ). But most of the time it's because the mails posted are RFS, I don't have powers to upload them, and the developer uploading them possess much more knowledge than me about packaging questions, specially the tricky ones. I'm trying to help Debian in general by adopting packages that are in my field of interest and are effectively abandoned by their maintainers -- so I update the upstream code (sometimes the package in debian is more than 3 years old), talk with upstream to solve issues and incorporate patches, quell lintian complaints, put new package formats and things like missing watch files, close a few bug reports, etc. And then I poke Ubuntu folks to update from Debian. So I've never added new packages to the repository despite what my initial mail could suggest, I'm in fact adopting packages long abandoned, but which need to enter the new queue for a variety of reasons (e.g. the package being named according to a SONAME version). The point being: adopting all the packages that I [co]maintain is already a quite comprehensive, careful and tiresome revision ;) The copyright peer-review sounds like an useful thing to do, though -- I'll look into it when I have some time available. Cheers, and thanks again! -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- 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/201010272325.25454.manuel.montez...@gmail.com
Re: roxterm resizing bug serious enough for freeze exception?
Hi, On Tue, Oct 26, 2010 at 08:54:06PM +0100, Tony Houghton wrote: With some window managers and/or when closing many roxterm tabs rapidly with keyboard auto-repeat, closing tabs may cause the window to shrink, reducing the number of columns and/or rows in the remaining tabs' terminals (see https://sourceforge.net/tracker/index.php?func=detailaid=3089323group_id=124080atid=698428 and https://bugs.launchpad.net/ubuntu/+source/roxterm/+bug/665730. Would this bug be considered serious enough to ask for another freeze exception? It doesn't sound so, unless the patch (any existing patch today?) is small / not invasive. You should read the current freeze status: http://lists.debian.org/debian-devel-announce/2010/10/msg2.html -- Simon Paillard -- 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/20101027220032.ge2...@glenfiddich.ikibiki.org
Re: Time of a package to be processed by FTP-masters
On Thu, Oct 28, 2010 at 5:25 AM, Manuel A. Fernandez Montecelo manuel.montez...@gmail.com wrote: I've been hanging around in this list for a while, I think that I only reviewed a package once (and replied to one question from your about the correct way to test man pages :) ). But most of the time it's because the mails posted are RFS, I don't have powers to upload them, and the developer uploading them possess much more knowledge than me about packaging questions, specially the tricky ones. Reviewing other folks packages is a good way to gain skills and reduce the amount of time developers need to spend on reviewing them before upload. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimdcwtx-slf+bac�ixxzwtrunkhu-2sphf...@mail.gmail.com
Re: Using quilt for Jarifa
Hi, El mié, 27-10-2010 a las 16:02 +0200, Daniel Lombraña González escribió: I do not an answer in a few days, so I was wondering where I should ask for help in this matter. Thanks a lot :) Daniel: I'm unable to help you but maybe in the mentors list someone give you a proper advice about this ;-) I'm wondering when I should use quilt and git-buildpackage to modify at least as possible the upstream version of Jarifa files. Let me explain. Jarifa has a SQL file that by default creates the DB in MySQL. Nevertheless, in the deb package this is managed by dbconfig-common, so I have to remove the instruction of creating the DB in the SQL file. Right now I have done this, by creating a new git repository and modify the source code by hand. After that, I kept reading about git-buildpackage and it seems that it should be more easy to maintain those differences between the upstream version and the deb one using patches. However, I don't know how I have to do this, as I have been trying it out, and as far as I have get is to create the debian/patches folder (using gbp-pq) with a patch that removes that instruction. However, when building the package using git-buildpackage in the master branch (not in patch-queue/master) the resulting package does not have applied the patch, which is wrong. Is it possible to apply automatically those patches when building the package? (FYI I have tried the 3.0 version, and I don't get it working either, probably because I'm doing something wrong). Regards, -- Fernando C. Estrada -- 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/1288235722.2641.6.ca...@erinn.soapros.com
