Where to place man-pages, when building multiple packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! I'm just working on packaging. When I build on source into 2 pkgs. Theese are the two packages: jailkit -- here go all the c-binaries jailkit-common -- here go python-scripts, manpages, other no-arch After building the pkg, lintian complains about binary-without-manpage. So in which pkg should it put the man-pages? Is it possible to tell lintian the man-pages to the binaries are in the - -common pkg? Or must they be put inside the main pkg? Many Thanks to you in advance. BR, Björn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk67ku4ACgkQ3u1SIc8s7PU9EwD/UYKCR4+bOMhTXMByKu+nhUDr h69Vv5dZ0YQTeaWhdQgBANhpbDH2KgrLhmGPQtMW1CY53mplkUW8ue7Qse1Kyao9 =nxAC -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/4ebb92ee.1050...@googlemail.com
Where to place man-pages, when building multiple packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi there! I'm just working on packaging. When I build on source into 2 pkgs. Theese are the two packages: jailkit -- here go all the c-binaries jailkit-common -- here go python-scripts, manpages, other no-arch After building the pkg, lintian complains about binary-without-manpage. So in which pkg should it put the man-pages? Is it possible to tell lintian the man-pages to the binaries are in the - -common pkg? Or must they be put inside the main pkg? Many Thanks to you in advance. BR, Björn -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk67kuUACgkQ3u1SIc8s7PVCvwD/ZpUeOY4RyDJWnF6qYZ/wILNW U8yAtwkrVp//Ewa5zWYBAN+ttR/EctMKSLtZ6pStrsJmfUbZcc4TTSuPMEFcKVOD =hzra -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/4ebb92ee.4020...@googlemail.com
Re: debian/rules override_dh_auto_build-indep
On 2011-11-10 08:20, Mathieu Malaterre wrote: Hi all, Hi I have been trying to split indep operations from the rest on the activiz.net package, see: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup However the -indep rules are still being called on the buildd machine: Eg: http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.netarch=s390xver=5.6.1-2stamp=1320869304 [...] Am I missing something here ? Thanks This is one of the real issue behind the optional build-arch/build-indep targets; since they are optional dpkg-buildpackage/buildds do not use them. Therefore, you cannot rely on them as a maintainer (yet). The purpose of adding the build-arch/build-indep targets is to reduce the number of packages that would be instantly RC-buggy if build-arch and build-indep became mandatory targets[0]. This should remove one of the major blockers for fixing this (in my view) ridiculus behaviour where the Build-Depends-Indep field is completely useless. In your case, it seems to build just fine anyway... If the build-indep does not require huge build-depends[1] or a lot of resources (i.e. memory or build-time)[2], I would personally just merge Build-Depends-Indep into Build-Depends and ignore it for now. The alternative is to do various hoops to conditionally skip build-indep based on installed packages or delay it until binary-arch vs binary/binary-indep is called (in which case you know whether or not to build it). If you want to see an example, I have done the former in libsysactivity. But as may realize, it is a suboptimal trade-off (delays failure on a indep build with missing B-D + plus error message is more or less a red-herring) ~Niels [0] See the proposed build-arch target release goal for more information. :) https://wiki.debian.org/ReleaseGoals/BuildArchTarget [1] For reference graphivz + doxygen appears to be 31.4 MB in my clean amd64 chroot (possibly including packages that would have been pulled anyway by other Build-Depends). [2] You may want to check the buildd logs for some of the slower archs when you make this decision. -- 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/4ebb9887.8030...@thykier.net
Re: Where to place man-pages, when building multiple packages
On 2011-11-10 10:01, Björn Esser wrote: Hi there! Hi, I'm just working on packaging. When I build on source into 2 pkgs. Theese are the two packages: jailkit -- here go all the c-binaries jailkit-common -- here go python-scripts, manpages, other no-arch After building the pkg, lintian complains about binary-without-manpage. So in which pkg should it put the man-pages? Is it possible to tell lintian the man-pages to the binaries are in the -common pkg? Or must they be put inside the main pkg? Many Thanks to you in advance. BR, Björn Newer versions of lintian (around 2.5.1 or so) will check direct dependencies (that are built from the same source) if said dependencies are processed together. So if you placed your manpage correctly in jailkit-common and jailkit depends on jailkit-common, then lintian should find the manpage if you do: lintian jailkit.deb jailkit-common.deb Alternatively you can pass lintian the changes file and it will process both debs automatically as well. ~Niels -- 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/4ebb997d.90...@thykier.net
Re: Where to place man-pages, when building multiple packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Newer versions of lintian (around 2.5.1 or so) will check direct dependencies (that are built from the same source) if said dependencies are processed together. So if you placed your manpage correctly in jailkit-common and jailkit depends on jailkit-common, then lintian should find the manpage if you do: lintian jailkit.deb jailkit-common.deb That's exactly what I'm doing, but lintian complains about missing man-pages in jailkit (main-pkg). Man-pages for all binaries are located under /usr/share/man/man8/ inside the jailkit-common pkg. Alternatively you can pass lintian the changes file and it will process both debs automatically as well. Even here lintian complains about missing manpages in jailkit (main-pkg). So what shall I try to get things fixed? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk67m00ACgkQ3u1SIc8s7PUz9AEA79a6o2xfXLofUgsIyFgqXDam AihYyVSbNU29yNji4NUBAI1wDNmDZ4wS1G41QsSWIrKMfW130AF6qqrv0oH2vUWO =srFw -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/4ebb9b4d.4080...@googlemail.com
Re: Where to place man-pages, when building multiple packages
Hi! Am 10.11.2011 10:37, schrieb Björn Esser: Newer versions of lintian (around 2.5.1 or so) will check direct dependencies (that are built from the same source) if said dependencies are processed together. [..] So what shall I try to get things fixed? What version of lintian are you using? Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebba045.9080...@schmehl.info
Additional lintian warnings in mentors upload
I've noticed that the lintian check on my mentors uploads are a bit more strict than the lintian checks on my PC; for example, lintian on mentors catches version numbering intended for debian native packages. I want to eliminate such warnings and errors before I upload rather than discovering them afterwards. My lintian version is v.2.5.3ubuntu2, so I'm guessing it's been modified for Ubuntu to skip such warnings/errors as the one mentioned above. Will a real (debian) lintian capture such errors/warnings, or do the mentor upload scripts make specific checks that won't be made by any generic lintian package I might find for debian? -- OLE WOLF[1] Rødhættevej 4 * 9400 Nørresundby Telefon: 9632-0108 * Mobil: 2467-5526 * Skype: ole.wolf * SIP: ole.w...@ekiga.net Links: -- [1] http://naturloven.dk smime.p7s Description: S/MIME Cryptographic Signature
Re: Where to place man-pages, when building multiple packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 lintian -V shows me: Lintian v2.4.3+squeeze1 It's the one which is shipped on default with Squeeze. Am 10.11.2011 10:58, schrieb Alexander Reichle-Schmehl: Hi! Am 10.11.2011 10:37, schrieb Björn Esser: Newer versions of lintian (around 2.5.1 or so) will check direct dependencies (that are built from the same source) if said dependencies are processed together. [..] So what shall I try to get things fixed? What version of lintian are you using? Best regards, Alexander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk67oTcACgkQ3u1SIc8s7PU8+AEAhLFdtGODaXNo0QXqtoY2dhLz lLk2zlDGGPoOUqj0HkMBAMBeLaFdOHLoBP1heLxn9l71rwCt6MvTGTcouaguYIvX =FsJM -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/4ebba138.5020...@googlemail.com
Re: Where to place man-pages, when building multiple packages
Hi! Am 10.11.2011 11:02, schrieb Björn Esser: What version of lintian are you using? lintian -V shows me: Lintian v2.4.3+squeeze1 It's the one which is shipped on default with Squeeze. http://backports-master.debian.org/ has an updated lintian package for squeeze, please always use that one, as lintian is rapidly developed. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4ebba315.2060...@schmehl.info
Re: Additional lintian warnings in mentors upload
On 2011-11-10 10:59, Ole Wolf wrote: I've noticed that the lintian check on my mentors uploads are a bit more strict than the lintian checks on my PC; for example, lintian on mentors catches version numbering intended for debian native packages. I want to eliminate such warnings and errors before I upload rather than discovering them afterwards. Hi, How do you use lintian? lintian pkg_ver_arch.deb lintian src_ver.dsc lintian src_ver_arch.changes The latter is preferred and should check everything included in the upload. You probably want to a full build for checking as some checks depend on the package type and what other packages (from the same source) are checked. My lintian version is v.2.5.3ubuntu2, so I'm guessing it's been modified for Ubuntu to skip such warnings/errors as the one mentioned above. Will a real (debian) lintian capture such errors/warnings, or do the mentor upload scripts make specific checks that won't be made by any generic lintian package I might find for debian? -- OLE WOLF[1] Rødhættevej 4 * 9400 Nørresundby Telefon: 9632-0108 * Mobil: 2467-5526 * Skype: ole.wolf * SIP: ole.w...@ekiga.net Links: -- [1] http://naturloven.dk Ubuntu has some modifications to lintian, but as I recall they only ignore debian-changelog-file-is-a-symlink and upstart-job-in-etc-init.d-not-registered-via-update-rc.d in lintian 2.5.3. You should be able to use lintian --profile debian to get Debian-like behaviour. Mind you, you should still build the package in Debian chroot, as Ubuntu and Debian has more diveragence in their build systems. :) ~Niels -- 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/4ebba387.70...@thykier.net
Re: Where to place man-pages, when building multiple packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 10.11.2011 10:01, Björn Esser wrote: jailkit -- here go all the c-binaries jailkit-common -- here go python-scripts, manpages, other no-arch why? Wouldn't it make slightly more sense to put the manpage where the corresponding executables lie in? That would also solve your problem. Also I do not see any benefit in splitting your package after all. You do not seem to provide any alternative to jailkit (the binary package is meant here), hence there is no common gound to share with another binary package. What's the size of the common package? Unless your arch:all data is huge you shouldn't be splitting it. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOu621AAoJEMcrUe6dgPNtjkoQAMBrxtk47G/YwyUb0rXfRWnU wFxiY91DCoRDGAl8LB/QsjLqnVfU/vsG8ZpfopEzt2T9odY9aCPTlokB3kA+Bf+v EdmcAfoMklNWzbzG6QR4cllqf/oNjbTwDXtdqwk5GT2CxvThHbncSRR9zVKxTNWH RnR2ZXalFDjZARW+h3IQgAp46adTZskROWs8ADYrKftUJ/9Pup7mhfiX+P7yZJl5 X2C6BTXgf09mz7jOirUa2tJZSCcU+h0z9hFpR0QPgQJa5rDEU8YcdpvJtXlqJsC0 JzQiqOAH5j+PwXcPefbg37eBs6soq79j1ah1JQXQbtaJ6g4bpgik2FCb6SOVVF/C PDOzoqy5GGVIBMqgbw1LYtH38qtQltY2zC36Bpp34FoCsOPKkUoN7XGwokvEHQ9r K7mF63wauisttpk4k9RgQny8THa7cp8IflT1leePGLJCVk9DVVp62w5o1/OgLk6D q0+yWoOJrCGv7W9CVnFW12McKdPx9CfAL0HLF2kZCFxbhtNIp/On4k8Mjp1yoIWd uu63+NTnXj8Qym8ZrLWcQb96aiIeKE59L/PWjZPbJdeV4bNWolo6gNLxsQ4SJ7yG eHH9/sAwL/iFLfBUILAiWubPiIP44C10jNaE53Mcvc++bjTOcYGbkKj+weInCkS3 3xZZhM0bv1mqVTDUNyyT =zScM -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/4ebbadb5.1020...@toell.net
Re: RFS: yast2-devtools
Hi, Björn Esser bjoern.es...@googlemail.com writes: I am looking for a sponsor for my package yast2-devtools. I'm just curious: what is this used for? Isn't YaST only used by SuSE? Regards, Ansgar -- 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/s2slirotg1p@bistromathics.mathi.uni-heidelberg.de
Re: RFS: yast2-devtools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10.11.2011 11:42, Ansgar Burchardt wrote: I'm just curious: what is this used for? Isn't YaST only used by SuSE? YaST has been liberated from its non-free origins a while ago. There even was an approach to introduce it to Debian once [1]. So, in theory you could run YaST on every distribution. Question remains whether you really want that, as YaST's messing in configuration files definitively breaks a random number of paragraphs in the Debian policy. That said, I do not know at all, what yast2-devtools is used/needed for, so I should perhaps shut up and let Björn answer. [1] http://yast4debian.alioth.debian.org/ - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOu7CrAAoJEMcrUe6dgPNtveYP/24i8OUSe7mcWEYhAB/sC3N4 xn+WcfLKRGC6ehjz5bURVtP0bCXpmHhuasFc95yuHF8zflpBOsRFcp2VwbWn2AQi 1BT6cQzIAdqhqRM8mgkrmKppft7aaGtSJjlZ3BI8QZ76HF97HN6lOzenWURXMgYD IV6bNFK/oHCJ0et/M97HDvr7pN84FVJVg7FfobeZf/6aqsngVFeXUTs/XvpZEulW YfoYsOQ5vmbPORsoivd1sdAMZXx6uGhVnK+VBNLwCjLYqqrnyc0Q2s+KUIgbnd6c dHi/98LeuVu/LiF3jhLeU4jC5Uzcj/53RQFWOGhdEIdrs6qaQsvVcYr9lZYIF6Q3 HH62B4+UNQJaSAwLZLGsu3Oymt5/aLufkQ0AeDy9MCmESDtswKs65QN15BlhKx5M ru4OTPGNLHeBTioTWP1PCBNgrnD8hPeWMrcwEo5rxk7VpQnGSq9ey0o7i9/h7qsO 9mU/jnYpJh2Ce5Ru00aVFAsbAlAGeVXn7nlV+obRHrQXQuqRZZic3cziDWrCx9xP U9eB/t0/tTgs8422SOuFwa+WpKQriQdFL8t9gSbZLt2eOxVD6T4G1hdo5jl8kBQz o/xOfYPlRYLFVO+qm3G2ejesx/E3aaDegP31DiI9aeNp52dBJQfVU4wEpdMJ7jN2 GG0yjR7NzQleSxet5KSb =trNW -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/4ebbb0ac.8040...@toell.net
Re: debian/rules override_dh_auto_build-indep
On Thu, Nov 10, 2011 at 10:25:27AM +0100, Niels Thykier wrote: On 2011-11-10 08:20, Mathieu Malaterre wrote: I have been trying to split indep operations from the rest on the activiz.net package, see: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup However the -indep rules are still being called on the buildd machine: Eg: http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.netarch=s390xver=5.6.1-2stamp=1320869304 [...] Am I missing something here ? This is one of the real issue behind the optional build-arch/build-indep targets; since they are optional dpkg-buildpackage/buildds do not use them. Therefore, you cannot rely on them as a maintainer (yet). [...] Agreed with all Niels comments. Your source package is fine; the issue is that dpkg-buildpackage (run by sbuild on the buildds) calls: debian/rules build debian/rules binary-arch when it should be running debian/rules build-arch debian/rules binary-arch I wrote a patch to fix this some time back, and it was discussed by the TC months ago. I guess it needs chasing up to get it applied. Once that's done, it will Just Work. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- 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/2010111438.gs28...@codelibre.net
Re: Where to place man-pages, when building multiple packages
On 2011-11-10 11:55, Arno Töll wrote: Hi, On 10.11.2011 10:01, Björn Esser wrote: jailkit -- here go all the c-binaries jailkit-common -- here go python-scripts, manpages, other no-arch why? Wouldn't it make slightly more sense to put the manpage where the corresponding executables lie in? That would also solve your problem. Also I do not see any benefit in splitting your package after all. You do not seem to provide any alternative to jailkit (the binary package is meant here), hence there is no common gound to share with another binary package. What's the size of the common package? Unless your arch:all data is huge you shouldn't be splitting it. Hey, If you need an architecture independent package anyway, putting the manpage in there saves a little space on the mirrors, so you might as well do it[1]. People have been doing this for years as far as I know[2], so I guess either way makes sense as long as the architecture-dependent package has a strict dependency on the architecture independent package. ~Niels [1] I know, this is most likely a tiny amount. [2] The bug requesting lintian to support this is nearly 10 years old today. -- 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/4ebbb263.2090...@thykier.net
RFS: scrotwm (already in Debian)
Dear mentors, I’m looking for a sponsor for my package “scrotwm”. * Package name : scrotwm Version : 0.9.34-1 Upstream Authors : Marco Peereboom ma...@peereboom.us, Ryan McBride mcbr...@countersiege.com, Darrin Chandler dwchand...@stilyagin.com * URL : http://opensource.conformal.com/wiki/Scrotwm * License : ISC and Expat and BSD-3-clause and BSD-4-clause Section : x11 It builds the following binary packages: scrotwm - dynamic tiling window manager The package, along with more information about it, can be found at http://mentors.debian.net/package/scrotwm This new version of the package fixes the following bugs: #531844 - scrotwm: please allow one workspace to span multiple monitors #552647 - suggest or recommend acpi and iostat The package is already in Debian; however, the packaged version is really old (almost two years) and my usual sponsor is no longer able to review and upload it further due to time constraints. I would be glad if someone would review and upload this package for me, and I would prefer it if the sponsor was interested in acting as a recurring sponsor for this and other packages I maintain in Debian. Have a nice day. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Re: Additional lintian warnings in mentors upload
Quoting Niels Thykier ni...@thykier.net: How do you use lintian? lintian pkg_ver_arch.deb lintian src_ver.dsc lintian src_ver_arch.changes Ah, my bad. I thought lintian should only be applied to the .deb files. -- OLE WOLF[1] Rødhættevej 4 * 9400 Nørresundby Telefon: 9632-0108 * Mobil: 2467-5526 * Skype: ole.wolf * SIP: ole.w...@ekiga.net Links: -- [1] http://naturloven.dk smime.p7s Description: S/MIME Cryptographic Signature
Re: Uploaded package is not showing up in mentors
Hi everyone, I have the same problem with my package 'uhub': http://mentors.debian.net/package/uhub Yesterday evening I uploaded updated version of the package via http. And dput said me that upload was successful. But there is no bot message in my e-mail and there is no updated package in m.d.n web site. All my previous uploads were without any problems. For example, you can see the history on page of 'uhub' package. Something really broken here. Regards, Boris -- 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/432661320924...@web89.yandex.ru
Re: Additional lintian warnings in mentors upload
On Thu, Nov 10, 2011 at 7:19 PM, Ole Wolf wrote: Ah, my bad. I thought lintian should only be applied to the .deb files. It might be interesting to find out where you got that impression from, so that we can prevent other people from getting the same impression in the future. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GTsoXJ5Y9kL0J8Kca22F87HTm=9_wgsmsgbpsrrwf...@mail.gmail.com
Re: Additional lintian warnings in mentors upload
Hi, I've noticed that the lintian check on my mentors uploads are a bit more strict than the lintian checks on my PC; for example, lintian on mentors catches version numbering intended for debian native packages. I want to eliminate such warnings and errors before I upload rather than discovering them afterwards. Just try to use special options for verbose output. I use something like this: lintian -ivI --pedantic *.changes My lintian version is v.2.5.3ubuntu2, so I'm guessing it's been modified for Ubuntu to skip such warnings/errors as the one mentioned above. Will a real (debian) lintian capture such errors/warnings, or do the mentor upload scripts make specific checks that won't be made by any generic lintian package I might find for debian? As I know there is no big difference between these packages in Debian and Ubuntu. Also I think there is no any reason to disable this specific warning in Ubuntu. So the problem on your side... Regards, Boris -- 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/442461320924...@web115.yandex.ru
Bug#648299: uscan; whitespace in filename
Package: devscripts Version: 2.10.69 Mathieu Malaterre mathieu.malate...@gmail.com writes: Has anyone work with upstream tarball with a space in the filename ? I could get uscan to work (--verbose), however --repack fails miserably on the following file: http://anonscm.debian.org/viewvc/collab-maint/deb-maint/openmcdf/debian/watch?view=markup with: unzip: cannot find or open ../OpenMCDF, ../OpenMCDF.zip or ../OpenMCDF.ZIP. tar: 1.5.2.tar.gz: Cannot stat: No such file or directory tar: Exiting with failure status due to previous errors Repacking from zip to tar.gz failed make: *** [get-orig-source] Error 2 This seems to be a bug in uscan: it uses system(unzip -q -d $tempdir $destdir/$newfile_base; GZIP=-9 tar -C $tempdir -czf $destdir/$newfile_base_gz .) == 0 to call unzip. As this involves a shell, it breaks if any of the variables contains whitespace (or other problematic characters). It should probably use a list instead of a scalar to avoid the shell. Ansgar -- 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/s2sehxgtfqd@bistromathics.mathi.uni-heidelberg.de
ITS: scrotwm (already in Debian)
On 2011-11-10 11:51, Andrea Bolognani wrote: Dear mentors, [...] The package is already in Debian; however, the packaged version is really old (almost two years) and my usual sponsor is no longer able to review and upload it further due to time constraints. I would be glad if someone would review and upload this package for me, and I would prefer it if the sponsor was interested in acting as a recurring sponsor for this and other packages I maintain in Debian. Have a nice day. Hi, As the subject suggests I am willing to sponsor the package. :) But before I do; have you considered enabling hardning flags in your package? A basic example of how to do it can be seen the attached patch[1]. Is there a reason that the binaries are compiled without optimization[2]? As far as I can tell it is an oversight, because the osx Makefile includes an -O2 flag. However, if it is known to have issues with optimization on Linux platforms, a comment about that would be appreciated (bonus points for valid references to bugs against gcc :P). ~Niels [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) [2] If so, my patch will need a DEB_CFLAGS_MAINT_STRIP:=-O2 before the include. diff -Nru scrotwm-0.9.34/debian/changelog scrotwm-0.9.34/debian/changelog --- scrotwm-0.9.34/debian/changelog 2011-11-09 18:04:29.0 +0100 +++ scrotwm-0.9.34/debian/changelog 2011-11-10 12:37:38.0 +0100 @@ -1,3 +1,10 @@ +scrotwm (0.9.34-1.1) UNRELEASED; urgency=low + + * Use buildflags.mk from dpkg-dev to set default buildflags. +- Enables hardning flags. + + -- Niels Thykier ni...@thykier.net Thu, 10 Nov 2011 12:40:00 +0200 + scrotwm (0.9.34-1) unstable; urgency=low * New upstream release. diff -Nru scrotwm-0.9.34/debian/control scrotwm-0.9.34/debian/control --- scrotwm-0.9.34/debian/control 2011-11-09 18:04:29.0 +0100 +++ scrotwm-0.9.34/debian/control 2011-11-10 12:38:15.0 +0100 @@ -2,7 +2,8 @@ Section: x11 Priority: optional Maintainer: Andrea Bolognani e...@kiyuko.org -Build-Depends: debhelper (= 7), libx11-dev, libxt-dev, libxrandr-dev, libxtst-dev +Build-Depends: debhelper (= 7), libx11-dev, libxt-dev, libxrandr-dev, libxtst-dev, + dpkg-dev (= 1.16.1~) Standards-Version: 3.9.2 Homepage: http://opensource.conformal.com/wiki/Scrotwm Vcs-Git: git://git.debian.org/collab-maint/scrotwm.git diff -Nru scrotwm-0.9.34/debian/patches/debian-changes-0.9.34-1.1 scrotwm-0.9.34/debian/patches/debian-changes-0.9.34-1.1 --- scrotwm-0.9.34/debian/patches/debian-changes-0.9.34-1.1 1970-01-01 01:00:00.0 +0100 +++ scrotwm-0.9.34/debian/patches/debian-changes-0.9.34-1.1 2011-11-10 12:41:50.0 +0100 @@ -0,0 +1,17 @@ +Description: Pass $(LDFLAGS) to gcc when making shared libraries. + +--- scrotwm-0.9.34.orig/linux/Makefile scrotwm-0.9.34/linux/Makefile +@@ -25,10 +25,10 @@ scrotwm: scrotwm.o linux.o + $(CC) $(LDFLAGS) -o $@ $+ $(LDADD) + + %.so: %.c +- $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@ ++ $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@ + + libswmhack.so.$(LVERS): swm_hack.so +- $(CC) -shared -fpic -o libswmhack.so.$(LVERS) swm_hack.so $(LDADD) ++ $(CC) -shared $(LDFLAGS) -fpic -o libswmhack.so.$(LVERS) swm_hack.so $(LDADD) + + install: all + install -m 755 -d $(DESTDIR)$(BINDIR) diff -Nru scrotwm-0.9.34/debian/patches/series scrotwm-0.9.34/debian/patches/series --- scrotwm-0.9.34/debian/patches/series 2011-11-09 18:04:29.0 +0100 +++ scrotwm-0.9.34/debian/patches/series 2011-11-10 12:41:04.0 +0100 @@ -4,3 +4,4 @@ 101-use-x-terminal-emulator-instead-of-xterm.diff 102-remove-openbsd-assumptions.diff 103-try-versioned-dlopen.diff +debian-changes-0.9.34-1.1 diff -Nru scrotwm-0.9.34/debian/rules scrotwm-0.9.34/debian/rules --- scrotwm-0.9.34/debian/rules 2011-11-09 18:04:29.0 +0100 +++ scrotwm-0.9.34/debian/rules 2011-11-10 12:38:01.0 +0100 @@ -1,5 +1,8 @@ #!/usr/bin/make -f +DPKG_EXPORT_BUILDFLAGS=1 +include /usr/share/dpkg/buildflags.mk + DESTDIR=$(CURDIR)/debian/scrotwm build: build-indep build-arch
Re: Additional lintian warnings in mentors upload
Quoting Paul Wise p...@debian.org: Ah, my bad. I thought lintian should only be applied to the .deb files. It might be interesting to find out where you got that impression from, so that we can prevent other people from getting the same impression in the future. I'm sure I got the impression from some web page that provided a howto on building a package. I don't recall which one, unfortunately. Nevertheless, the reason I relied on that web page was that I find it difficult to follow manuals such as this one: http://www.debian.org/doc/manuals/maint-guide/ --I needed examples and howtos. -- OLE WOLF[1] Rødhættevej 4 * 9400 Nørresundby Telefon: 9632-0108 * Mobil: 2467-5526 * Skype: ole.wolf * SIP: ole.w...@ekiga.net Links: -- [1] http://naturloven.dk smime.p7s Description: S/MIME Cryptographic Signature
Re: Additional lintian warnings in mentors upload
On Thu, Nov 10, 2011 at 8:26 PM, Ole Wolf wrote: I'm sure I got the impression from some web page that provided a howto on building a package. I don't recall which one, unfortunately. Ok. Nevertheless, the reason I relied on that web page was that I find it difficult to follow manuals such as this one: http://www.debian.org/doc/manuals/maint-guide/ --I needed examples and howtos. maint-guide is one big howto with one example sprinkled through it, so I'm not sure what should be changed there, perhaps you could file some bugs on it with suggested changes and or some links to documents that do it better than maint-guide. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6FJRfninfdRHS4YfuaO8Ai3_dUsvHBTtydVy-=qq7n...@mail.gmail.com
Re: RFS: yast2-devtools
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 10.11.2011 12:08, schrieb Arno Töll: On 10.11.2011 11:42, Ansgar Burchardt wrote: I'm just curious: what is this used for? Isn't YaST only used by SuSE? YaST was licensed under GPLv2 somewhen in 2004/2005. So it can be used by anyone and inside any distri, although it is currently on used in (open)SuSE, yet. yast2-devtools is the central-pkg, which is need to compile the YaST-core and to develop and/or compile the modules which add functions or config-tools to YaST [1] [2]. Since the effort of a GSoC-project, which made libYUI (I'll talk on that later) independent of zypper (pkg-management in SuSE) [3]. It would be a piece of cake to have the basic YaST-components to be ported to debian. The YasT-modules themselves need to be modded or redevlopped for debian, like make them use debconf, aptitude, dpkg or other debian-native tools instead of SuSE-native ones. libYUI (Yast User Interface) is a nifty lib to develop UIs using ncurses, gtk and qt. The special about it is you only need only one pice of code to get your UI work without having to worry about your tools is run from console, gnome, kde or somewhat else [4]. It was initially designed to make YaST's UI independent from the user's environment. So I think YaST would be a piece software, which could bring debian to larger audience by giving a way to setup daemons or system-settings in an easy way, even when you're just using a console-based (server-)system YaST has been liberated from its non-free origins a while ago. There even was an approach to introduce it to Debian once [1]. So, in theory you could run YaST on every distribution. Question remains whether you really want that, as YaST's messing in configuration files definitively breaks a random number of paragraphs in the Debian policy. YaST itself isn't messing around in the confs. This is the problem of SusE.config (which is called by several YaST-modules inside SusE). SuSE.config is the more or less somewhat compound of debconf. So for debian the modules need to be modded as stated above. That said, I do not know at all, what yast2-devtools is used/needed for, so I should perhaps shut up and let Björn answer. [1] http://yast4debian.alioth.debian.org/ [1] http://en.opensuse.org/openSUSE:YaST_development [2] http://en.opensuse.org/openSUSE:YaST_tutorials_development_in_general [3] http://nbprashanth.wordpress.com/category/gsoc/ [4] http://www.slideshare.net/hedgehogpainter/3-uis-for-the-price-of-one-code I hope this gives a bit of information to this. BR, Björn. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk67zrsACgkQ3u1SIc8s7PWFbQEA6I93kQ2efFFdEbgf/q/Ab/6/ ANKuC3GxGxUh6BqQWC4A/1Vrh5dSKINP4kVX67M6+H495JBe7mjzOFAOo7UdGGdz =8drK -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/4ebbcebb.3020...@googlemail.com
uploaded package as if it belong to someone else
Hi Mentors, Just wanted to share a peculiar situation with package upload: Recently I uploaded a package to mentors for review, but it didn't show in http://mentors.debian.net/packages/my (Fortunately I could get a URL for .dsc file from confirmation email so it wasn't much of a problem apart from being unable to delete the package) I just found where did it go. It turned out that some time ago Andreas Beckmann packaged the same thing and posted it to mentors. Probably because my package name is the same as his (and his package is still there) my upload goes to page http://mentors.debian.net/package/r8168 where my version 8.026.00-1 looks like if it was uploaded by him. I'm not sure if this is a bug or expected but unforeseen behavior. Regards, Dmitry. -- 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/CANBdODXEmO+kgzNxPc3RRqniA0SDE7-qWdWq4oL5jSPqYvV=i...@mail.gmail.com
Re: RFS: python-libmemcached
thx, I will try to fix that. 2011/11/9 Jakub Wilk jw...@debian.org * Shell Xu shell909...@gmail.com, 2011-11-04, 15:53: http://mentors.debian.net/**package/python-libmemcachedhttp://mentors.debian.net/package/python-libmemcached Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/**debian/pool/main/p/python-** libmemcached/python-**libmemcached_0.40-1.dschttp://mentors.debian.net/debian/pool/main/p/python-libmemcached/python-libmemcached_0.40-1.dsc (I don't intend to sponsor this package.) Please consider using debhelper (= 8) rather than debhelper (= 8.0.0). The long description is... bad. Please consult Developer's Reference 6.2.3 about how should it look like. As per Python Policy 2.2, the binary package name should be python-cmemcached. The package fails to build in a minimal environment: | dh clean --with python2 |dh_testdir |dh_auto_clean | Traceback (most recent call last): | File setup.py, line 3, in module | from setuptools import setup, Extension | ImportError: No module named setuptools | dh_auto_clean: python setup.py clean -a returned exit code 1 | make: *** [clean] Error 2 -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-REQUEST@lists.**debian.orgdebian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/**2009152251.GA1651@jwilk.**nethttp://lists.debian.org/2009152251.ga1...@jwilk.net -- 无能者无所求，饱食而遨游，泛若不系之舟 blog: http://shell909090.com/blog/ twitter: http://twitter.com/shell909090
Re: RFS: python-ipcalc [update]
On Thu, Nov 10, 2011 at 7:01 AM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Nov 09, 2011 at 04:54:34PM +, mezgani ali wrote: All job is done Andrey, what do you think ? You've renamed README.Debian to README.source. debian/patches/01_network.patch: - Why Forwarded: not-needed? - Origin: states that the patch was taken from #533437, this is not true - Bug-Debian: states that #533437 is related to the patch, this is not true either debian/patches/02_hextoipv4.patch: - Again, why Forwarded: not-needed? debian/copyright: - License: GPL-3 but text for MIT? Anyway, I'd suggest you to relicense your work to MIT rather than put additional burden on the package users by changing the package license. Why may i rename my work to MIT ? please explain , if i understand i have to remove GPL-3 and let the package licence as is it - The Debian packaging is: Copyright (C) 2011? What about 2009? debian/control: Description still starts from lowercase letters. On Wed, Nov 9, 2011 at 3:48 PM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Nov 09, 2011 at 03:33:09PM +, mezgani ali wrote: updated but still have a warning, please take a look at it Your diff.gz creates python-ipcalc-0.3/pkg-info. Please can you explain me this point ? What is the problem with diff.gz ? Did you read the description of patch-system-but-direct-changes-in-diff lintian tag? -- WBR, wRAR -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: cxxtest - xUnit-like framework for C/C++ applications
Hello Michael. No interesting reply from the upstream authors. Only one of the authors reply me but asking the others what they want to do about the missing license header in the source files. I suggested some alternative to release the new version of cxxtest with the license header, but they didn't reply me. Do you think the package won't be accepted in Debian without the headers? Thanks, bye Simone signature.asc Description: OpenPGP digital signature
Re: RFS: python-ipcalc [update]
On Thu, Nov 10, 2011 at 03:36:40PM +, mezgani ali wrote: Why may i rename my work to MIT ? Because you have the copyright. please explain , if i understand i have to remove GPL-3 and let the package licence as is it What should I explain? -- WBR, wRAR signature.asc Description: Digital signature
Re: RFS: python-ipcalc [update]
Andrey, all changes is updated please take a look to my package. On Thu, Nov 10, 2011 at 4:14 PM, Andrey Rahmatullin w...@wrar.name wrote: On Thu, Nov 10, 2011 at 03:36:40PM +, mezgani ali wrote: Why may i rename my work to MIT ? Because you have the copyright. please explain , if i understand i have to remove GPL-3 and let the package licence as is it What should I explain? -- WBR, wRAR -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
RFS: dwm (Adapted package)
Dear mentors, I'm looking for a sponsor for package dwm. This package was orphaned by its previous maintainer. This upload will close #647088. The package can be accessed using dget -X http://silpa.org.in/~vasudev/dwm/dwm_5.9-1.dsc I was trying to upload to mentors from past one week with no luck so I uploaded it to a VPS in which I've account Best Regards -- Vasudev Kamath http://blog.copyninja.info vasu...@joindiaspora.com (Ostatus) signature.asc Description: Digital signature
RFS: aclock.app/0.2.3-3.1 (NMU to fix RC bug)
Dear mentors, I am looking for a sponsor for my NMU of aclock.app. It fixes #645921. I'd be glad if someone uploaded this package for me. http://mentors.debian.net/debian/pool/main/a/aclock.app/aclock.app_0.2.3-3.1.dsc -- 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/878vnndgfg.GNUs_Not_Unix!%ya...@gnu.org
Re: RFS: aclock.app/0.2.3-3.1 (NMU to fix RC bug)
On Thu, 10 Nov 2011, Yavor Doganov wrote: I am looking for a sponsor for my NMU of aclock.app. It fixes #645921. I'd be glad if someone uploaded this package for me. I am looking into it now. cheers, Andrea signature.asc Description: Digital signature
Re: Uploaded package is not showing up in mentors
I have just tried again twice. Result is still negative. Any suggestions? 10.11.2011, 13:49, Boris Pek tehnic...@yandex.ru: Hi everyone, I have the same problem with my package 'uhub': http://mentors.debian.net/package/uhub Yesterday evening I uploaded updated version of the package via http. And dput said me that upload was successful. But there is no bot message in my e-mail and there is no updated package in m.d.n web site. All my previous uploads were without any problems. For example, you can see the history on page of 'uhub' package. Something really broken here. Regards, Boris -- 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/97961320947...@web23.yandex.ru
RFS: jailkit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear mentors, I am looking for a sponsor for my package jailkit. * Package name: jailkit Version : 2.14-1 Upstream Author : Olivier Sessink oliv...@bluefish.openoffice.nl * URL : http://olivier.sessink.nl/jailkit/ * License : BSD-3 Section : admin It builds those binary packages: jailkit- chroot jail utilities jailkit-common - architecture independent files for jailkit To access further information about this package, please visit the following URL: http://mentors.debian.net/package/jailkit Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/j/jailkit/jailkit_2.14-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Björn Esser -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iF4EAREIAAYFAk68HrAACgkQ3u1SIc8s7PXX8wEA1WF/XFsn93xYiqoMv28jzqYF OnFI90sdx/W8jqnvGBEBAJDxYTnBQKtG1j7LqlX/swDbs8BKou6VwY3IY3SCHPyM =wofn -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/4ebc1eb0.4090...@googlemail.com
Re: Uploaded package is not showing up in mentors
Ok. I found temporary solution for myself. I had deleted the package before new upload. And uploaded package was successfully added again in m.d.n. and I received appropriate confirmation from bot. But this is not common solution. And this bug is really serious. 10.11.2011, 19:48, Boris Pek tehnic...@yandex.ru: I have just tried again twice. Result is still negative. Any suggestions? 10.11.2011, 13:49, Boris Pek tehnic...@yandex.ru: Hi everyone, I have the same problem with my package 'uhub': http://mentors.debian.net/package/uhub Yesterday evening I uploaded updated version of the package via http. And dput said me that upload was successful. But there is no bot message in my e-mail and there is no updated package in m.d.n web site. All my previous uploads were without any problems. For example, you can see the history on page of 'uhub' package. Something really broken here. Regards, Boris -- 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/146241320954...@web147.yandex.ru
Re: RFS: jailkit
* BjĂśrn Esser bjoern.es...@googlemail.com, 2011-11-10, 19:57: http://mentors.debian.net/package/jailkit Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/j/jailkit/jailkit_2.14-1.dsc (I don't intend to sponsor this package.) The package fails to build in a minimal environment: |dh_install | cp: cannot stat `debian/tmp//usr/sbin/jk_procmailwrapper': No such file or directory | dh_install: cp -a debian/tmp//usr/sbin/jk_procmailwrapper debian/jailkit///usr/sbin/ returned exit code 1 Lintian complains: I: jailkit source: duplicate-long-description jailkit jailkit-common W: jailkit source: format-3.0-but-debian-changes-patch W: jailkit-common: manpage-has-errors-from-man usr/share/man/man8/jailkit.8.gz 73: warning: macro `Use' not defined I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jailkit.8.gz:110 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jailkit.8.gz:111 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jailkit.8.gz:112 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jailkit.8.gz:114 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:16 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:18 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:20 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:22 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:75 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:79 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_check.8.gz:83 I: jailkit-common: spelling-error-in-manpage usr/share/man/man8/jk_chrootlaunch.8.gz deamon daemon I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_chrootlaunch.8.gz:32 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_chrootlaunch.8.gz:66 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_cp.8.gz:18 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_cp.8.gz:22 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_init.8.gz:43 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_jailuser.8.gz:18 I: jailkit-common: spelling-error-in-manpage usr/share/man/man8/jk_jailuser.8.gz seperator separator I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_lsh.8.gz:12 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_socketd.8.gz:68 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_socketd.8.gz:71 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_socketd.8.gz:74 I: jailkit-common: hyphen-used-as-minus-sign usr/share/man/man8/jk_socketd.8.gz:84 Why do you build depend on python2.6-minimal and python-minimal? debian/docs lists README.txt twice. jailkit.postrm is kinda empty, just remove it. jailkit's prerm removes /usr/share/jailkit/jk_lib.pyc, but /usr/share/jailkit/jk_lib.py is in the other package (jailkit-common). Anyway, python-support would take care of byte-compilation (and cleaning up after it) if used correctly... Maybe more importantly, why jailkit and jailkit-common are separate packages? jk_list --help doesn't quite work: | # jk_list --help | Traceback (most recent call last): | File /usr/sbin/jk_list, line 156, in module | main() | File /usr/sbin/jk_list, line 144, in main | usage() | NameError: global name 'usage' is not defined -- Jakub Wilk -- 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/2010210733.gb...@jwilk.net
Re: ITS: scrotwm (already in Debian)
On 2011-11-10 17:08, Andrea Bolognani wrote: On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote: Hi, As the subject suggests I am willing to sponsor the package. :) I’m glad to hear that! Hi, But before I do; have you considered enabling hardning flags in your package? A basic example of how to do it can be seen the attached patch[1]. Thanks for pointing that out. I’m looking at the documentation and at your patch, and I’m unsure about this bit %.so: %.c - $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@ + $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@ Are you positive $(LDFLAGS) is supposed to be passed to the compiler here? It is just creating an object file, so the linker should not be called by $(CC). I am indeed wrong. I assumed that the %.so: %.c rule implied it was a shared library and completely overlooked the -c argument. [...] I will patch the Makefile and send the patch upstream for inclusion in a future release. Is there a reason that the binaries are compiled without optimization[2]? As far as I can tell it is an oversight, because the osx Makefile includes an -O2 flag. However, if it is known to have issues with optimization on Linux platforms, a comment about that would be appreciated (bonus points for valid references to bugs against gcc :P). It’s almost certainly an oversight. [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) Can’t think of a way of doing that without patching the Makefile. But then again, patching the Makefile is no big deal. If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) Thanks for your input, I’ll let you know when I have an updated package ready for review. Looking forward to seeing it. :) ~Niels -- 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/4ebc3e60.5040...@thykier.net
Re: debian/rules override_dh_auto_build-indep
On Thu, Nov 10, 2011 at 12:14 PM, Roger Leigh rle...@codelibre.net wrote: On Thu, Nov 10, 2011 at 10:25:27AM +0100, Niels Thykier wrote: On 2011-11-10 08:20, Mathieu Malaterre wrote: I have been trying to split indep operations from the rest on the activiz.net package, see: http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup However the -indep rules are still being called on the buildd machine: Eg: http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.netarch=s390xver=5.6.1-2stamp=1320869304 [...] Am I missing something here ? This is one of the real issue behind the optional build-arch/build-indep targets; since they are optional dpkg-buildpackage/buildds do not use them. Therefore, you cannot rely on them as a maintainer (yet). [...] Agreed with all Niels comments. Your source package is fine; the issue is that dpkg-buildpackage (run by sbuild on the buildds) calls: debian/rules build debian/rules binary-arch when it should be running debian/rules build-arch debian/rules binary-arch I wrote a patch to fix this some time back, and it was discussed by the TC months ago. I guess it needs chasing up to get it applied. Once that's done, it will Just Work. buildd can make the decision to run build-indep, I am ok with it. What I am not ok with, is when buildd are setup to run build-indep rules, but do not respect B-D-I ! That does not make any sense for me. Anyway I have merged B-D-I into B-D, as suggested. And -2 seems to compile just fine -well almost I need to B-D on doxygen-latex- Thanks, -- Mathieu -- 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/ca+7wuswji_xhh5w2wobpdbg2-czynqzgyk8retufr_cxqz6...@mail.gmail.com
Re: debian/rules override_dh_auto_build-indep
Mathieu Malaterre mathieu.malate...@gmail.com writes:
buildd can make the decision to run build-indep, I am ok with it.
What I am not ok with, is when buildd are setup to run build-indep
rules, but do not respect B-D-I !
That does not make any sense for me.
Anyway I have merged B-D-I into B-D, as suggested. And -2 seems to
compile just fine -well almost I need to B-D on doxygen-latex-
There's an alternative solution, that lets you keep B-D-I separate, and
doesn't break buildds. But it's ugly, and 'breaks' debian/rules build:
If you disable the build target, and make it do nothing, but make
binary-{arch,indep} depend on the appropriate build-{arch,indep} target,
that will skip build-indep on the buildds.
I've done something like this in the libmongo-client package, because I
didn't want to pull in doxygen as a B-D, especially not since buildds
shouldn't rebuild the docs anyway.
It's not pretty, because build becomes a no-op, but it makes one able to
push a couple of huger build-deps into B-D-I. (It's also not a violation
of the letter of the policy, because policy only says that build should
perform compilation.)
--
|8]
--
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/87bosjhcic@luthien.mhp
RFS: php-pecl-http - extended HTTP support for php5
Dear mentors, I am looking for a sponsor for my new package php-pecl-http. * Package name: php-pecl-http Version : 1.7.1+dfsg.1-1 Upstream Author : Michael Wallner m...@php.net * URL : http://pecl.php.net/package/pecl_http * License : BSD-2 Section : web Language: C It builds a single binary package: php5-pecl-http - extended HTTP support for php5 It has been tested with Lintian and pbuilder; there is an experimental Lintian warning about a shared lib calling exit(), but this is an artifact of using PHP's memory allocator which dies horribly instead of returning with some kind of error indication. Still, if people think it's worth it, I could add an override. (well, okay, there's also a pedantic warning, since I haven't converted upstream's package.xml file to a changelog yet; this is on my to-do list) More information about the package is available at its mentors.d.n page: http://mentors.debian.net/package/php-pecl-http Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/php-pecl-http/php-pecl-http_1.7.1+dfsg.1-1.dsc I would be glad if someone uploaded this package for me. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@freebsd.org pe...@packetscale.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 This sentence is false. signature.asc Description: Digital signature
Re: RFS: yubiserver (new package in Debian, 2nd try)
On Wed, Nov 09, 2011 at 10:50:29AM +0200, Nanakos V. Chrysostomos wrote: It needs automake package in the Build-Depends field. I will upload a new update in a few hours. Uploaded. signature.asc Description: Digital signature
Re: RFS: yubiserver (new package in Debian, 2nd try)
Thank you very much. On 11 Νοε 2011, at 0:27, Anibal Monsalve Salazar ani...@debian.org wrote: On Wed, Nov 09, 2011 at 10:50:29AM +0200, Nanakos V. Chrysostomos wrote: It needs automake package in the Build-Depends field. I will upload a new update in a few hours. Uploaded. -- 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/675fbaec-4cf5-4bfc-9019-f84223b2b...@wired-net.gr
Re: ITS: scrotwm (already in Debian)
2011/11/10 Niels Thykier ni...@thykier.net On 2011-11-10 17:08, Andrea Bolognani wrote: On Thu, Nov 10, 2011 at 12:56:57PM +0100, Niels Thykier wrote: Hi, As the subject suggests I am willing to sponsor the package. :) I’m glad to hear that! Hi, But before I do; have you considered enabling hardning flags in your package? A basic example of how to do it can be seen the attached patch[1]. Thanks for pointing that out. I’m looking at the documentation and at your patch, and I’m unsure about this bit %.so: %.c - $(CC) $(CFLAGS) -c -fpic -DPIC $+ -o $@ + $(CC) $(LDFLAGS) $(CFLAGS) -c -fpic -DPIC $+ -o $@ Are you positive $(LDFLAGS) is supposed to be passed to the compiler here? It is just creating an object file, so the linker should not be called by $(CC). I am indeed wrong. I assumed that the %.so: %.c rule implied it was a shared library and completely overlooked the -c argument. [...] I will patch the Makefile and send the patch upstream for inclusion in a future release. Is there a reason that the binaries are compiled without optimization[2]? As far as I can tell it is an oversight, because the osx Makefile includes an -O2 flag. However, if it is known to have issues with optimization on Linux platforms, a comment about that would be appreciated (bonus points for valid references to bugs against gcc :P). It’s almost certainly an oversight. [1] Strictly speaking the CFLAGS/LDFLAGS from should overrule the upstream ones if there are conflicts. Fixing that is left as an exercise to the reader. ;) Can’t think of a way of doing that without patching the Makefile. But then again, patching the Makefile is no big deal. If you are going to send a patch upstream anyway, you might as well make it possible to insert user *FLAGS after the upstream flags. ;) Thanks for your input, I’ll let you know when I have an updated package ready for review. Looking forward to seeing it. :) ~Niels -- 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/4ebc3e60.5040...@thykier.net Oh this is really nice, i'm glad to finally see that you got a sponsor. :-)
RFS: acsccid (squeeze-backports)
Dear mentors, I am looking for a sponsor for my package acsccid. * Package name: acsccid Version : 1.0.2-3~bpo60+1 Upstream Author : Advanced Card Systems Ltd. * URL : http://acsccid.sourceforge.net/ * License : LGPL-2.1+ Section : libs It builds those binary packages: libacsccid1 - PC/SC driver for ACS USB CCID smart card readers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/acsccid Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/acsccid/acsccid_1.0.2-3~bpo60+1.dsc I would be glad if someone uploaded this package for me. Kind regards, Godfrey Chung
Re: Uploaded package is not showing up in mentors
2011/11/11 Boris Pek tehnic...@yandex.ru: Ok. I found temporary solution for myself. I had deleted the package before new upload. And uploaded package was successfully added again in m.d.n. and I received appropriate confirmation from bot. But this is not common solution. And this bug is really serious. Yes you are right in my case I can't follow this solution because the previous package is uploaded by some one else and now I really own an ITA for the package. So I uploaded it to a VPS in which I have account and sent an RFS. Best Regards -- Vasudev Kamath http://vasudevkamath.blogspot.com http://identi.ca/vasudev http://twitter.com/vasudevkamath -- 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/CAK+NOPXS=csX=m-isrjmetn4dgzk1gov_rdrnmob-bcar6s...@mail.gmail.com
Re: RFS: dwm (Adapted package)
On 10.11.2011 20:52, Vasudev Kamath wrote: Dear mentors, I'm looking for a sponsor for package dwm. This package was orphaned by its previous maintainer. This upload will close #647088. Hm. So I become curious and looked into its homepage -- http://dwm.suckless.org/ . And there, there's one interesting note: Because dwm is customized through editing its source code, it’s pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though. Maybe there should be no binaries really? :) /mjt -- 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/4ebcd2f3.7000...@msgid.tls.msk.ru
