Re: More C++ help needed (Was: Bug#811866: fixed in hyphy 2.2.6+dfsg-4)
nge: _Formula f (*thisString,nil,false); to: _Formula f (*thisString,nil,nil); (or the more standard "nullptr", but since they already use 'nil', which I guess that it's an alias... I don't want to break their style). /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:87:5: note: no known conversion for argument 3 from 'bool' to '_String*' /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate: _Formula::_Formula() _Formula (void); ^~~~ /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:86:5: note: candidate expects 0 arguments, 3 provided /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate: _Formula::_Formula(const _Formula&) class _Formula // a computational formula ^~~~ /build/hyphy-2.2.6+dfsg/src/core/include/formula.h:79:9: note: candidate expects 1 argument, 3 provided /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp: In member function 'virtual void _HYDistributionChartWindow::AddVariable(_String*)': /build/hyphy-2.2.6+dfsg/src/gui/HYChartWindow.cpp:4530:45: error: no matching function for call to '_Formula::_Formula(_String&, NULL, bool)' These don't seem a good candidate in this case. In any event, it's probably upstream who should take a look at this, because changing the code without knowing exactly what it does is never a good idea :-) Hope that helps! -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Bug#683840: RFS: razorqt/0.4.1-1~exp1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package razorqt. I am a DM and I already take care of a few widely used packages, I intend to keep this one in good shape as well. Initially I decided to put this one into experimental, since it's not very stable upstream and there are new versions coming soon. Related RFP/ITP bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652745 Package name: razorqt Version: 0.4.1-1~exp1 Upstream Author: Razor-qt team URL: http://razor-qt.org/ License: LGPL2.1+ Section: x11 It builds those binary packages: libqtxdg0 - Implementation of the XDG Specifications for Qt, libs libqtxdg0-dev - Implementation of the XDG Specifications for Qt, development pack librazorqt0 - Shared libraries for Razor-qt desktop environment librazorqt0-dev - Shared libraries for Razor-qt desktop environment, development pa razorqt- Lightweight desktop environment, all components razorqt-appswitcher - Application switcher component for Razor-qt desktop environment razorqt-config - Configuration component for Razor-qt desktop environment razorqt-data - Shared data files for Razor-qt desktop environment razorqt-desktop - Desktop component for Razor-qt desktop environment razorqt-panel - Panel component for Razor-qt desktop environment razorqt-policykit-agent - PolicyKit agent component for Razor-qt desktop environment razorqt-power - Power manager component for Razor-qt desktop environment razorqt-runner - Application launcher component for Razor-qt desktop environment razorqt-session - Session manager component for Razor-qt desktop environment To access further information about this package, please visit the following URL: http://mentors.debian.net/package/razorqt Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/razorqt/razorqt_0.4.1-1~exp1.dsc There is a lintian warning related with shared libraries file, I don't know if it causes harm but the package should work all right. I would appreciate if somebody advises on how to get rid of it, never experienced it before, and it's happening only in one of the binary packages when in fact the structure for most of them is the same. 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/CAPQ4b8=p-DHKMkoL=c+wosa3gyseoweuypbrhsk1mddd5ny...@mail.gmail.com
Bug#683840: RFS: razorqt/0.4.1-1~exp1 [ITP]
Hi Bart, 2012/8/4 Bart Martens ba...@debian.org: Hi Manuel, The package name is razor-qt on the ITP and razorqt on the RFS and at mentors. Why the difference ? Initially I was using razor-qt, then tried to follow upstream's recent names in Ubuntu's PPA: https://launchpad.net/~razor-qt/+archive/ppa/ I don't know why they decided to change, though. There are some advantages in not having the dash and those making razorqt a unit, for example, that it doesn't look like Qt's interface for package Razor, or that it helps to shorten package names in general (eg razorqt-policykit-agent instead of razor-qt-policykit-agent). But in short, there's no strong reason. 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/CAPQ4b8k91sT+jWTDpBB=60omdhc+wuftnyu_1twnewoq5o+...@mail.gmail.com
Re: RFS: tupi -- 2D Animation design and authoring tool
Hi, Including debian-mentors@ so other people can chime in -- I thought that I already did in my initial reply, sorry. 2011/12/29 Dmitry Smirnov only...@member.fsf.org: 1) README.source in debian/ is unnecessary, I think Sorry, I'm not sure what do you mean - where did you find README.source ??? In tupi package I don't have it... Actually, I unpacked orig.tar.gz and then yours on top, without realising that upstream already has a debian/ dir. So, forget about this one. 2) If you want hardening flags, you can depend on debhelper = 8.9.0~ and use compat=9. debian/make.mk is unnecessary, IMO You're right, but I'm not too confident using compat=9 until it will be stabilized. I like include for the explicit reference to variables initialization. I think such things are better left visible. About hardening flags it's OK, it was just a suggestion. But I don't understand how debian/make.mk is used if it's not included. 3) In control file, the long description should be much longer and explain what actually does Yes, true. The problem is that I'm not familiar enough with tupi to write long description. I can't borrow description from ktoon package because I'm not sure how well its description applies to tupi. In regards to long description I found nothing useful neither on tupi web site nor in embedded help... :( Any ideas? Well, you can tell upstream that their provided information is not very clear. But I found this, which contains a bit more information: http://www.maefloresta.com/portal/about A mix of some of the points in Tupi is plus the features section below would be fine, I think. In any case, I advise you to communicate with upstream when you encounter problems like these and you have to make some decisions. In my experience they're usually happy to help to get their packages in Debian (and... beyond -- all the derivatives), and will help you to avoid ugly things like the chmods in rules in future releases. 4) You can use Breaks/Replaces on ktoon if you really want to show that it provides a replacement for ktoon Thanks for advice, I'll do that. [ left this bit so debian-mentors@ folk can correct me if appropriate ] 5) I think that debian/postinst, just calling ldconfig, is also unnecessary No, it's calling 'update-menus' only. I avoid ldconfig by override_dh_makeshlibs: dh_makeshlibs --noscripts Again, this is something from upstream's debian/. You don't have the debian/postinst file, so my comment is irrelevant. 6) Not completely sure, but I think that you can get rid of this conversion and use the .png in the menu/.desktop files convert launcher/icons/tupi_32x32.png $(PDIR)/usr/share/pixmaps/tupi_32x32.xpm I already tried it but lintian didn't like that - see menu-icon-not-in-xpm- format http://lintian.debian.org/tags/menu-icon-not-in-xpm-format.html Ahm, I am not sure if this bit (or the Debian menu thing altogether) is a bit obsoleted with Freedesktop XDG guidelines? Otherwise you're correct. Btw, the debian/desktop linking to a .desktop file contains this path, which if unmodified it's incorrect: /usr/local/tupi/bin/tupi 7) I am not sure that the magic things that you do with shlibs are the best way to do it -- just a hint for other reviewers more knowledgeable than me :) I'm not sure how to do it better. CMAKE is not very nice and alternative way could be patching upstream CMAKE files to build libraries in intended directories, in which case implications will be the difficulties with future maintenance. So I'm merely moving libraries where they belong after build phase - it appears to be easy enough. Does the project use CMake at all? I think that you can for example use --libdir=/usr/lib/ in debian/rules (I think that there's no need for this PDIR), removing the /tupi/ end from there would allow you to not have to move things later. Anyway, *again* I was refering to debian/shlibs file in upstream's debian/, not yours :o) Other than that, it looks like an interesting piece of software, I hope that it gets into Debian. Thanks for your effort! Thank you so much for your review. I hope you found tupi useful. I hope it'll find its way to Debian eventually, but sponsors are so hard to find... I wish you all the best for the new year. BTW, I think that I already told you that I'm not a Developer, just a poor Maintainer, so I cannot sponsor packages. But hopefully this review will help you to get closer to uploading the package to Debian. Thanks for your efforts and happy celebrations for you too! -- 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/CAPQ4b8=pz2jw9+htgcqmuacjmfr2pdhetvotwoznzdxm60i...@mail.gmail.com
Re: RFS: libqglviewer
On Tuesday 13 Dec 2011 23:18:13 Artur R. Czechowski wrote: Hello, I am looking for a sponsor for my package libqglviewer. I'm not a Debian Developer so I cannot sponsor, but this is a review with comments and considerations. I will appreciate if people more knowledgable than me confirm or rebut my comments. Items in no particular order, just to separate topics. 1) Name of author in *.README.Debian files contain dot: This package contains QGLViewer made by Gilles.Debune available at: 2) Actually the 3 *.README.Debian contain the same text... would not be better to have just README.Debian that would be shipped with all binary packages? (Or it doesn't work in this way, as other files in debian/ do?) 3) There's version 3 available for watch files, maybe it's good to update it? (I never used version=2 so I am not aware of advantages/disadvantages) 4) Copyright could use DEP-5 format. Anyway, I think that it would be at least good to mention the GPL_EXCEPTION file in the source, with Additional rights granted beyond the GPL (the Exception). Maybe it would even be necessary to mention the double-license (GPLv2 and commercial), copying the whole header of LICENSES file to copyright. 5) debhelper compat 7 is a bit outdated I think. Maybe it's not still deprecated, but debian/rules would be greatly simplified. Conversion to compat 9 and multi-arch is probably required before next stable release, although it's understandable if you want to do this in small steps (I usually do this with my packages). 6) I think that Policy Standards Version 3.9.2 that you updated actually requires that you convert Conflicts to Breaks/Replaces in your control file, at least for the case of your package (see 7.4 Conflicting binary packages - Conflicts): http://www.debian.org/doc/debian-policy/ch-relationships.html This lintian warning is related to the same: http://lintian.debian.org/tags/conflicts-with-version.html Hope that it's useful! Cheers. -- 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/201112292329.48332.manuel.montez...@gmail.com
Re: berlios closing; where should my projects escape to?
Sending the reply to the list too, maybe there are other people interested and nobody mentioned it yet... 2011/10/18 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com: 2011/10/18 Paul Elliott pelli...@blackpatchpanel.com: On Tuesday, October 18, 2011 01:22:15 AM Paul McEnery wrote: On 18 October 2011 06:02, Paul Elliott pelli...@blackpatchpanel.com wrote: [...] Any suggestions? GitHub? I use them for my package repos, and I see that MythTV recently (in the last few months) switched to them. Not sure about the full project experience, I.e. mailing lists, website etc, but they do appear to have these features, although I've not used it to that extent. Paul. I don't want to learn GIT right now. Is there someplace I could stay with svn? http://gna.org/ -- the source from when savannah-gnu comes from. I've been happily using it for years for not-very-demanding projects, haven't been using it in the last couple of years. It seems to me that they don't have much working-force behind the scenes. Cheers. -- 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/capq4b8k7qayzgszbbfanfa84dret68pss27yqx1mkt--wz4...@mail.gmail.com
Fwd: openscenegraph_2.9.11-1_amd64.changes REJECTED
Hello, I have a question regarding the attached e-mail, which I think it's appropriate to ask here. I got this email because it's a new package, or what? This is about the package OpenSceneGraph and I have DMUA permission: http://packages.qa.debian.org/o/openscenegraph.html The binary files that I tried to upload are: libopenscenegraph71_2.9.11-1_amd64.deb libopenscenegraph-dev_2.9.11-1_amd64.deb libopenthreads14_2.9.11-1_amd64.deb libopenthreads-dev_2.9.11-1_amd64.deb openscenegraph_2.9.11-1_amd64.deb openscenegraph-doc_2.9.11-1_all.deb openscenegraph-examples_2.9.11-1_all.deb However I get the REJECTion only on a couple of them -- maybe because their binary package name is different, while the name of the rest of the packages is the same as in past versions? Thanks in advance for any reply which might help me to understand the problem. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com ---BeginMessage--- Reject Reasons: manuel.montez...@gmail.com may not upload NEW file libopenthreads14_2.9.11-1_amd64.deb manuel.montez...@gmail.com may not upload NEW file libopenscenegraph71_2.9.11-1_amd64.deb === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. ---End Message---
Re: Review of pev
On Wednesday 12 January 2011 23:55:52 Fernando Mercês wrote: Good to read it, Manuel. Thank you. By the way -- I don't know if I had said it before, but anyway: I am not a Debian Developer (just maintainer) so I can't upload your package. Somebody else has to do the actual sponsoring, but after the reviews hopefully it's now a trivial matter. Cheers. PS: Parabéns pelo seu primeiro pacote! -- Congratulations for your first package! ;) Att, @Fernando Mercês http://twitter.com/FernandoMerces Linux Registered User #432779 www.mentebinaria.com.br http://linuxreversing.org http://softwarelivre-rj.org - - Participe do I Hack'n Rio http://hacknrio.org/, dias 8 e 9 de abril na UFRJ! - - 2011/1/12 Manuel A. Fernandez Montecelo manuel.montez...@gmail.com Hello, On Wednesday 12 January 2011 17:07:15 Fernando Mercês wrote: Thanks, friends, for all comments and tips. I've just updated my package on mentors including all modifications suggested. I would appreciate if you can take a look at my package now. I think that it is more than ready now :) Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com -- 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/201101131031.21640.manuel.montez...@gmail.com
Re: Review of pev
Hello, On Wednesday 12 January 2011 17:07:15 Fernando Mercês wrote: Thanks, friends, for all comments and tips. I've just updated my package on mentors including all modifications suggested. I would appreciate if you can take a look at my package now. I think that it is more than ready now :) 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/201101121737.35684.manuel.montez...@gmail.com
Re: Review of pev
Hello Fernando, First of all I am no mentor, just a regular package, and don't have years of experience with this, but I'll review your package anyway. Hopefully something else gets interested and helps to review it, too. On Tuesday 11 January 2011 08:00:39 Fernando Mercês wrote: Hello, mentors. I would appreciate if you can look at my package and tell me if is something wrong. Will be my first package. The package name is pev and the tarball can be downloaded on http://www.mentebinaria.com.br/coding40/pev_0.22-1.tar.gz Thanks. The contents of the debian/ directory look more or less fine, save for the following details: - The files files and pev.debhelper.log which, as far as I known, are unnecessary. - The changelog should contain the name of a distribution -- unstable by default. But what you should really get done for future versions/revisions is to present to this mailing list the source and maybe binary packages (as built by debuild). Cheers, and congratulations for your first package :) -- 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/20110309.45028.manuel.montez...@gmail.com
Re: Review of pev
Hello again, On Tuesday 11 January 2011 22:50:45 Fernando Mercês wrote: Scott, thank you. It's very clear for me now. I have just uploaded my package. I don't know where you get the instructions, but I think that you got some things wrong (somebody will correct me if it's me who is wrong, hopefully). I had to follow these steps to get the right files: $ dget http://mentors.debian.net/debian/pool/main/p/pev/pev_0.22-1.dsc [...] $ tar xavf pev_0.22.orig.tar.gz AUTHORS LICENSE Makefile pe.h pev.1 pev.c README VERSION This is wrong, the .orig. has to contain the files in pev-0.22 directory, so: $ mkdir pev-0.22 $ tar xavf pev_0.22.orig.tar.gz -C pev-0.22/ AUTHORS LICENSE Makefile pe.h pev.1 pev.c README VERSION $ tar cavf pev_0.22.orig.tar.gz pev-0.22/ pev-0.22/ pev-0.22/LICENSE pev-0.22/Makefile pev-0.22/pe.h pev-0.22/AUTHORS pev-0.22/VERSION pev-0.22/README pev-0.22/pev.c pev-0.22/pev.1 Now .orig contains the same files but inside pev-0.22. Patching worked all right: $ gunzip -c pev_0.22-1.diff.gz | patch -p0 patching file pev-0.22/debian/control patching file pev-0.22/debian/compat patching file pev-0.22/debian/copyright patching file pev-0.22/debian/watch patching file pev-0.22/debian/pev.dirs patching file pev-0.22/debian/changelog patching file pev-0.22/debian/rules patching file pev-0.22/debian/source/format By the way, maybe you should use the format 3.0 (quilt) [1], it seems to be preferred now and it requires very few changes. [1] http://wiki.debian.org/Projects/DebSrc3.0 So what I did is to put 3.0 (quilt) in debian/source/format, then, inside the directory pev-0.22, debuild without signing: $ debuild -us -uc And everything worked perfectly. The important resulting files are: - pev_0.22.orig.tar.gz (as before) - pev_0.22-1.debian.tar.gz (substituted your initial pev_0.22-1.diff.gz, it has the same contents but in tar format) - pev_0.22-1.dsc - pev_0.22-1_i386.changes 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/201101112320.34627.manuel.montez...@gmail.com
Re: Time of a package to be processed by FTP-masters
Hi, On Wednesday 27 October 2010 16:24:38 Alexander Reichle-Schmehl wrote: 2.1- If so, what's would be the time appropriate to ask? 1 month for 1 Month sounds reasonable to me under normal circumstances. Two months have gone by, and no feedback. Is there any kind of alternative for these cases, a la Ubuntu PPA? I don't think so, from what I could gather... 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/201012161708.48233.manuel.montez...@gmail.com
Re: Time of a package to be processed by FTP-masters
On Thursday 16 December 2010 18:28:33 Luke Faraone wrote: On 12/16/2010 11:08 AM, Manuel A. Fernandez Montecelo wrote: On Wednesday 27 October 2010 16:24:38 Alexander Reichle-Schmehl wrote: 2.1- If so, what's would be the time appropriate to ask? 1 month for 1 Month sounds reasonable to me under normal circumstances. Two months have gone by, and no feedback. We're in a freeze. Poking the FTPmasters will not be useful, unless there's a reason your package should get reviewed before everything else in the queue. As has been said before, the developer will be notified if there's a problem with his package. I won't poke them to review my package, as if it was the most important thing in the universe, before anything else. I just wanted to ask about its status and possible review because my package is already towards the front of the queue since a few weeks ago, and new packages behind mine are being approved constantly, and mine isn't. Why is this important? In this lapse of time of 2 months, my package (1.7.1 version) was already obsoleted (by 1.7.2, with a lot of bug fixes). So I was wondering if it's worth to invest time in creating a package for 1.7.2, or if the effort might be futile because the package won't be reviewed and approved under any circumstance until freeze is over. By that time 1.7.3 might be out, and my effort wasted again, so I would choose not to create the 1.7.2 package at this moment. I think that these are pretty reasonable things that a contributor can ask, to decide what to do with his free time, but maybe I am wrong. In any case, having unresolved doubts about this, the voluntary effort that I could put forward in the next few weeks will be spent elsewhere, where the effort will hopefully be more appreciated and won't be wasted for sure. 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/201012161931.57837.manuel.montez...@gmail.com
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
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: Rescue Plan for apt-listbugs
Hi, Just copying the reply to the original author... he already said that he's not subscribed to the mailing list ;) Cheers. On Tuesday 05 October 2010 09:27:57 Jan Hauke Rahm wrote: On Mon, Oct 04, 2010 at 11:29:28PM +0200, Francesco Poli wrote: Hi everybody, I need help. I am not a DD, nor a DM; nonetheless, I am one of the two current co-maintainers of apt-listbugs. The other one is Ryan Niebur. My problem is that I've lost contact with him: he seems to be currently (almost) MIA. FWIW, I have been working with him as well and found him rather inactive lately. I've now contacted him and will see where this leads. Francesco, if you fear someone's MIA, please feel free to contact (or CC) the MIA team at m...@qa.debian.org. I just happened to see your concerns here. Hauke on behalf of Debian QA/MIA -- 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/201010051054.30340.manuel.montez...@gmail.com
Re: purging upstream source tarball, or not?
Hello, On Saturday 17 July 2010 09:54:16 Paul Wise wrote: 2010/7/17 Sébastien Barthélemy barthel...@crans.org: Besides collada-dom, the upstream svn and tarballs include several related programs, which I do not plan to build. They are either - dependancies (such as pcre) which are already packaged separately in debian, Please ask upstream to remove embedded code copies from their SVN and tarballs. I don't think that when upstream has those 3rd party packages included with extra effort (supporting them in their build systems, in some cases even supporting conditional-building with either the in-source copy or use the copy already installed in a system, freshen upstream from time to time, etc) would consider removing them just because somebody asks, even if it comes from a well-known distribution like Debian/Ubuntu. At least the packages that I'm thinking of, won't do it in a million years and would insist that it's better for their target users (and informal surveys of users' opinions seem to confirm that). Your Mileage May Vary, though. Do you know of cases where upstream agreed to do that? 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/201007180301.59414.manuel.montez...@gmail.com
Re: How to test a manpage? ‘nroff -man | less’ does not display like ‘man’.
Hi Charles, On Wednesday 14 July 2010 06:50:57 Charles Plessy wrote: Dear all, before updating a package, I wanted to look at the new upstream manpage, but realised that ‘nroff -man’ does not produce the same output as ‘man’ itself. Let's take the example of samtools(1) from the samtools package. With ‘man samtools’, users can see tables like the following one in the section ‘SAM FORMAT’. ┌┬───┬── ┐ │Col │ Field │ Description │ ├┼───┼── ┤ │ 1 │ QNAME │ Query (pair) NAME │ │ 2 │ FLAG │ bitwise FLAG │ │ 3 │ RNAME │ Reference sequence NAME │ (…) But with ‘zcat /usr/share/man/man1/samtools.1.gz | nroff -man | less’, here is what I get. center box; cb | cb | cb n | l | l . Col Field Description _ 1QNAME Query (pair) NAME 2FLAG bitwise FLAG 3RNAME Reference sequence NAME 4POS 1-based leftmost POSi‐ The workaround I found was to copy the new manpage in /tmp/man/man1, and call ‘man -M /tmp/man samtools’. Does anybody know how a more convenient to display a manpage the same way as users will get it by using ‘man’ ? Have a nice day, I don't know if this would help you, but the canonical (lintian) way to check that everything is OK is like this: LANG=en_US.UTF-8 MANWIDTH=80 man --warnings -E UTF-8 -l file /dev/null You might want to pipe it through |less or something to check for visual artifacts. from: http://lintian.debian.org/tags/manpage-has-errors-from-man.html Cheers. -- Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
Re: Litte problem with Build-Depends and architectures
Hello, On Wednesday 07 July 2010 16:46:20 Jakub Wilk wrote: * Manuel A. Fernandez Montecelo manuel.montez...@gmail.com, 2010-07-07, 02:01: --- I: Building the package I: Running cd tmp/buildd/*/ dpkg-buildpackage -us -uc -rfakeroot [...] dpkg-buildpackage: source package k3d dpkg-buildpackage: source version 0.8.0.2-2 dpkg-buildpackage: source changed by Manuel A. Fernandez Montecelo manuel.montez...@gmail.com dpkg-buildpackage: host architecture i386 dpkg-checkbuilddeps: Unmet build dependencies: libinotifytools-dev dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) E: Failed autobuilding of package --- This is bug #363193. Thanks for the information. But what should I do, then? Does that mean that I can submit the package to the farm and hope that it'll work OK there? 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/201007071828.25587.manuel.montez...@gmail.com
Re: Litte problem with Build-Depends and architectures
On Wednesday 07 July 2010 19:38:32 Jakub Wilk wrote: But what should I do, then? Does that mean that I can submit the package to the farm and hope that it'll work OK there? By the farm you mean the autobuilder network? The answer is maybe, see this thread: http://lists.debian.org/debian-wb-team/2010/07/msg7.html Yes, I meant the autobuilder network. The package in question takes about 1h to compile in a modern laptop (with that I mean that it's not the leanest of the software packages out there, it can take many hours on ARM or old machines), and it's out of question to try to compile it on qemu or similar emulations. I don't know if it's appropriate to submit it as I have now and try, and if they don't work submit again with that disabled, etc (so I'll be spending several days on trial-and-error maybe misusing the autobuilder network), or I should just leave non-linux architectures just failing as they do now, or try to disable the specific dependency in some other way (surely more packages have this issue and they have to solve it in some way or another), or what. 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/201007071953.20759.manuel.montez...@gmail.com
Re: Litte problem with Build-Depends and architectures
Hello, On Wednesday 07 July 2010 23:37:26 Holger Levsen wrote: Hi, On Mittwoch, 7. Juli 2010, Manuel A. Fernandez Montecelo wrote: This is bug #363193. But what should I do, then? use the patch from that bug? According to the link (and other threads in debian-wb-team) that Jakub posted, it wouldn't work in the autobuild network anyway, they're still trying to get it working. 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/201007080026.54438.manuel.montez...@gmail.com
Litte problem with Build-Depends and architectures
Hello, I'm updating K3D to a new version, and I have a little problem with the dependencies when trying to use pbuilder to check that everything is all right. One of the dependencies that this software makes use of, if available, is inotify (libinotifytools-dev virtual, or ...0-dev for the real package). I noticed that this is not available in hurd or kfreebsd, so the package is BD-uninstallable in the farm. So I tried to follow the Policy Manual: http://www.debian.org/doc/debian-policy/ch-relationships.html which says for cases like this that I can use foo [linux-any], or equivalently foo [!hurd-i386] and similar relationships/constraints. When I use libinotifytools0-dev [linux-any] (same without 0, using the virtual package), I get this error from pbuilder at some point: --- I: Building the package I: Running cd tmp/buildd/*/ dpkg-buildpackage -us -uc -rfakeroot [...] dpkg-buildpackage: source package k3d dpkg-buildpackage: source version 0.8.0.2-2 dpkg-buildpackage: source changed by Manuel A. Fernandez Montecelo manuel.montez...@gmail.com dpkg-buildpackage: host architecture i386 dpkg-checkbuilddeps: Unmet build dependencies: libinotifytools-dev dpkg-buildpackage: warning: Build dependencies/conflicts unsatisfied; aborting. dpkg-buildpackage: warning: (Use -d flag to override.) E: Failed autobuilding of package --- and indeed, pbuilder doesn't try to install the package libinotify*dev. Same when using libinotifytools0-dev [!kfreebsd-any !hurd-any], which would be equivalent for my purposes. Does anybody know why this happens, if I'm missing something, or can hint me about what's the real problem? (Maybe its a problem with pbuilder and it would work in the farm, but it's a pretty big package which takes hours to compile in most of the architectures, so I prefer to ask before/rather than attempting the trial- and-error approach, to not put extra load on the farm...). 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/201007070201.56083.manuel.montez...@gmail.com
Fwd: failed hppa build of aqsis 1.6.0-1.2
Hello, Can anybody tell me what I'm supposed to do with this? It builds fine in the rest of architectures: https://buildd.debian.org/pkg.cgi?pkg=aqsis And the log doesn't say anything interesting about what the failure is... it's like the process was in an infinite loop, or maybe killed by some segfault or something... [ 37%] Compiling shader /build/buildd-aqsis_1.6.0-1.2-hppa- rxuuD6/aqsis-1.6.0/shaders/displacement/dented.sl make[3]: *** [shaders/displacement/AqDMap.slx] Terminated make[3]: *** [shaders/displacement/dented.slx] Terminated make[2]: *** [shaders/CMakeFiles/all_shaders.dir/all] Terminated make[1]: *** wait: No child processes. Stop. make[1]: *** Waiting for unfinished jobs make[1]: *** wait: No child processes. Stop. make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs make: *** wait: No child processes. Stop. E: Caught signal 'Terminated': terminating immediately Build killed with signal TERM after 150 minutes of inactivity Another attempt... [ 55%] Compiling shader /build/buildd-aqsis_1.6.0-1.2-hppa- XEK7vq/aqsis-1.6.0/shaders/displacement/dented.sl make[3]: *** [shaders/displacement/dented.slx] Terminated make: *** wait: No child processes. Stop. make: *** Waiting for unfinished jobs E: make: *** wait: No child processes. Stop. Caught signal 'Terminated': terminating immediately And -1.1 had similar problem (only on hppa, too), but with the compilation around 82%... The package is a (software) 3D renderer which require quite a lot of power, probably, they won't bother if it won't run in a retired architecture being phased out by the vendor. Is there a way to ask for more info to the buildd system? Is it a problem if I leave it like this, or should I better mark it as don't build this package in hppa in the control file? Cheers. -- Forwarded Message -- Subject: failed hppa build of aqsis 1.6.0-1.2 Date: Wednesday 30 June 2010, 12:00:04 From: Debian buildds nore...@buildd.debian.org To: aq...@packages.qa.debian.org * Source package: aqsis * Version: 1.6.0-1.2 * Architecture: hppa * State: failed * Suite: unstable * Builder: lafayette.debian.org * Build log: https://buildd.debian.org/fetch.cgi?pkg=aqsisarch=hppaver=1.6.0-1.2stamp=1277891975file=log Please note that these notifications do not necessarily mean bug reports in your package but could also be caused by other packages, temporary uninstallabilities and arch-specific breakages. A look at the build log despite this disclaimer would be appreciated however. - -- 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/201006301520.11347.manuel.montez...@gmail.com
Re: Fwd: failed hppa build of aqsis 1.6.0-1.2
Hi, On Wednesday 30 June 2010 22:05:25 The Fungi wrote: On Wed, Jun 30, 2010 at 03:20:10PM +0200, Manuel A. Fernandez Montecelo wrote: Can anybody tell me what I'm supposed to do with this? It builds fine in the rest of architectures: https://buildd.debian.org/pkg.cgi?pkg=aqsis And the log doesn't say anything interesting about what the failure is... it's like the process was in an infinite loop, or maybe killed by some segfault or something... [...] You might also ask on debian-h...@ldo in case someone there is willing to provide assistance debugging it on the platform. Since it's a graphical app, I'm guessing a build on my 712/60 is probably out of the question but there are others with more powerful systems or access to the porter boxes. It's not a graphical app, it's an offline renderer, not a modeller like Blender. You send the scene to be rendered (output of Blender or similar) and it produces an image, video, or something like that. By default after rendering, opens it in a window, but it's a very simple fltk one. So maybe you want to give it a try. It takes about ~10 minutes to compile in my 2 year old, dual core not very powerful laptop. I don't know how hppa compares to these ones, but just in case, buildd official times are: mipsel: Build needed 00:52:51, 264392k disc space armel: Build needed 06:53:56, 266224k disc space i386: Build needed 00:07:44, 248728k disc space ia64: Build needed 00:39:33, 405948k disc space The point is that upstream authors only care in principle about the main SOs and popular hardware architectures (I don't see them putting resources to solve this), and most hardware architectures are probably quite slow and thus not suited to use such renderer anyway. On the other hand, in general it doesn't harm to have the package available in such architectures, and it's one of the main points of Debian anyway. So I think that the main possibilities are: 1) Do nothing. 2) Put an exception in control file so it doesn't build in that architecture, or something like that. 3) Try to debug it, with no support from upstream and no easy access to such machines. Honestly I don't think that it pays to puch effort in this one, given the target users (already a niche) and so on. Cheers, and thanks for the reply. -- 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/201006302341.54566.manuel.montez...@gmail.com
Re: Fwd: failed hppa build of aqsis 1.6.0-1.2
On Thursday 01 July 2010 00:15:12 The Fungi wrote: On Wed, Jun 30, 2010 at 11:41:53PM +0200, Manuel A. Fernandez Montecelo wrote: [...] It takes about ~10 minutes to compile in my 2 year old, dual core not very powerful laptop. I don't know how hppa compares to these ones, but just in case, buildd official times are: mipsel: Build needed 00:52:51, 264392k disc space armel: Build needed 06:53:56, 266224k disc space i386: Build needed 00:07:44, 248728k disc space ia64: Build needed 00:39:33, 405948k disc space [...] Hmm... yeah, my 712/60 has about that much available space on its 1G SCSI drive, but only a 60MHz CPU and 32MiB of RAM. I compile small utilities and applications on it in a matter of 5-10 minutes which take all of a few seconds on my faster systems. Chances are this would take hours if it even completed at all. It's not quite as slow as my Mac Quadra, but it's pretty close. As I said, the HPPA porters probably have access to suitable hardware for replicating this problem (but I definitely don't). All right, thank you very much for your reply and tips :) 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/201007010041.50254.manuel.montez...@gmail.com
