Re: [Pkg-utopia-maintainers] Bug#895261: RFS: dbus-broker/13-2 [ITP] -- Linux D-Bus Message Broker
On Sun, Jul 8, 2018 at 9:34 PM Michael Biebl wrote: > Hi Daniele > > Am 09.07.2018 um 01:45 schrieb Daniele Nicolodi: > > my attempt to implement user service management in init-system-helpers > > and debhelper unfortunately stalled by lack of review of the > > init-system-helper patches. Before I loose all interest, how do prefer > > to solve the issue of user units in the dbus-broker package? > > I sincerely apologize for that. > Let me apologize too. > I'm a bit tight on time atm, but it should get better in a few weeks. > My perl is a bit rusty, but I'll try to have a look at it then. I hope > you can bare with us for a little longer. > Felipe, would you be able to review the patches? > Unfortunately I don't think so, at least not until August. I did take a look, and it looked reasonable to me. I have not taken a look at the latest iteration though. I was tempted to do a merge and release (early and often, right?) but I'm going to be particularly unavailable for about a month so I wouldn't be able to do any necessary followups in a timely manner. -- Saludos, Felipe Sateler
Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
(moving discussion to RFS bug, please keep me in CC) On 1 December 2015 at 11:15, Roger Shimizu <rogershim...@gmail.com> wrote: > Dear Felipe, > > Considering now we have consensus on the service file except the > description part, which is quite minor, I made a release build of > adjtimex package and uploaded to mentors. OK > > I also created a RFS: https://bugs.debian.org/806797 > > Since you helped me greatly on the service file, which is the most > significant improvement of this version (adjtimex/1.29-6), I hope you > can kindly be my sponsor to upload. Thank you! Sure! I have a few comments, though: - uscan tells me that there is no 1.29 version in the upstream page. And indeed there is only 1.28. What happened? - It would be great if you forward your patches upstream. - The dirs file is not needed. It is only useful when a package needs to ship a directory that is not created by anything else in the build process. In your case, all directories are created by either the upstream build system or the debhelper commands. - I would change all /bin/sh -e in maintainer scripts to use #!/bin/sh\nset -e. This way, if it is invoked via `sh $script`, then it will still get the -e option. Otherwise looks good -- Saludos, Felipe Sateler
Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
On 2 December 2015 at 13:33, Roger Shimizu <rogershim...@gmail.com> wrote: > Dear Felipe, > > Thanks for your favor! > >> - uscan tells me that there is no 1.29 version in the upstream page. >> And indeed there is only 1.28. What happened? >> - It would be great if you forward your patches upstream. > > I actually created the pkg repo by "gbp import-dscs --debsnap > adjtimex", so now I have all the history. > I found 1.29 version was introduced by "James R. Van Zandt > <j...@debian.org>", who acted both pkg maintainer and upstream > maintainer. > I guess he just released 1.29 and forgot to put it in upstream's website. > I didn't contact him and confirm this yet, but he seems to be MIA for > a few years. [0] Hmm. It would be great if you could try reaching out anyway (there are a few more emails in the ChangeLog file). > >> - The dirs file is not needed. It is only useful when a package needs >> to ship a directory that is not created by anything else in the build >> process. In your case, all directories are created by either the >> upstream build system or the debhelper commands. >> - I would change all /bin/sh -e in maintainer scripts to use >> #!/bin/sh\nset -e. This way, if it is invoked via `sh $script`, then >> it will still get the -e option. > > Thanks for your advice! > I already modified as you suggest, and uploaded to mentors again. Looks good. There is only the slightly weird line about adding stuff to debian/dirs and then removing it ;) I will try to upload during the week, if I haven't by the weekend please ping me again. -- Saludos, Felipe Sateler
Bug#806797: Bug#796588: adjtimex: Has init script in runlevel S but no matching service file
On 2 December 2015 at 20:22, Roger Shimizu <rogershim...@gmail.com> wrote: > On Thu, Dec 3, 2015 at 2:59 AM, Felipe Sateler <fsate...@debian.org> wrote: >> On 2 December 2015 at 13:33, Roger Shimizu <rogershim...@gmail.com> wrote: >>> I guess he just released 1.29 and forgot to put it in upstream's website. >>> I didn't contact him and confirm this yet, but he seems to be MIA for >>> a few years. [0] >> >> Hmm. It would be great if you could try reaching out anyway (there are >> a few more emails in the ChangeLog file). > > Understand. I put it on my todo list. > >>>> - The dirs file is not needed. It is only useful when a package needs >>>> to ship a directory that is not created by anything else in the build >>>> process. In your case, all directories are created by either the >>>> upstream build system or the debhelper commands. >> Looks good. There is only the slightly weird line about adding stuff >> to debian/dirs and then removing it ;) > > Sorry about that on debian/changelog. > Already fixed and re-uploaded to mentors. Too late ;), I had a moment to upload, and I decided to do it anyway. On the next upload you can do it with the fixed changelog. -- Saludos, Felipe Sateler
Bug#768878: RFS: sfarklib/0.20131219gitee08d0c-1 [ITP]
On Wed, Feb 18, 2015 at 6:39 PM, Ruben Undheim ruben.undh...@gmail.com wrote: Hi Felipe, Do you have some time for sponsoring of these two packages? (sfarklib and sfarkxtc) Or should we ask someone else? Hi, I'm terribly sorry, but I have been insanely busy these days and will continue to be so for a while. If you can find another sponsor please go ahead. I'm unlikely to be available for this until mid-march. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caafdzj8gggnc0vz9fe8rmm473letuworg0pgl+ygdrhnc-u...@mail.gmail.com
Bug#768878: RFS: sfarklib/0.20131219gitee08d0c-1 [ITP]
On Fri, Dec 5, 2014 at 5:39 PM, Ross Gammon r...@the-gammons.net wrote: As I said before I will be happy to co-maintain this with you in the Debian Multimedia team. I am now a DM. So if we can convince a sponsor to upload sfarklib, then after it passes the new queue we may be able to convince the same sponsor to give me upload permission sometime. I'm willing to sponsor as long as the packages have 2 comaintainers. I;ve been busy and may continue so for the next few weeks, so maybe it will take some time for me to actually look at the packages though. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAfdZj-L0yG0_t9peV=bigD8Yvhm7-jFnOAVDR8Gwuqc=rx...@mail.gmail.com
Re: question about proprietary libraries
On 01/09/10 20:40, Stephen Sinclair wrote: Hello, This is a general question about linking to proprietary libraries. Specifically I am thinking about developing a library which will work normally in the general case, but in some cases the user might have a proprietary library installed on their system, in which case I'd like to dynamically load that library and call out to its functions. The proprietary library in this case would be for doing I/O with a particular hardware device, for which there is currently no open source alternative. Therefore the user owning such a device would have installed the software and expect my library to work with it. Conversely, he would not have the proprietary library unless he has the device in question.. so I sort of think of this library as being part of the device. I don't have the ability to reverse engineer it and write my own drivers, but I'd still like users of this device to be able to make use of my software. Would such a library have difficulty getting accepted by Debian? Are there other examples of libraries in Debian which optionally leverage proprietary code if it is available? Not exactly a library, but the kernel will load proprietary firmware if it finds it available and the device in question exists. As long as your software is useful without said proprietary library, it can go in main. If not, it should go in contrib. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: dfsg bit in the package name
On 18/08/10 18:23, gregor herrmann wrote: On Wed, 18 Aug 2010 22:42:09 +0100, Tomasz Muras wrote: Is there any preference/reasoning for using any particular symbol that joins dfsg bit with the package name? I can see that different packages use a different format, here are some quick stats from packages in unstable (with the counts): 1179 +dfsg 1119 .dfsg 233 ~dfsg 201 -dfsg Should I use + or .? Should that be somehow standardized or mentioned in the faq? Or do you reckon that it doesn't make any difference at all and should be left up to maintainers? The difference is in the sorting: lintian tells us the following about it: $ lintian-info -t dfsg-version-with-period N: dfsg-version-with-period N: N: The version number of this package contains .dfsg, probably in a N: form like 1.2.dfsg1. There is a subtle sorting problem with this N: version method: 1.2.dfsg1 is considered a later version than 1.2.1. If N: upstream adds another level to its versioning, finding a good version N: number for the next upstream release will be awkward. N: N: Upstream may never do this, in which case this isn't a problem, but N: it's normally better to use +dfsg instead (such as 1.2+dfsg1). + N: sorts before ., so 1.2 1.2+dfsg1 1.2.1 as normally desired. N: N: Severity: minor, Certainty: possible N: And if there are any prospects of upstream cleaning up their tree, the ~ symbol makes it possible to re-release the same tarball without the offending files. -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Working with upstream-developed debian packaging
Hi all, I recently developed an interest in Code::Blocks, which is not currently in Debian, and the current ITP has shown no real activity for over a year. However, an upstream developer does provide unofficial debian packages, and I would like to polish them and upload to Debian, acting as a sponsor rather than co-maintainer. So, the problem is that currently the debian packaging lives in the same subversion repository as upstream development, with the associated problems (native package, or in a best case scenario a very dirty diff; entanglement of upstream development with debian packaging development). If upstream were using git, the solution would be pretty simple, just branch and merge from upstream as required (as done by many packagers in debian). However, subversion is in use, and last time I tried a merge in svn it was a complete disaster, so I'm not recommending that strategy. What workflows could be used, to avoid a fork? -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: Working with upstream-developed debian packaging
On 03/08/10 17:15, Josue Abarca wrote:
On Tue, Aug 03, 2010 at 05:04:20PM -0400, Felipe Sateler wrote:
Hi all,
I recently developed an interest in Code::Blocks, which is not currently
in Debian, and the current ITP has shown no real activity for over a year.
However, an upstream developer does provide unofficial debian packages,
and I would like to polish them and upload to Debian, acting as a
sponsor rather than co-maintainer.
So, the problem is that currently the debian packaging lives in the same
subversion repository as upstream development, with the associated
problems (native package, or in a best case scenario a very dirty
diff;
I think this is a good option to avoid the dirty diff:
From http://wiki.debian.org/Projects/DebSrc3.0
...
* You don't have to repack the upstream tarball to strip the debian
directory. (The debian directory is automatically replaced by the
content of the .debian.tar.{gz,bz2,lzma} file at unpack time)
...
That still leaves me with the next issue:
entanglement of upstream development with debian packaging development).
I do not want to have to upload svn snapshots each time a
debian-specific thing needs to be adjusted.
--
Saludos,
Felipe Sateler
signature.asc
Description: OpenPGP digital signature
Re: Working with upstream-developed debian packaging
On 03/08/10 19:29, Charles Plessy wrote: Le Tue, Aug 03, 2010 at 05:04:20PM -0400, Felipe Sateler a écrit : If upstream were using git, the solution would be pretty simple, just branch and merge from upstream as required (as done by many packagers in debian). However, subversion is in use, and last time I tried a merge in svn it was a complete disaster, so I'm not recommending that strategy. What workflows could be used, to avoid a fork? Dear Felipe, how about using git-svn ? In parallel, you can forward upstream your changes to the debian directory, so that merges of new upstream release are easy. But that would imply changing the scm tool for the maintainer (which I noted above is not me). -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: Working with upstream-developed debian packaging
On 03/08/10 20:52, Charles Plessy wrote: Le Tue, Aug 03, 2010 at 07:58:08PM -0400, Felipe Sateler a écrit : that would imply changing the scm tool for the maintainer (which I noted above is not me). I am confused… In the upstream Subversion repository, there is a debian directory whose maintainer is a Code::Blocks developer. http://svn.berlios.de/svnroot/repos/codeblocks/trunk/debian/control Yes. In the ITP bug, it is mentionned that the package prepared for Debian is already in Ubuntu. The Debian directory is not the same and the VCS containing the source package is not mentionned. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570#101 On your side, you would like to contribute as co-maintainer to the Debian package, which has not been accepted yet. It has been proposed that you ignore upstream's debian directory using the 3.0 (quilt) format, but if your intention is to be a co-maintainer, then the decision of which format to use is not entirely in you hands. If your goal is to stay close to the debianization work of the upstream maintainers, you can pull the upstream Subversion repository with git-svn. Using git you can produce patches that can be sent upstream. This does not require them to switch to git. This said, I recommend that you do not ignore the package that is already in Ubuntu… http://packages.ubuntu.com/codeblocks Hmm, I think I need to polish my reading skills... I missed the part where codeblocks was actually uploaded to Ubuntu. I will get in touch with the Ubuntu maintainers, then, so that we can avoid duplicating effort. Thanks for noticing this! -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: RFS: julius - speech recognition engine
On 04/07/10 16:15, Siegfried-Angel Gevatter Pujals wrote: Dear mentors, I am looking for a sponsor for the new version 4.1.5-1 of my package julius. It builds these binary packages: julius - speech recognition engine libjulius-dev - speech recognition engine - development headers A few comments: - Why do you modify the manpages via sed instead of patching them? - You say you remove a manpage because you have a better one, but there is not actually one (dfa_minimize)? - Any reason why you don't enable parallel builds with DEB_BUILD_PARALLEL? - Why are there only static libraries? ... and I'm not quite confident about the license, specially about the Kyoto District Court venue thing (clause 5). -- Saludos, Felipe Sateler signature.asc Description: OpenPGP digital signature
Re: RFS: julius - speech recognition engine
[ No need to CC me, I read the list ] On 13/07/10 19:47, Siegfried-Angel Gevatter Pujals (RainCT) wrote: Hi Felipe, Thank you for taking a look at the Julius package. No problem. 2010/7/13 Felipe Sateler fsate...@debian.org: - Why do you modify the manpages via sed instead of patching them? Because IMHO it's much easier to maintain than having a big patch which I have to update every time a manpage changes. OK, indeed this seems like a better approach. - Why are there only static libraries? It's what upstream's build system provides, and I was told that the libraries do stuff like calling abort() so I haven't really bothered about it. I want to look into this some day though and maybe patch it. Well, its probably better to fix that first instead. ... and I'm not quite confident about the license, specially about the Kyoto District Court venue thing (clause 5). Uhm, isn't that a common thing in licenses? It's the least clause I'd have expected to be problematic, personally I'm more worried about the advertising clause. In any case, I could live with it if the package goes into non-free. The thing is that I'm not a legalese person, so I'm not confident enough to upload it. Would you mind passing the license through debian-legal and see what they say? -- Saludos, Felipe Sateler -- 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/4c3cff09.6020...@debian.org
Re: RFC: Using git/collab-maint/PET for debian-mentors.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/06/10 10:05, Tim Retout wrote: Proposal I am considering creating a new workflow for my sponsoring: * Maintaining packages in git in collab-maint. (I don't think we want a separate pkg-mentors repository, because once people graduate from mentors they would feel compelled to move away.) * Using PET or similar to show which packages need review, and keep track of bugs/upstream versions. (Minor issue: I don't know how easy this is without putting the whole of collab-maint into PET.) * Optionally co-ordinating on IRC in #debian-mentors, as well as via notes at the top of debian/changelog. This would then require my mentees to do some things they don't do at the moment: * Register for an alioth account. * Learn how to maintain packages in a VCS. * Use the 'UNRELEASED/unstable' method of changelog management (and probably stop bothering with the RFS mails). It would also allow potential contributors to collaborate on packaging work in a team, rather than every sponsored package being worked on by exactly one person. I would most likely enforce the use of short dh7 rules files as well, and go all out on the 'lintian -iI --pedantic' warnings, same as I do with regular sponsorship. And of course, any packages which belong in other teams should be sent there - the steps above should have lowered the barrier to entry to the rest of Debian. Information that is likely to become relevant for different sponsors (like VCS in use, debian/rules style [dh/cdbs/debhelper]) could be shown on the PET page. Different sponsors are likely to have different requirements. The only problem I see is that PET does not really scale well to lots of packages, the page gets quite cluttered. So I don't know if pulling the whole collab-maint area will be of any use. - -- Saludos, Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMFtQMAAoJEKO6uuJAjdbPKioP/0P8ufyVc//HTliJ8Xs+K4Do HZ7we1v+a5WnsIaBLDsIaZuDUfwJ5BfnGmL+kmVIv4f/XkAkkhQVHmqDm0EnqSvQ Luob721sr6QlROsRkVNWsKXZ/D9AOjF/KBFcgUjVnvpOvEDjgcCoqTpRQ9CIvQWl WMDNQ0J5gdBWNyP94TQ9pxAOfbnGOgVKKGeZvIn8/WoO2xiSpa+4stupQlrA/DZk EQL/QFfHoBhfIQ+7zogRy/jydedZp+9Cig5ijLXvTrIjbuKzRVSNaNhmUs5D0jbu 1zQaGPAY1x5i3UNKwGKnvEgZEqinuJG+k72l/ctFpXmxhR/OqlCcO/RkslqopTNy u8+KVSzSACLy6cg8QSqYpZ8Dc7rar9JW8wb3J2PJ/HM+pQRBFQyKQpnt+vLiU2We ekVrSB7tudvbOtv4hbCEeBm6fvdDtkQYeQCL1wZx33B3CUiQLCXcByS+WAz6qZBu wB+KUnO+qwmE256zCizFemiwuKdXwMh/vgl08cQ7axbnbr8SjUMlPn45IlhpLaLh Ze/qmaD7xnUTR6h2myQdgWwnwNl+/DavR09T6didMRmSeNmReueSXaUOVQIGFPb+ H3WyDhuZvULrBtorihxJxkppgvz/kMYwG01gj/T6jnIHgCvByEBTp9Gr+xG/ffCX /P7q+B9PhJVtYURKT/Vr =zlkJ -END PGP SIGNATURE- -- 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/hv6k6n$aa...@dough.gmane.org
Re: RFC: Using git/collab-maint/PET for debian-mentors.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/06/10 01:55, Ansgar Burchardt wrote: I started working on a version of PET that supports several VCS backends, even for a single instance: all packages show up on a single package no matter in which of the known VCS they live in. For now it supports Git and SVN as I use those myself. It still needs some work, but is slowly getting usable. Is that available somewhere? - -- Saludos, Felipe Sateler -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJMFtfnAAoJEKO6uuJAjdbPAjIP/iJuvKuG0kgdtdt/9V55Tq7Q NV779UIlJh5b5vBoA0dsYAZg8MKlRNpRhAv2QgTauqhsERdWbxarG57tLD00BUGQ 94OQr/3mizXqX1VsYyru890UyJ7r0CBdYYfNGMkoXIMjrYIbNoiY0TtwQKG6UMyf qgkDNPab1Tqq59AdrrhcbLYik9AbTUnfzbBeeX5/oFdyvUWmicBER/iOPNbccMro OCf0X9oRDz76eB8fW30KFM5w/PgtNU9Xmgc5t2ovCHo7AGeBx0xZKRLwU1rfvHP5 fIkjeIPev+cqnKNBWc8g6c9XaMrQ4Ppe411j7uZpcXLSvN73HH4/DStebz/bBHwp G5m/Wp/pevx1FY33vgfEXqJx1rNfxwbG4MzNRpGoLPVESK3Vhwo1V7eOjace7Bb4 q0Fk6ygsk+P4kv46RiPaLyzwesT9rU8yvVXdr0lrFv13qz66n7dxshgo0upvFMY8 VId7xwpYrs54+W6YncvWUHOFWcLSRf8Wfb4PtnEF2Arl32fBTbdzhUuWDS0kNnhk AJZDBM1a9GTStQI5HGNcT+RmAaizs3LPm7s+vXFNpzaOqnq3pkv4f/aabfXWyUKS Zmlr5XIbltZz4Yk1LaAis+3q1qV4mCTpSq8tn/Dg83E1UhnW0g2qdo/mqdEJQZ25 fvEcaCgKgi/nRxjgVVu6 =shof -END PGP SIGNATURE- -- 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/hv6l59$ce...@dough.gmane.org
Re: RFS: checkinstall (new upstream)
On 18/04/10 23:14, Charles Plessy wrote: Le Thu, Apr 15, 2010 at 11:16:25PM +0200, Jan Hauke Rahm a écrit : On Thu, Apr 15, 2010 at 04:28:13PM -0400, Felipe Sateler wrote: Dear mentors, I am looking for a sponsor for the new version 1.6.2-1 of my package checkinstall. As per the comments of Charles Plessy[1], I have set the DM-Upload-Allowed field in debian/control. The package looks quite good from a first glance. I would probably upload it but I don't feel comfortable doing so with DMUA as I have never sponsored a package of yours before. Putting Charles in CC, maybe he wants to pick up on it since he's the one suggesting it in the first place. Dear all, sorry for not having the time to answer faster. Felipe has been maintaining checkinstall since 2006 and I do not see any problem that would suggest that each of his uploads still needs to be reviewed. I am ready to sponsor a change of the DM-Upload-Allowed if Felipe would like. No need to worry, thanks for the offer. I don't think an upload just to set the DMUA flag is warranted. Should I need to do an upload, I will set the flag again. Saludos, Felipe Sateler -- 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/hqhkr9$73...@dough.gmane.org
Re: RFS: checkinstall (new upstream)
On 17/04/10 04:43, Jan Hauke Rahm wrote: On Fri, Apr 16, 2010 at 11:48:55AM -0400, Felipe Sateler wrote: On 15/04/10 17:16, Jan Hauke Rahm wrote: On Thu, Apr 15, 2010 at 04:28:13PM -0400, Felipe Sateler wrote: Dear mentors, I am looking for a sponsor for the new version 1.6.2-1 of my package checkinstall. As per the comments of Charles Plessy[1], I have set the DM-Upload-Allowed field in debian/control. The package looks quite good from a first glance. I would probably upload it but I don't feel comfortable doing so with DMUA as I have never sponsored a package of yours before. Putting Charles in CC, maybe he wants to pick up on it since he's the one suggesting it in the first place. If you want me to upload it with DMUA, contact me. I take it you meant without. Yes, just do that, please. Hopefully I will have finished the NM process by the time I need to make another checkinstall upload. Yes, uploaded. Thanks! Thanks! Saludos, Felipe Sateler -- 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/hqfdeu$km...@dough.gmane.org
Re: RFS: checkinstall (new upstream)
On 15/04/10 17:16, Jan Hauke Rahm wrote: On Thu, Apr 15, 2010 at 04:28:13PM -0400, Felipe Sateler wrote: Dear mentors, I am looking for a sponsor for the new version 1.6.2-1 of my package checkinstall. As per the comments of Charles Plessy[1], I have set the DM-Upload-Allowed field in debian/control. The package looks quite good from a first glance. I would probably upload it but I don't feel comfortable doing so with DMUA as I have never sponsored a package of yours before. Putting Charles in CC, maybe he wants to pick up on it since he's the one suggesting it in the first place. If you want me to upload it with DMUA, contact me. I take it you meant without. Yes, just do that, please. Hopefully I will have finished the NM process by the time I need to make another checkinstall upload. Saludos, Felipe Sateler -- 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/hqa0t8$nl...@dough.gmane.org
RFS: checkinstall (new upstream)
Dear mentors, I am looking for a sponsor for the new version 1.6.2-1 of my package checkinstall. As per the comments of Charles Plessy[1], I have set the DM-Upload-Allowed field in debian/control. It builds these binary packages: checkinstall - installation tracker The package appears to be lintian clean. The upload would fix these bugs: 478312, 490633, 510681, 570510 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/checkinstall - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/checkinstall/checkinstall_1.6.2-1.dsc I would be glad if someone uploaded this package for me. [1] http://lists.debian.org/debian-mentors/2009/11/msg00351.html -- Saludos, Felipe Sateler -- 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/y2v8a0bda451004151328pd39e111dh77d3534acee36...@mail.gmail.com
Re: example vs contrib?
On Tue, 2009-12-22 at 22:34 +0100, Ludovico Cavedon wrote: Felipe Sateler wrote: On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote: Upstream for tortoisehg (interface for mercurial) distributes in their tarball a file: contrib/_hgtk which enables zsh completion script for tortoisehg. I am not a zsh user and I would not feel confident in installing that script in a location so it is automatically enabled for all zsh users, nevertheless I would like to distribute it. What do you think is the proper location? Ask upstream to submit the zsh completion to zsh. And in the meanwhile, Ah, so it should be zsh to distribute the completion script for virtually everything? Last time I read about it, they recommended submitting the completions. It might be different now, but it doesn't cost much. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: example vs contrib?
On Mon, 2009-12-21 at 00:03 +0100, Ludovico Cavedon wrote: Hi all, Upstream for tortoisehg (interface for mercurial) distributes in their tarball a file: contrib/_hgtk which enables zsh completion script for tortoisehg. I am not a zsh user and I would not feel confident in installing that script in a location so it is automatically enabled for all zsh users, nevertheless I would like to distribute it. What do you think is the proper location? /usr/share/tortoise-hg/contrib/_hgtk /usr/share/tortoise-hg/examples/_hgtk other? Max (in CC) and I had a discussion about that and could not agree :) Ask upstream to submit the zsh completion to zsh. And in the meanwhile, install it globally for all zsh users. If there are problems, they will be reported, and you can forward them to upstream. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: weak-library-dev-dependency is there a lintian bug ?
On Tue, 2009-12-01 at 16:43 +0100, Picca Frédéric-Emmanuel wrote:
Hello I am developping a package for the tango control system.
the upstream tango-7.1.1.tar.gz contain in fact a sub package.
in the configure.in there is a
AC_CONGIF_SUBDIRS(blablabla...)
this sub package provide a librairy but the version number is taken from its
AC_INIT with this line in the debian/rule file:
LOG4TANGO_VERSION := $(shell egrep AC_INIT lib/cpp/log4tango/configure.in |
cut -f 2 -d ' ' | cut -f 1 -d ',')
DEB_NOREVISION_VERSION := $(shell dpkg-parsechangelog | egrep '^Version:' |
cut -f 2 -d ' ' | cut -f 2 -d '-')
for now the version is 4.0.3-1 != (= ${binary:Version})
You want the debian package version, not the library version. So I think
lintian is correct here: liblog4tango4 version will be ${binary:Version}
(something like 7.1.1-1), not 4.0.3-1.
Unless you are doing something _really_ weird and changing the version
per-binary?
--
Saludos,
Felipe Sateler
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RE : Re: weak-library-dev-dependency is there a lintian bug ?
OOps, I didn't reply to list either :p
On Tue, 2009-12-01 at 15:16 -0300, Felipe Sateler wrote:
(please reply to list)
On Tue, 2009-12-01 at 18:41 +0100, PICCA Frédéric-Emmanuel wrote:
Hello
You want the debian package version, not the library version. So I think
lintian is correct here: liblog4tango4 version will be ${binary:Version}
(something like 7.1.1-1), not 4.0.3-1.
ok so I can generate a log4tango4-dev debian package with the 7.1.1 version
which provided the library liblog4tango.so.4.0.3
debian version != library version
Exactly
Unless you are doing something _really_ weird and changing the version
per-binary?
Yes I have one package tango-7.1.1 with a sub package log4tango-4.0.3
this is why I decided to change the debian version for the log4tango4-*
debian binary packages
to keep in synchro with the real log4tango upstream package version.
You shouldn't do this. It adds complexity for no gain (after all, the
_source_ version is 7.1.1, not 4.0.3). Library versions do not match
project versions, since they generally used to track interface issues.
--
Saludos,
Felipe Sateler
signature.asc
Description: This is a digitally signed message part
Re: Buildd failed: C compiler cannot create executables
On Sat, 2009-11-28 at 03:17 +0100, Cyril Brulebois wrote: Felipe Sateler fsate...@gmail.com (26/11/2009): Your package build-depends on ccache, and it actively enforces it in the debian/rules file. Why is that? I would be willing to bet money that the problem is that buildd's have no (writable) home directory, so ccache fails. Drop the ccache stuff, or if it _absolutely_ necessary, setup a bogus $HOME so that ccache can work in the buildds. I shall collect your money. Next time, check the facts. Which would be...? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Buildd failed: C compiler cannot create executables
On Thu, 2009-11-26 at 20:34 +0100, Joachim Wiedorn wrote: Hello, while building the new package 'Xfe' I can see that buildd failed on some architectures. See: https://buildd.debian.org/~luk/status/package.php?suite=p=xfe They failed all with the same error: checking for gcc... ccache cc checking for C compiler default output file name... configure: error: C compiler cannot create executables See `config.log' for more details. That is my first package build on buildd! Could it be, that ccache cc can be the reason? Or is there another reason? Your package build-depends on ccache, and it actively enforces it in the debian/rules file. Why is that? I would be willing to bet money that the problem is that buildd's have no (writable) home directory, so ccache fails. Drop the ccache stuff, or if it _absolutely_ necessary, setup a bogus $HOME so that ccache can work in the buildds. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: gem (updated package) [3rd try]
On Thu, 2009-11-26 at 22:24 +0100, IOhannes m zmölnig wrote: i'm wondering what would be the best way to keep it maintained in debian. should i try and join the multimedia team? should i try and nag the old maintainer (günter geiger) to sponsor the package? You are more than welcome to join the pkg-multimedia project (which is the alioth group name). However, there is a bit of a shortage of DD manpower there too, so you may want to start by introducing yourself and seeing the reactions on the list. It does happen for some packages to be ready but not uploaded yet because no DD is currently available in the team :(. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: checkinstall (fixes RC bug)
Dear mentors, I am looking for a sponsor for the new version 1.6.1-10 of my package checkinstall. It builds these binary packages: checkinstall - installation tracker The package is lintian clean, and fixes the FTBFS with newer glibc. The upload would fix these bugs: 552860, 556725 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/checkinstall - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/checkinstall/checkinstall_1.6.1-10.dsc I would be glad if someone uploaded this package for me. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: checkinstall (fixes RC bug)
Charles Plessy wrote: Le Sun, Nov 22, 2009 at 09:21:44PM -0300, Felipe Sateler a écrit : The upload would fix these bugs: 552860, 556725 Dear Felipe, I have uploaded the package. Thanks! By the way, have you considered appliying as a DM to upload it independantly? Judging by your changelog, you have a good track record… I hadn't really thought of it. Checkinstall is small and requires little maintainance, and the rest of my packages are team maintained so that it is not usually a problem. I am in the NM process, so this looks like little overhead for a good gain :). Another question I have is the upstream status of checkinstall. There are no commits anymore in the Upstream git repository since November 2008. As a consequence, your package is accumulating a lot of patches. Has Upstream completely abandonned development and maintainance ? In the worse case, maybe you can consult with the maintainers of the checkinstall packages of the other distributions (the command ‘whohas’ will help you to find them). Not really. The upstream maintainer has been sort of MIA in the past year, but most of the patches in the debian package are already in the upstream git repository (and he usually accepts proposed patches). Although I have not really been involved with upstream so I haven't pushed him to release or anything. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing manpages
Ben Finney wrote: The Fungi fu...@yuggoth.org writes: I, too, had resolved recently to start maintaining all my project documentation in reST. Not that I find building/editing manpages directly in vi to be that hard, but it's still laborious and time-consuming. I'll be happy to contribute fixes to this for any bugs I find. Thanks for the rcommendation! Great. Both I and the upstream author are not supremely familiar with proper *roff markup and the nuances of manpage rendering, so reasoned suggestions for improvement are definitely welcome. I'm also looking for a new sponsor for the ‘rst2man’ package (though there's currently nothing waiting for upload), so if anyone wants to step up for that, please feel free to get in touch. Rogério Brito rbr...@ime.usp.br writes: Well, it seems that we have two strong contenders: POD and reST. Things look brighter for a more documented Debian. :-) Now if only we can convince more package maintainers. Hopefully the ability to use these source formats, with steady evangelisation about the available rendering tools, can lower the resistance to following policy on providing manpages for all commands. I would say a wishlist bug against dh-make that includes a reST remplate for manpages would be good. Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: Algoscore
On Tue, 2009-11-03 at 19:14 -0300, Felipe Sateler wrote: On Tue, 2009-11-03 at 20:38 +0100, Matthias Klumpp wrote: Dear mentors, I am looking for a sponsor for my package algoscore. Some comments, I'm no DD so I can't upload. * liblo-dev exists currently only in experimental. liblo0-dev, on the other hand (the old package) is for version 0.23. I think you can only upload to experimental currently. Duh, I somehow overlooked the fact that it is targeted there. No problems here, then. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: Algoscore
On Tue, 2009-11-03 at 20:38 +0100, Matthias Klumpp wrote: Dear mentors, I am looking for a sponsor for my package algoscore. Some comments, I'm no DD so I can't upload. * liblo-dev exists currently only in experimental. liblo0-dev, on the other hand (the old package) is for version 0.23. I think you can only upload to experimental currently. * You need to build-depend on libsndfile1-dev * No need to depend on csound, you don't use it at build time (and at runtime? maybe only the library). * Your standards-version is not uptodate. * There are a bunch of unneeded links. You should try building with --as-needed. * The version should probably be prefixed with 0.0 or something in case upstream wants to change versioning scheme in the future. * The examples should be under /usr/share/doc/algoscore, not /usr/share/algoscore. The same for the help files. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: qutecsound (updated package)
Dear mentors, I am looking for a sponsor for the new (upstream) version 0.4.3-1 of my package qutecsound. It builds these binary packages: qutecsound - frontend for the csound sound processor The package is lintian -iI clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0.4.3-1.dsc I would be glad if someone uploaded this package for me. -- Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, 2009-10-20 at 20:48 +1100, Ben Finney wrote: Howdy all, I recall this discussion occurring a few times, but I'm not sure of the recommended best practice. We can all agree that “convenience copies” of third-party library code are to be avoided, and to work with upstream to remove them where feasible. What I'm not clear on are the details of dealing with it in the interim: * Declare dependencies on the version of the library in Debian, even though that version may be later than the convenience copy currently in the original source? Yes, and possibly patch your program to work with the new version. Note that it is a policy 'should', so if that is too hard eventually you could link with the convenience copy while upstream works at it, provided you notify the security team of the fact (and possibly leaving your package out of testing). * Remove the convenience copy from the original source archive, or merely from the binary package? I would say merely from the binary package but... * Document the convenience copy in the dependent package's ‘copyright’, even if it doesn't appear in the binary package? ftpmasters seem to be requiring everything in the source to be documented in debian/copyright (really annoying, I know). If the library copied is large enough, it might be easier to repack instead of documenting it. Specially if it is not the same version as the package in Debian. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Convenience copies in upstream code: dependencies, removal, copyright, and other issues
On Tue, 2009-10-20 at 12:05 -0700, Don Armstrong wrote: On Tue, 20 Oct 2009, Felipe Sateler wrote: ftpmasters seem to be requiring everything in the source to be documented in debian/copyright (really annoying, I know). This is because we don't only distribute the binaries; we also distribute the source. But the upstream source already has them (in the source files themselves or other files). The copyright file is for installation in the binary packages (as per my reading of policy 12.5). ftpmaster has to check all of this out anyway, and it makes it much easier on them if you've documented it properly. I don't see how including that info saves work for them since they check it anyways. It's probably only confusing if different than what is in the source. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Using symbols files for C++ libraries?
Is there a way to do that without going insane? Some sort of wildcards or shortcuts to the mangled symbols would be great (specially since it seems the mangling is different on different archs). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qemu-kvm (kvm)
On Fri, 2009-10-16 at 21:36 +0200, Giuseppe Iuculano wrote: Michael Tokarev ha scritto: You are trying to hijack kvm, this is not the way to do it appropriately. I'm trying to make it to work. And to my shame, I don't know how to do that in another way. I already support debian users by maintaining the package out of debian. Simply you can't. You can't take over a package that you feel is neglected without the assent of the current maintainer. That is not true. That is precisely the point of a hijacking. The maintainer has been unresponsive for half a year according to Michael, so it is perfectly reasonable to attempt a hijack (even if it was not correctly done). -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Building pdf from odt files noninteractively?
I have a source package that has pdf documentation, which is generated with openoffice.org. Is it possible to generate said pdf without user interacion (that is, for autobuilding in the buildds)? Or maybe I can just ship the also-included pdf files? AFAICS, the license is not violated. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Building pdf from odt files noninteractively?
On Fri, 2009-10-16 at 17:31 -0300, Felipe Sateler wrote: I have a source package that has pdf documentation, which is generated with openoffice.org. Is it possible to generate said pdf without user interacion (that is, for autobuilding in the buildds)? Or maybe I can just ship the also-included pdf files? AFAICS, the license is not violated. The license is GPL, I forgot to add. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Realloc is blocking execution
On Wed, 2009-10-14 at 01:40 +0200, Mats Erik Andersson wrote: Dear Mentors, in my efforts to reintroduce the package windowlab-1.37, I am facing the unexpected fact that realloc() is repeatedly blocking execution, when I compile the package on a Debian Lenny system. This blocking does not happen in Debian Etch, nor in OpenBSD, nor FreeBSD. After getting the upstream author to accept my patches for the old package windowlab-1.34, it is only this issue with realloc() that prevents me from submitting the package to mentors.debian.net. Is this unavoidable fact that realloc() blocks execution a known issue with gcc-4.3.2 or glibc-2.7? Personally, I was under the impression that malloc/realloc never should block execution, but would instead return NULL. That Etch and Lenny behave oppositely disturbs me very much. I've always assumed that malloc (and thus realloc) can sleep. Why is it so important to not sleep? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Autotools (library + binary) to debian packages
On Mon, 2009-10-12 at 14:47 +0900, Charles Plessy wrote: Le Sun, Oct 11, 2009 at 06:25:12PM -0500, Jonathan Nieder a écrit : If the libfoo-dev is _very_ small and feels silly as a separate package, you can include its files in libfoo0 and make that Provides: libfoo-dev, but what does this win you? Problems with multi-arch ? http://lists.debian.org/debian-devel/2009/07/msg00861.html And not even with multiarch. It breaks smooth transitions of libraries. Since the include files and friends are not ABI-versioned, you will not be able to install libfoo0 and libfoo1 at the same time (you need appropriate conflicts and replaces), thus defeating the purpose of ABI versioning in the package name. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: script-with-language-extension
On Mon, 2009-10-05 at 13:12 +1100, Matthew Palmer wrote: On Mon, Oct 05, 2009 at 03:43:22AM +0200, Jarom?r Mike? wrote: Od: Jarom?r Mike? mira.mi...@seznam.cz JM I did it, but it breaks functionality ... there exist also symlinks with JM same name and in same location. JM usr/bin/lv2rack JM usr/bin/zynjacku JM usr/bin/zynspect JM -- JM usr/bin/lv2rack.py JM usr/bin/zynjacku.py JM usr/bin/zynspect.py CLJ Hmmm what about remove these symlink first and then remove suffix? CLJ I am going to try it. CLJ How about just mv /usr/bin/lv2rack.py /usr/bin/lv2rack and so on? JM nice solution ... but there is anyway something broken. JM This package actually contains two commands you can call from CLI zynjacku and JM lv2rack. JM When I remove .py suffixes lv2rack stop works ... zynjacku is fine. JM Without removing .py suffixes both work fine. JM I have to investigate it more. BTW: error message for lv2rack is: --- $ lv2rack Traceback (most recent call last): File /usr/bin/lv2rack, line 52, in module import zynjacku as zynjacku -- So someone's using a single file as both a library and a stand-alone program. Damned silly idea. Stick zynjacku.py in a proper library path somewhere, and write a little shim wrapper to stick in /usr/bin that calls zynjacku as it expects to be called. Involving upstream is always a good idea in these cases, since you will be creating a divergence from pristine upstream source. Also, isn't it possible to install zynjacku.py in site-packages (before calling dh_pysupport, of course) and symlinking it from /usr/bin possible too? -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: what to do when upstream package is shipped with MB of dependencies?
Jérémy Lal wrote: I'm in a situation where upstream tarball is not very nice; e.g. it's shipped with 3MB of dependencies, most of which are already packaged. I suppose a patch has no meaning here, since it consists in removing the dependencies from the tarball. Another patch consists in correcting the makefile to use already installed libraries instead of rebuilding them. That one could be meaningfull. Is doing a get-orig-source taking care of cleaning up upstream a good solution ? You *really* should to use the system ones, patch the build system if needed. Removing the libraries is not needed, you may want to do it anyways as a service to others. If some dependencies are not packaged yet, you should package them separately before and then package the software you want. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Test of a package on a specific architecture
Laurent Guignard wrote: Hi mentors, On my package, dhcp-probe, i have a problem on 64 bits architectures (amd64 for the bug report). I built a patch with help of Ilkka Virta and i have not any 64 bits host to test the patch. How to test a package 64 bits on a 32 bits host ? If it is impossible, where can i test my package before submit it for upload ? Is there any machine where i can logon freely and test my package (i am not Debian Developer nor Debian Maintainer) ? It is always possible to ask the bug submitter to try it out. Another option is to create a virtual machine with qemu or VirtualBox. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to detect 32 or 64 bit at build time?
Laurent Guignard wrote: On Tue, 08 Sep 2009 00:05:55 -0400, Felipe Sateler wrote: Sven Joachim wrote: On 2009-09-07 12:54 +0200, Sven Joachim wrote: How about DEB_HOST_ARCH_BITS? This needs dpkg 1.15.4, though. Sorry, that should have been DEB_BUILD_ARCH_BITS. As Neil would have pointed out if he were still subscribed to -mentors, DEB_BUILD_* is almost always the wrong choice, otherwise it will cross-build incorrectly. -- Felipe Sateler Is there any documentation about this ? Why is it a wrong choice when you want to create a package from sources for a specific architecture ? Because you want the package to build for the architecture you plan to run it in. Cross compilation means compiling in one architecture for another. A common case is using an amd64 machine to build arm binaries, because amd64 is so much faster. If you use DEB_BUILD_*, you would are detecting on the amd64 host, instead of the arm you really want, which you would get with DEB_HOST_*. In this case, if you look for DEB_BUILD_*, and the package was being cross- compiled from amd64 to i386, it would get ARB_64=1 instead of ARB_64=0. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How to detect 32 or 64 bit at build time?
Sven Joachim wrote: On 2009-09-07 12:54 +0200, Sven Joachim wrote: How about DEB_HOST_ARCH_BITS? This needs dpkg 1.15.4, though. Sorry, that should have been DEB_BUILD_ARCH_BITS. As Neil would have pointed out if he were still subscribed to -mentors, DEB_BUILD_* is almost always the wrong choice, otherwise it will cross-build incorrectly. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: soundconverter: want to help, can't contact maintainer
Jason Heeris wrote: But all of this hard work only makes sense if the maintainance problem of soundconverter is solved in the long term. Maybe you can see if a packaging team, for instance http://wiki.debian.org/DebianMultimedia, would like to adopt it, with you as a maintainer if you would like, of course. That's something I hadn't thought of. Should it be under MM or GNOME, though? The multimedia team is generally understaffed, and finding a sponsor within it can be troublesome. From the FAQ: 2.1. I have packaged new software. Can you upload it for me? In general, we of course care for new multimedia packages. However we cannot sponsor packages on a regular basis. Please see DebianMentorsNet for a service aiming at this. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Any efficient way to specify target arches?
Rogério Brito wrote: Hi there. Just a quick question: how does one would specify that a given package should be compiled in all but a small set of arches? Of course, I could list all the supported arches (instead of any), but this has an annoying drawback: arches change names (e.g., arm), new arches are included (avr32), etc. I have one package that is primarily intended for Linux arches and, thus, I would like to specify something like: Architectures: all [! kfreebsd-i386, ! kfreebsd-amd64, ! hurd-i386] but I suppose that that's not really allowed (is it?). I just read the policy, but this wasn't addressed there. I don't think there is a general way to do this, but for your particular case (restricting to linux), you can use Architecture: linux-any I don't remember if dak accepts it, though. It's worth trying. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: burn 0.4.3-2.2 (Lenny security bug fixes)
Ben Finney wrote: Felipe Sateler fsate...@gmail.com writes: I believe packages with updates to stable debian releases are versioned version-revision+lenny1 or something like that. Felipe Sateler fsate...@gmail.com writes: BTW, I know this is not a hard requirement, but it is to easily detect stable updates. Okay. Given that the release team has approved a specific set of changes that includes the package release version string, would I need to seek approval again when changing that string? I'm not sure, but I would think not. After all, the change is irrelevant to the software functionality. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: burn 0.4.3-2.2 (Lenny security bug fixes)
Ben Finney wrote: Howdy mentors, I am looking for a sponsor for the new release 0.4.3-2.2 of my package ‘burn’ in Lenny. I believe packages with updates to stable debian releases are versioned version-revision+lenny1 or something like that. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: burn 0.4.3-2.2 (Lenny security bug fixes)
Felipe Sateler wrote: Ben Finney wrote: Howdy mentors, I am looking for a sponsor for the new release 0.4.3-2.2 of my package ‘burn’ in Lenny. I believe packages with updates to stable debian releases are versioned version-revision+lenny1 or something like that. BTW, I know this is not a hard requirement, but it is to easily detect stable updates. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qutecsound (2nd try)
El lunes 15 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 14:29, Felipe Satelerfsate...@gmail.com wrote: El domingo 14 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 11:37, Felipe Satelerfsate...@gmail.com wrote: El sábado 13 de junio, LI Daobing escribió: Hello, On Sat, Jun 13, 2009 at 16:15, LI Daobinglidaob...@debian.org wrote: Hello, On Sat, Jun 13, 2009 at 11:58, Felipe Satelerfsate...@gmail.com wrote: This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound _0. 4-1 .dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. I'll take a look. failed to build from source. build log in attachment. This failure is caused by using gcc 4.4 instead of 4.3. Upstream knew about it already, so I took the patch from their svn. Please see an updated package in mentors. comments: 1. E: qutecsound: menu-icon-too-big /usr/share/pixmaps/qtcs.xpm: 128x128 32x32 Duh, I forgot to change the .install file when I created the smaller icon. 2. debian/copyright: following paragraph is incorrect: On Debian systems, the complete text of the GNU General Public License version 3 can be found in `/usr/share/common-licenses/LGPL-2.1'. Fixed as well. New package uploaded to mentors. uploaded. Thanks! Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: RFS: qutecsound (2nd try)
El domingo 14 de junio, LI Daobing escribió: Hello, On Sun, Jun 14, 2009 at 11:37, Felipe Satelerfsate...@gmail.com wrote: El sábado 13 de junio, LI Daobing escribió: Hello, On Sat, Jun 13, 2009 at 16:15, LI Daobinglidaob...@debian.org wrote: Hello, On Sat, Jun 13, 2009 at 11:58, Felipe Satelerfsate...@gmail.com wrote: This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0. 4-1 .dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. I'll take a look. failed to build from source. build log in attachment. This failure is caused by using gcc 4.4 instead of 4.3. Upstream knew about it already, so I took the patch from their svn. Please see an updated package in mentors. comments: 1. E: qutecsound: menu-icon-too-big /usr/share/pixmaps/qtcs.xpm: 128x128 32x32 Duh, I forgot to change the .install file when I created the smaller icon. 2. debian/copyright: following paragraph is incorrect: On Debian systems, the complete text of the GNU General Public License version 3 can be found in `/usr/share/common-licenses/LGPL-2.1'. Fixed as well. New package uploaded to mentors. Thanks for reviewing. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: RFS: qutecsound (2nd try)
El sábado 13 de junio, LI Daobing escribió: Hello, On Sat, Jun 13, 2009 at 16:15, LI Daobinglidaob...@debian.org wrote: Hello, On Sat, Jun 13, 2009 at 11:58, Felipe Satelerfsate...@gmail.com wrote: This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0.4-1 .dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. I'll take a look. failed to build from source. build log in attachment. This failure is caused by using gcc 4.4 instead of 4.3. Upstream knew about it already, so I took the patch from their svn. Please see an updated package in mentors. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: RFS: qutecsound (2nd try)
This package has been updated, it now sets the default html for the csound ^path manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0.4-1.dsc I would be glad if someone uploaded this package for me. Ping? This application is very important for csound users, because it provides a great frontend for it. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Packaging:library packaging stuff
Adrian von Bidder wrote: * How do I pass the right linker flags (-Wl,--as-needed?) through cmake to= =20 the linker? Whatever I tried so far, it was ignored and I get a few=20 warnings from dpkg-shlibdeps. (This is more a question of style, since=20 they're libraries I'd expect a KDE user has installed in any case.) -DCMAKE_LD_FLAGS=-Wl,--as-needed -Wl,-z,defs. Unless you know what you are doing, don't pass --as-needed with out --no-undefined. Ok. Wasn't there some debconf talk some time ago about --as-needed? Slides or other paper available? I think the section in libpkg-guide about this issue is a bit short (I'll try to imrpove that section and at least put ion the hint about using --no-undefined) Note that the --no-undefined flag can break builds if you have plugins that expect to use symbols from the binary they are loaded from. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: packaging using cmake using external modules
Gerber van der Graaf wrote: Hi, I am working on the DEB packaging of FreeFOAM (http://freefoam.wiki.sourceforge.net/) that uses the CMake building system. In order to build some tools for making the output readable in Paraview, it uses find_package () which searches for a complete building tree of Paraview which also includes ParaViewConfig.cmake. Paraview is available in Debian, but does not provide ParaViewConfig.cmake. Manually building of the Paraview modules in FreeFOAM by pointing to the build tree of Paraview works fine. But in order to get DEB packages of FreeFOAM, the building will also have to be done automatically, under pbuilder for example. How to deal with this? I already have reported a bug against paraview to include ParaViewConfig.cmake, but wonder if that will do the trick. If ParaViewConfig requires the build tree to successfully report the parameters to cmake, then it is broken. Such modules should require an _installed_ package, not a build tree. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: qutecsound (2nd try)
This package has been updated, it now sets the default html for the csound manual currently in NEW. I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Swig and Java bindings packaging
Dmitrijs Ledkovs wrote: I'm maintaining a C++ library. They have SWIG (python) and Java (dunno how) bindings which are not packaged right now. I would greatly appreciate if someone can point out good examples of packaged python-swig and / or Java bindings for libraries? I'm a bit stuck cause the bindings are not integrated into autofoo build system (it's not just additional flag to configure) and i struggling to get my head around how to link against a library which has just been build and not yet installed. SWIG is an interface generator for C++ into several languages. So probably both interfaces in your program are SWIG-based. If the interfaces are not hooked into the package build system, then you will probably have to invoke swig directly to generate them. My package csound uses SWIG to generate Java, Python and Lua bindings. It uses scons, however. What package is this? -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Swig and Java bindings packaging
(please don't cc me) Dmitrijs Ledkovs wrote: 2009/5/22 Felipe Sateler fsate...@gmail.com: Dmitrijs Ledkovs wrote: I'm maintaining a C++ library. They have SWIG (python) and Java (dunno how) bindings which are not packaged right now. I would greatly appreciate if someone can point out good examples of packaged python-swig and / or Java bindings for libraries? I'm a bit stuck cause the bindings are not integrated into autofoo build system (it's not just additional flag to configure) and i struggling to get my head around how to link against a library which has just been build and not yet installed. SWIG is an interface generator for C++ into several languages. So probably both interfaces in your program are SWIG-based. If the interfaces are not hooked into the package build system, then you will probably have to invoke swig directly to generate them. My package csound uses SWIG to generate Java, Python and Lua bindings. It uses scons, however. What package is this? -- Felipe Sateler It's libsword7 (currently only in experimental) Hmm, I can't figure out what upstream was doing with the build system for the bindings. I think you should contact them and ask about the correct way to build the bindings. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: #456356 should really be considered a bug?
William Vera wrote: Or, it's worth having open after all this time? If it was worth having open at some point, then probably yes. Is only a question: The bug has already opened some time, upstream does not answer the mail that I sent him and coldly watching this bug can resolve this in several ways. You could patch the source. We can set off the beep on X session only: 'xset -b' and launch the script to run scrot each minute to make a screenshot (for example), also we can set off the beep with: 'set bell-style none' for all sessions, or just unload the 'pcspkr' module Then believe that it should remain open? Maybe the user wants the beep for some other reason, but doesn't want scrot to beep. It is still a valid request, I think. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dash and dot in package version
Ludovico Cavedon wrote: Hi, I could not find exactly how - and . are ordered in package names. Are they equivalent, counting as non-digits? My actual problem is: -current version of qutecom is 2.2~rc3.dfsg1 -as per lintian warning, the next version will be +dfsg1 instead of .dfsg1 -latest upstream version is still 2.2~rc3, but I would like to upload a more recent snapshot from upstream hg. What would be the correct packager version? - 2.2~rc3+hg365+dfsg1, being lucky that +hg comes after +dfsg - 2.2~rc3-hg365+dfsg1, but would have the - any drawback I do not see? When adding a dfsg or whatever suffix, always use ~ to avoid problems like the one Jan pointed out. So your version would be 2.2~rc3~dfsg1, and then you bump to 2.2~rc3+hg123~dfsg1. I think you should use 2.2~rc3.hg123~dfsg1 for now, and when 2.2 is released you go to 2.2.0~dfsg1 (the .0 is needed because dfsg sorts before rc3). -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dash and dot in package version
Ludovico Cavedon wrote: On Sat, May 16, 2009 at 4:08 PM, Ludovico Cavedon ludovico.cave...@gmail.com wrote: On Sat, May 16, 2009 at 3:14 PM, Magnus Holmgren holmg...@debian.org wrote: On lördagen den 16 maj 2009, Felipe Sateler wrote: When adding a dfsg or whatever suffix, always use ~ to avoid problems like the one Jan pointed out. So your version would be 2.2~rc3~dfsg1, and then you bump to 2.2~rc3+hg123~dfsg1. However, that won't work if you have already uploaded e.g. version 1.2-3 of a package, and then somebody files a bug that the tarball contains some non-free file, and you'd like to upload 1.2~dfsg-1 to fix it without waiting for a new upstream release. Yes, I agree with that (and also with http://lintian.debian.org/tags/dfsg-version-with-period.html). dfsg it is something that comes *after* the upstream release. I mean: repackaging for dfsg compliance is something that comes after the upstream release, so +dfsg1 is the right one. My problem is how to deal with hg375 in combination with +dfsg1. Of course, you can always do 2.2~rc3+dfsg1+hg375 (a bit uglier, but works). Thanks, Ludovivo -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: qutecsound
Dear mentors, I am looking for a sponsor for my package qutecsound. * Package name: qutecsound Version : 0.4.1-1 Upstream Author : Andrés Cabrera mantaray...@gmail.com * URL : http://sourceforge.net/projects/qutecsound * License : LGPL-2.1 Section : sound It builds these binary packages: qutecsound - frontend for the csound sound processor The package appears to be lintian clean. The upload would fix these bugs: 511631 QuteCsound is a simple cross platform editor and front-end for Csound with syntax highlighting, interactive help and automatic launching of Csound. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qutecsound - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qutecsound/qutecsound_0.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upload just to fix a watch file?
Ben Finney wrote: Andrea Bolognani e...@kiyuko.org writes: Since the upstream website has been redesigned, the watch file for one of my packages[1] has stopped working. Which leaves your package with a new bug: a ‘debian/watch’ file that no longer works. Right? The fix is a trivial one-line patch, so I was wondering if such a minor change could warrant a new upload. Many critical security bug fixes are trivial one-line patches. Why would the size of the patch be a factor in whether you should make a new release? Yes, certainly fixing any bug (even one not yet reported) is enough justification for making a new release. No. The cost of wasting buildd and user time has to be factored in. Not any bug is worth of making a new release for. -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: lbzip2
Paul Wise wrote: It seems awkward to me to generate debugging symbols and then strip them. Is there a reason to include debugging symbols per default? It can eat up a lot of disk space (and thus buffer cache) for huge projects. Also, -O0 is gcc's default, AFAIK. Can you please explain the reason for these rules?(I'll accept that's the way we do it in Debian too.) I created the flags stuff in debian/rules so that the behavior matches the Policy Manual, 4.9.1 debian/rules and DEB_BUILD_OPTIONS; all eight variations of The reason is that's the way we do it in Debian. The policy manual probably has a rationale. There is no reason to generate debugging symbols and then strip them. However, usually programs will build unstripped binaries which can be unstripped afterwards (eg, via dh_strip) to avoid patching upstream's makefiles or having to pass special arguments to gcc via make variables. Also, it eases the implementation of nostrip (for free if you use dh_strip) and the generation of -dbg packages (dh_strip manages this automatically via the right arguments). -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Different behaviour of dpkg-buildpackage and pbuilder
Gudjon I. Gudjonsson wrote: Hi I do have a problem with the debian packaging tools but I don't know how to debug it. When I build one of my packages using dpkg-buildpackage or ./debian/rules binary the library files are installed into debian/tmp/usr/lib/tcltk/spice But if I use pdebuild, the same files are installed into debian/tmp/usr/share/tcltk/spice How can there possibly be this difference between these two tools? I don't know why they can differ but maybe you can work around this bug by just specifying --libdir and/or --datarootdir to configure to force a behaviour? -- Felipe Sateler -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libmsn
Pau Garcia i Quiles wrote: Please note I did not just unpackage and repackage it again but I also renamed the directory from 4.0-beta1 to 4.0~beta1 because: $ dpkg --compare-versions 4.0-beta1 gt 4.0; echo $? 0 $ dpkg --compare-versions 4.0~beta1 gt 4.0; echo $? 1 Should I rename the directory in the .orig.tar and make tamper-checking more difficult, or not rename the directory in the .orig.tar and make tamper-checking easier? Don't rename. dpkg-source takes care of that. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: airoscript
Daniel Moerner wrote: Incidentally, this makefile seems to have some problems with it (it has an empty clean: target, and no .PHONY even though some rules don't create files with their names, like the clean: target). And why would that be a problem? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: airoscript
Daniel Moerner wrote: On Thu, Oct 9, 2008 at 10:24 PM, Felipe Sateler [EMAIL PROTECTED] wrote: Daniel Moerner wrote: Incidentally, this makefile seems to have some problems with it (it has an empty clean: target, and no .PHONY even though some rules don't create files with their names, like the clean: target). And why would that be a problem? I was under the impression that it's always good practice to have a .PHONY target in case there accidentally happens to be a file with the name of a target, like clean, in the working directory. Ah, that seems sensible (although I'd argue that a file called 'clean' in a source tarball is broken). Reading the make info page I find that if you define the targets as .PHONY, then it can optimize a bit, so if your Makefile is large you could get some speed improvement. As far as an empty clean target in the Makefile goes, if you're adding a Makefile to the .diff.gz, and you have the choice to call make clean or not call it in debian/rules, it just seems like extraneous cruft to include a makefile with a clean target that does nothing just so you can run make clean in debian/rules. I was asking about the .PHONY issue. I agree with this point. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the best method to update only some binary packages
Osamu Aoki wrote: Hi, Suppose source foo_1.0.tar.gz produces: foo-updated_1.0_all.deb foo-static_1.0_all.deb Then with next source foo_1.1.tar.gz with updated contents will produce now with normal build script: foo-updated_1.1_all.deb (updated from foo-updated_1.0_all.deb) foo-static_1.1_all.deb (same as foo-static_1.0_all.deb) Then What is the best way to make update archive to have: foo-updated_1.1_all.deb foo-static_1.0_all.deb This way user will not be forced to download same package again. Any suggestion for debian/rules ? or pointer to good example. You can't really do this, AFAIK. You can break the source into 2 separate source packages that each build one package. That way you only update the foo-updated package. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the best method to update only some binary packages
El 02/10/08 12:51 Osamu Aoki escribió: On Thu, Oct 02, 2008 at 12:10:16PM -0400, Felipe Sateler wrote: Osamu Aoki wrote: Any suggestion for debian/rules ? or pointer to good example. You can't really do this, AFAIK. You can break the source into 2 separate source packages that each build one package. That way you only update the foo-updated package. from maint-guide: # dh_gencontrol # up to date versions, using the default value of 1.2* in debian/changelog: DH_OPTIONS=-p$(name) dh_gencontrol DH_OPTIONS=-p$(name)-fr dh_gencontrol DH_OPTIONS=-p$(name)-ja dh_gencontrol DH_OPTIONS=-p$(name)-pl dh_gencontrol DH_OPTIONS=-p$(name)-it dh_gencontrol DH_OPTIONS=-p$(name)-zh dh_gencontrol DH_OPTIONS=-p$(name)-ko dh_gencontrol DH_OPTIONS=-p$(name)-de dh_gencontrol DH_OPTIONS=-p$(name)-es dh_gencontrol DH_OPTIONS=-p$(name)-pt dh_gencontrol DH_OPTIONS=-p$(name)-ru dh_gencontrol # out of date versions: # If no change from old version, # upload with the same version to prevent updating. #DH_OPTIONS=-p$(name)-XX -u-v1.X.Y-Z dh_gencontrol Will dak accept such a package? I doubt so. Saludos, Felipe Sateler signature.asc Description: This is a digitally signed message part.
Re: Building package,
Luca Bruno wrote: On Thu, Oct 02, 2008 at 03:03:40PM -0500, =?ISO-8859-1?Q?El=EDas_A._M._ wrote: Hi, Hi I'm not a developer but I try to suggest you. Somebody know why when I build the package, show me: dpkg-shlibdeps: warning: debian/pack/usr/games/pack shouldn't be linked with libpthread.so.0 (it uses none of its symbols). Your package is linking against libpthread and it might not be used. If your program uses it, then ignore the warning. If your program doesn't really use it, add --as-needed in the LDFLAGS in your debian/rules. When (for some reason) -pthread is passed to gcc, the -Wl,--as-needed flag won't unlink it (newlines added for clarity): % gcc -o test test.c % objdump -p test | grep NEEDED NEEDED libc.so.6 % gcc -pthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % gcc -lpthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % gcc -Wl,--as-needed -lpthread -o test test.c % objdump -p test | grep NEEDED NEEDED libc.so.6 % gcc -Wl,--as-needed -pthread -o test test.c % objdump -p test | grep NEEDED NEEDED libpthread.so.0 NEEDED libc.so.6 % -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Determining native or non-native package inside pbuilder
Ben Finney wrote: Paul Wise [EMAIL PROTECTED] writes: On Sun, Sep 7, 2008 at 3:33 PM, Ben Finney [EMAIL PROTECTED] wrote: Paul Wise [EMAIL PROTECTED] writes: Usually this warning is produced because of an incorrectly named orig.tar.gz - foo-1.2.orig.tar.gz (bad) vs foo_1.2.orig.tar.gz (good). Perhaps that is the issue? Perhaps. But as far as I know, I have no control over the name of the tarball; it's generated automatically as part of 'pdebuild'. What do I need to do so that the correct tarball name (i.e. correctly indicating native or non-native) is used when I run 'pdebuild'? A native tar.gz (rather than a non-native orig.tar.gz) is only generated automatically when you don't have an orig.tar.gz file. I suggest removing all tar.gz files below your source directory and doing something like this in the source directory: wget -O ../foo_1.2.3.orig.tar.gz http://foo.bar.com/foo-1.2.3.tar.gz Should I expect it to be found at '../tarballs/foo_1.2.3.orig.tar.gz'? That's where 'dpkg-buildpackage' and other tools seem to expect it. dpkg-buildpackage expects it to be in ../foo_*. svn-buildpackage is the only one that uses ../tarballs AFAIK. Is 'pbuilder' different in this regard? I'd rather not have the same file needing to appear at multiple places just to get the Debian tools working in concert. pbuilder requires whatever you use as a builder. The default is dpkg-buildpackage, so it will expect the orig in .. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with implicit rule for .o files and overriding of CXXFLAGS.
George Danchev wrote:
On Monday 07 July 2008 16:39:14 Charles Plessy wrote:
Le Sun, Jul 06, 2008 at 09:34:33PM +0300, Yavor Doganov a écrit :
Charles Plessy wrote:
Hello,
When a Debian binary package is built, environment variables such as
{{{CFLAGS}}} and {{{CXXFLAGS}}} are set by {{{dpkg-buildpackage}}}
and may override the corresponding variables in the
{{{Makefile}}}.
The matter is more complex in general; add here the well known fact
that a truckload of upstream makefiles/build systems is broken.
Well, this is why I tried to write something in the wiki page that is
supposed to be something to read for upstream maintainers. But I am not
a C programmer, I do not think I can improve what I wrote any further.
It is not that much related to the C programming language, nor to the GNU
implementation for it (compiler, linker, standard library), nor with any
other GNU programming language implementation (like the ones for C++ or Ada),
it is the GNU build system (autotools, make) which adds the complexity.
FWIW, in this case the problem was clever use of (i think standard) make and
implicit rules. Using the gnu build system would have actually avoided this
issue, as automake puts flags in other variables and doesn't rely on implicit
rules.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with get-orig-source and md5sum
David Paleino wrote: On Fri, 20 Jun 2008 09:29:37 +0200, David Paleino wrote: On Fri, 20 Jun 2008 09:24:09 +0200, David Paleino wrote: On Thu, 19 Jun 2008 20:05:31 -0400, Felipe Sateler wrote: David Paleino wrote: Now, the fact is that the resulting tarball has very different md5sums at each run -- and I found no way to have the same exact md5sum of the .orig.tar.gz that would be uploaded to Debian: [..] I thought that this could be related to timestamps -- but I found no option in `man tar` to remove timestamps from archived files (I thought that, removing timestamps, the files would have been all the same). I can also confirm that the files in the archives are always the same (checked with `tar -tf` and diffing the lists). What can I do here? AFAIK the problem is not tar, but gzip. If I read correctly man gzip, your solution would be to use tar first, and then gzip -9n. -n... I'll try that, thanks :) Great, it worked :) No, it didn't... I md5sum'ed the same file before... :( I'm open to other suggestions, I was thinking a bit about this, and apparently this is a not-so-trivial problem. Maybe you can try pristine-tar which attempts to do this. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with get-orig-source and md5sum
David Paleino wrote:
Hello mentors,
I'm packaging a svn snapshot of a Mono assembly, for which no released tarball
is present.
As per Policy 3.8.0, I wrote in debian/README.Debian-source how to get a
tarball to start the build, i.e. ./debian/rules get-orig-source.
This is my get-orig-source target (please tell me if and how it can be
improved), with some variables defined in the very beginning of the makefile:
---8---
VERSION=$(shell parsechangelog | grep ^Version | awk -F: '{print $$2}' |
cut -d- -f1) REV=$(shell echo $(VERSION) | awk -F~svn '{print $$2}')
GOS_TMP=$(CURDIR)/get-orig-source-tmp
AFAIK, get-orig-source shouldn't rely on other files to do it's job. I have
always hardcoded the version or date to make the checkout from, to ensure that
only debian/rules is used, and that it can be used from anywhere
(eg, ../src/package/debian/rules get-orig-source).
[..]
get-orig-source:
rm -rf $(GOS_TMP) mkdir $(GOS_TMP)
svn co -r $(REV) svn://anonsvn.mono-project.com/source/trunk/Mono.Nat
$(GOS_TMP)/mono-nat-sharp-$(VERSION)
You can use svn export and skip the next instruction.
find $(GOS_TMP)/mono-nat-sharp-$(VERSION)
-name .svn -type d | xargs rm -rf
cd $(GOS_TMP) tar zcf
mono-nat-sharp_$(VERSION).orig.tar.gz mono-nat-sharp-$(VERSION)/ mv
$(GOS_TMP)/mono-nat-sharp_$(VERSION).orig.tar.gz $(CURDIR)/../ rm -rf
$(GOS_TMP) echo The original source tarball is located at $(CURDIR)/../ .
Policy 4.9 says it should be left at the current directory.
---8---
Now, the fact is that the resulting tarball has very different md5sums at
each run -- and I found no way to have the same exact md5sum of the
.orig.tar.gz that would be uploaded to Debian:
$ date -R
Thu, 19 Jun 2008 23:12:36 +0200
$ debian/rules get-orig-source /dev/null
$ md5sum ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
2826da659bb5a5ab5867c8ca11b6f7fe ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
$ debian/rules get-orig-source /dev/null
$ md5sum ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
54db2bdb1131f7b3e5a1a73d495bd737 ../mono-nat-sharp_0.1~svn106158.orig.tar.gz
$ date -R
Thu, 19 Jun 2008 23:13:06 +0200
$
I thought that this could be related to timestamps -- but I found no option in
`man tar` to remove timestamps from archived files (I thought that, removing
timestamps, the files would have been all the same).
I can also confirm that the files in the archives are always the same (checked
with `tar -tf` and diffing the lists).
What can I do here?
AFAIK the problem is not tar, but gzip. If I read correctly man gzip, your
solution would be to use tar first, and then gzip -9n.
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: On Thu, 2008-05-22 at 01:12 -0400, Felipe Sateler wrote: Hi. Csound, a package I maintain, supports enabling a set of gcc optimizations via a build option. Code generated with those options can be significantly faster (I've seen improvements of over 2x). However, this option means adding a -mtune option to gcc. Obviously, the only sane option for a debian package is -mtune=generic (which is apparently only available on x86 and amd64). However I read in the info pages for gcc: Produce code optimized for the most common IA32/AMD64/EM64T processors. Does this mean that setting -mtune=generic is the same as setting -mtune to the most popular processor? If so, can/should I use that option? Only for the supported architectures or you'll get a build failure on ARM, powerpc, mips, sparc etc. Of course. I already noted that it was only available on x86 and amd64. To check the arch, always test against the HOST architecture. Native builds set HOST == BUILD but if the package is ever cross-built, your debian/rules must allow building an ARM package on amd64 (HOST=ARM, BUILD=amd64) and *NOT* enable -mtune. DEB_HOST_ARCH_CPU=... -qDEB_HOST_ARCH_CPU) This holds true for any architecture-specific checks in any package - always, always check the HOST value - BUILD is almost always the wrong variable to use. I think csound is unlikely to be cross-built. Sound synthesis is a pretty cpu-intensive task. If I enable it then I should only enable it on the appropriate environments. However there is still the question: is it reasonable to enable this option on supported archs? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: On Thu, 2008-05-22 at 12:42 -0400, Felipe Sateler wrote: Neil Williams wrote: To check the arch, always test against the HOST architecture. Native builds set HOST == BUILD but if the package is ever cross-built, your debian/rules must allow building an ARM package on amd64 (HOST=ARM, BUILD=amd64) and *NOT* enable -mtune. DEB_HOST_ARCH_CPU=... -qDEB_HOST_ARCH_CPU) This holds true for any architecture-specific checks in any package - always, always check the HOST value - BUILD is almost always the wrong variable to use. I think csound is unlikely to be cross-built. Sound synthesis is a pretty cpu-intensive task. :-) don't think that cross-building is only for low resource units. I suppose csound may also require a lot of RAM. Not really. It would depend on the use, of course, but normally it doesn't. It is still possible that an arch could be sufficiently powerful to *run* csound but not capable of building gcc for itself. (I would be surprised if running csound is quite as much workload as compiling gcc.) Indeed, running csound is a lot less resource-intensive than compiling a large application (such as csound itself). The problem is that (AFAICS), csound on an emdebian-targeted device will probably be most useful as a realtime sound generator, which is problematic because now you not only have a lot of work to do, but you need to do it fast (or else the sound will clip and stutter). Many pieces fail to run in realtime on fast amd64 machines. If I enable it then I should only enable it on the appropriate environments. However there is still the question: is it reasonable to enable this option on supported archs? Yes. OK then. I will enable it on x86 and amd64. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Compiling with -mtune?
Neil Williams wrote: This holds true for any architecture-specific checks in any package - always, always check the HOST value - BUILD is almost always the wrong variable to use. What if I'm checking for build-dependencies? For example, csound can use alsa, which isn't present on non linux archs. Should I test for HOST or BUILD? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Compiling with -mtune?
Hi. Csound, a package I maintain, supports enabling a set of gcc optimizations via a build option. Code generated with those options can be significantly faster (I've seen improvements of over 2x). However, this option means adding a -mtune option to gcc. Obviously, the only sane option for a debian package is -mtune=generic (which is apparently only available on x86 and amd64). However I read in the info pages for gcc: Produce code optimized for the most common IA32/AMD64/EM64T processors. Does this mean that setting -mtune=generic is the same as setting -mtune to the most popular processor? If so, can/should I use that option? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Felipe Sateler wrote: [some text missing] The thing is you just named 3 cases were they are useful for unrelated reasons (namely, saving mirror space via an arch: all package), while you didn't provide the reason for libtorrent. Maybe I was unclear. What I meant is that perhaps, given that libtorrent is only used by rtorrent, it should be shipped as /usr/lib/rtorrent/libtorrent.so. I don't know if this is possible, but I really do wonder if it useful to install it under /usr/lib/. Because LibTorrent is _not_ part of the rtorrent upstream tarball. Well, there's one reason to ship it separately then :). I thought libtorrent was part of the rtorrent source. They're shipped individually for practical purposes (if someone wants, in some moment, to only use the library and not the client). Besides, there are normally more (a lot more) uploads of libtorrent than rtorrent, most of the changes are made in the library (talking about patches made to upstream and stuff). More reason then to keep them separate. Installing LibTorrent in /usr/lib is as useful as installing it in rtorrent, only that making the last one would imply actually changing the actual scheme. Don't know what for, _really_. There's another reason that just Cause rtorrent is the only one using it right now? (Which, BTW, is not true [1][2][3][4][5] are other examples of software using LibTorrent-Rakshasa) Ok then. I was not aware of that other software. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: Sorry, I don't think that libtorrent-rakshasa is used by only one client is argument enough to get it a name change. I'm wondering if libtorrent-rakshasa even needs a shared library, given that the only person using it is rakshasa. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#402462: Would like libtorrent-rasterbar
Jose Luis Rivas Contreras wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Felipe Sateler wrote: Jose Luis Rivas Contreras wrote: Sorry, I don't think that libtorrent-rakshasa is used by only one client is argument enough to get it a name change. I'm wondering if libtorrent-rakshasa even needs a shared library, given that the only person using it is rakshasa. Ok, lets make things funnier and easier to explain with your same phrase: I'm wondering if $X even needs a $Y, given that the only person/package using it is $Z. Now let's try with: X=zorp-doc;Y=package;Z=zorp X=widelands-data;Y=data package;Z=widelands X=deluge-torrent-common;Y=common package;Z=deluge-torrent Please, don't make me continue :) The thing is you just named 3 cases were they are useful for unrelated reasons (namely, saving mirror space via an arch: all package), while you didn't provide the reason for libtorrent. Maybe I was unclear. What I meant is that perhaps, given that libtorrent is only used by rtorrent, it should be shipped as /usr/lib/rtorrent/libtorrent.so. I don't know if this is possible, but I really do wonder if it useful to install it under /usr/lib/. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: Dear mentors, I am looking for a sponsor for my packages libtorrent-rasterbar and You may want to contact the btg guys. They have been providing deb packages for both btg and libtorrent for a while (I made the first few releases). BTW, embedded code copies are a bad thing. You should try to contact Simon Richter (asio's maintainer) to update debian's asio version. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: On Thu, May 08, 2008 at 01:52:37PM -0400, Felipe Sateler wrote: You may want to contact the btg guys. They have been providing deb packages for both btg and libtorrent for a while (I made the first few releases). Hi Felipe, do you remember me? I wrote you when starting work with this package. Doh, yes. I somehow got confused and thought you were someone completely different. As you suggested me some days ago, I contacted Roman Rybalko, the guy who currently packages libtorrent and btg. He provided me with some advices, and then I looked at your past works on this library. This package is the result of my work merged with yours experience. Oh, ok. But you seem to have started the package from scratch? The changelog at least suggests that. BTW, embedded code copies are a bad thing. You should try to contact Simon Richter (asio's maintainer) to update debian's asio version. The main problem here is that Asio 1.0.0 gets included with Boost 1.35.0, which package is still unreleased and there is a discussion about versioning and problems with probably broken rdepends [1]. Should we consider upgrading Asio to latest version anyway? boost1.35 is already on NEW. But I can't see asio in there. Maybe it's bundled in some package there? http://ftp-master.debian.org/new/boost1.35_1.35.0-1.html -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: libtorrent-rasterbar and qBittorrent
Cristian Greco wrote: boost1.35 is already on NEW. But I can't see asio in there. Maybe it's bundled in some package there? http://ftp-master.debian.org/new/boost1.35_1.35.0-1.html I see the Asio header files are listed in libboost1.35-dev. That package depends on new, versioned, -dev packages and conflicts with libboost-dev. I think libtorrent-rasterbar can then build-depends on libboost1.35-dev and other non-versioned -dev packages from boost 1.34, am I right? I don't think so. Loading more than one version of a library is asking for trouble, I think (although asio is not a library per se, AFAIK). If you build depend on libboost1.35, then I think you should use the other boost libraries at 1.35. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tesseract-ocr: missing-dependency-on-libc
Cyril Brulebois wrote: You could try and use LDFLAGS to pass -Wl,--as-needed (linker flags). But since it could break silently some parts of your build, it shouldn't be used without -Wl,-z,defs which will help spot possible missing -l$foo options in intermediate objects (if any). You can pass LDFLAGS to the ./configure script. Can -Wl,--as-needed really break anything that can be detected by -Wl,-z,defs? As I understood from some discussion at -devel, it can't create problems with C code, it only creates problems on some obscure situations involving C++ constructors/destructors. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote: What would be the best way to keep such a directory in place, but exclude the directory from the Debian source and binary packages? dpkg-source -iregexp? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keep directory in working tree, but exclude from foo.diff.gz
Ben Finney wrote:
Felipe Sateler [EMAIL PROTECTED] writes:
Ben Finney wrote:
What would be the best way to keep such a directory in place, but
exclude the directory from the Debian source and binary packages?
dpkg-source -iregexp?
Thanks. That looks like the right functionality, indeed.
However:
=
$ man dpkg-source
[...]
-i[regexp]
You may specify a perl regular expression to match files
you want filtered out of the list of files for the diff.
[...] There can only be one active regexp, of multiple
-i options only the last one will take effect.
[...]
$ dpkg-source --help
[...]
-i[regexp] filter out files to ignore diffs of
(defaults to:
'(?:^|/).*~$|(?:^|/)\.#.*$|(?:^|/)\..*\.swp$
(?:^|/),,.*(?:$|/.*$)|(?:^|/)(?:DEADJOE|\.cvsignore|\.arch-inventory
\.bzrignore|\.gitignore)$|(?:^|/)(?:CVS|RCS|\.deps|\{arch\}|\.arch-ids|\.svn
\.hg|_darcs|\.git|\.shelf|_MTN|\.bzr(?:\.backup|tags)?)(?:$|/.*$)').
[...]
=
Yikes. So, in order to filter out an additional pattern, I can't just
say ignore this pattern as well as the defaults. I have to construct
a *single* regexp that contains the default pattern *plus* mine, and
forever diverge from any future changes to the default regexp.
Am I reading it wrong, or is this dpkg-source option really that
awful?
Apparently it is. Note though that most of that regex is to match stuff you
won't use (eg, every VCS in common use, you probably use only one).
BTW, why are there files useful to you but not other developers?
--
Felipe Sateler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging without Makefile
Dominik George wrote: Hello mentors, I am just packaging my Pidgin Last.fm Plugin for Debian and am wondering how to get a .changes file. The problem is that the plugin consists of a single perl script which is copied to /usr/lib/pidgin. You may want to consider adding the script to an existing package, such as pidgin-plugin-pack instead of building a package for only a perl script. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: VCS repository on Alioth projects with unrelated packages (was: Proposed new package, bugs-everywhere_0.0.193-1.1)
Ben Finney wrote: Sandro Tosi [EMAIL PROTECTED] writes: If this is as python app (and you'd like to follow this path) It is implemented in Python, and I'm interested in the PAPT; thanks for the invite. the repository it's already on Alioth, and it's called PAPT[1] ;) Unfortunately (as URL:irc://irc.oftc.net/#debian-python made clear in a conversation earlier this evening), the PAPT won't allow packages to use any VCS but their chosen repository, which is currently a Subversion back-end. Since my VCS preference, and that of my upstream, is Bazaar, this makes PAPT more of a burden than I was looking for. Alioth was attractive for this package largely *because* it provides hosted Bazaar repositories. You may want to consider using collab-maint instead of creating a new project. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed for packaging a library
Helmut Grohne wrote: Hi Georgi, Why is my library architecture-dependent? How can I make it architecture-independent, assuming the source code doesn't care about the architecture (I don't think a printf should be a problem)? Your library will be compiled to a binary blob and this binary blob is architecture dependant. But Georgi was asking why the pkgconfig file was arch dependent, not the library. I'd say that in pretty much all non-trivial libraries the pc file is system-dependant, so I would go with /usr/lib by default even if in your case the pkgconfig file is trivial. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install files with debhelper or make install?
Jörg Sommer wrote: Hallo Don, Don Armstrong [EMAIL PROTECTED] wrote: On Sat, 08 Mar 2008, Jörg Sommer wrote: Don Armstrong [EMAIL PROTECTED] wrote: That's why you generally fail your build if there are files in tmp which do not get installed. In which of your packages you do so? All of mine are simple enough not to need it, but --fail-missing is the option to dh_install. But I want to use dh_installman, dh_installexamples and the linke. I don't want to do a big dh_install run. The goal is to use the helper scripts to take the advantage of them. Then use package.manpages, package.examples and the like. What's the problem with that? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Install files with debhelper or make install?
Jörg Sommer wrote: Hi Felipe, Felipe Sateler [EMAIL PROTECTED] wrote: Jörg Sommer wrote: Don Armstrong [EMAIL PROTECTED] wrote: On Sat, 08 Mar 2008, Jörg Sommer wrote: Don Armstrong [EMAIL PROTECTED] wrote: That's why you generally fail your build if there are files in tmp which do not get installed. In which of your packages you do so? All of mine are simple enough not to need it, but --fail-missing is the option to dh_install. But I want to use dh_installman, dh_installexamples and the linke. I don't want to do a big dh_install run. The goal is to use the helper scripts to take the advantage of them. Then use package.manpages, package.examples and the like. What's the problem with that? Does dh_install run dh_installman for the files in dh_install? I didn't know this. I though dh_install installs only the files in package.install. It does. But if you leave the manpage out of package.install, put it in package.manpages and add a call to dh_installman you should have your problem solved. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: parallel building without make
Lucas Nussbaum wrote: On 29/01/08 at 17:23 -0300, Felipe Sateler wrote: Recently dpkg-buildpackage got the option to build in parallel via the -j option. This means that debian/rules is called with that option set, and sets parallel=n in DEB_BUILD_OPTIONS. The problem is that for build systems not using make (eg, scons), this option is not inherited. Of course, one could parse DEB_BUILD_OPTIONS and find if parallel=n is set and then call the build system with the equivalent option. However this means that, although one specified n threads of execution, there can be more than n threads concurrently. Consider this case: build: build-indep build-arch build-arch: scons -j$(NTHREADS) buildProgram build-indep: scons -j$(NTHREADS) buildDocumentation Where NTHREADS is calculated from DEB_BUILD_OPTIONS. If I call dpkg-buildpackage with -j2, I will get build-arch and build-indep running concurrently, which means I will actually get 4 scons threads running instead of the intended 2. What should I do? I see 3 options: 1- Don't use the -j flag in scons 2- Use the -j flag and potentially use more threads than specified 3- Use the -j flag with a lower number (eg, NTHREADS/2). Any opinions? Don't use dpkg-buildpackage -j. Only set DEB_BUILD_OPTIONS=parallel=n, so build-arch and build-indep are not run in parallel, but you still get several scons threads. OK. But it makes me wonder what is the real use for -j in dpkg-buildpackage, then. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
parallel building without make
Recently dpkg-buildpackage got the option to build in parallel via the -j option. This means that debian/rules is called with that option set, and sets parallel=n in DEB_BUILD_OPTIONS. The problem is that for build systems not using make (eg, scons), this option is not inherited. Of course, one could parse DEB_BUILD_OPTIONS and find if parallel=n is set and then call the build system with the equivalent option. However this means that, although one specified n threads of execution, there can be more than n threads concurrently. Consider this case: build: build-indep build-arch build-arch: scons -j$(NTHREADS) buildProgram build-indep: scons -j$(NTHREADS) buildDocumentation Where NTHREADS is calculated from DEB_BUILD_OPTIONS. If I call dpkg-buildpackage with -j2, I will get build-arch and build-indep running concurrently, which means I will actually get 4 scons threads running instead of the intended 2. What should I do? I see 3 options: 1- Don't use the -j flag in scons 2- Use the -j flag and potentially use more threads than specified 3- Use the -j flag with a lower number (eg, NTHREADS/2). Any opinions? -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Using symbols files
David Paleino wrote: Hi all, one of my packages, libopenraw, has just been uploaded to NEW. My sponsor (lucab, thanks Luca!) noted that I should've read [1] and [2], to write proper symbols files. Unfortunately, I've not been able to fully understand how to implement this. Can anyone give some help? That would be appreciated :p The thing is that very few packages are using this right now, and I remember someone asking in debian-devel for early adopters to write a set of guidelines, but nothing has come out yet. I should note that apparently it takes some work to get the new dependencies working, and that currently only packages with *lots* of reverse dependencies (such as glibc) have it implemented. I personally wouldn't bother for a new library. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [pkg-ntp] - where does /etc/default/ntpdate come from?
D. Pathirana wrote: I've been trying to figure out how the installation process of the package ntpdate works. After installation the configuration file /etc/default/ntpdate is created. But: I can not find any evidence of it being used throughout the whole debian directory in the source-package. Actually there IS THE file in debian/ntpdate.default but is never refered in the rules file or elsewhere. I believe it has something to do with .default suffix but I was not able to find any docs about what and how it is going on. So where does the magic happen? man dh_installinit: If a file named debian/package.default exists, then it is installed into etc/default/package in the package build directory, with package replaced by the package name. -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: dblatex (updated package): 2nd try
Leo costela Antunes wrote: Andreas Hoenen wrote: I have just uploaded dblatex 0.2.8-2 to mentors.debian.net [1]. Regarding the new lintian warning 'spelling-error-in-changelog' I have opened a bug report [2]. [1] dget [http://mentors.debian.net/debian/pool/main/d/dblatex/dblatex_0.2.8-2.dsc Now there's just one last minor problem: since you closed some bugs on 0.2.8-1 which never got uploaded, you would have to close them manually as the automatic bug handling wouldn't be triggered for them. This can be triggered with the -v option to dpkg-buildpackage -- Felipe Sateler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
