Re: different version numbers?
Hi Paul, On Mon, Jul 25, 2011 at 10:13:56PM -0500, Paul Elliott wrote: All the different versions numbers make my brain hurt! It'll be better soon. ;-) What is the relationship, if any, between the version number of the source pachage and the version number of a library, which has to do with SONAME. Library versions are described in http://www.debian.org/doc/debian-policy/ch-sharedlibs.html Versions at large are covered in http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version including the description of where source/upstream version number goes and what the debian_revision is. What do these have to do with PACKAGE_VERSION in autotools? That should be upstream's version in the source for most if not all cases. My up stream, has version number associated with his source tarballs, that have nothing to do with debian or Linux, because he does not develop with Linux in mind. All though he does build a Linux static library. There's a number of upstreams that don't target Debian but still have their source distributed with it. The general rules (like version numbers always increment) still apply though. -- Best regards, Kilian signature.asc Description: Digital signature
Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it
Hi Ben, On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote: Howdy all, Lintian recommends (via tag ‘debian-rules-missing-recommended-target’): = N: Note that the following form is recommended however: N: N: build: build-arch build-indep N: build-arch: build-stamp N: build-indep: build-stamp N: build-stamp: N: build here = I am building arch-independent and arch-dependent packages from a rules file. The actions don't need anything other than “dh $@”. (I don't want to use the “%:” style, since I prefer the ‘.PHONY’ target to be explicit). But where should “dh $@” be put? The above information from Lintian recommends that all the build actions should be in ‘build-stamp’, but ‘dh’ doesn't know about that target and barfs. If you're sure that you want to use dh but .PHONY then just put into your rules something like: build-indep: dh $@ build-arch: dh $@ build: build-arch build-indep No need for a stamp as dh is already producing stamps internally. At second thought I'm not too sure what would happen if you'd put %: dh $@ and also .PHONY into debian/rules. Considering the internal stamps of dh that might also be an option. Just out of curiosity: what are you stuffing into your .PHONY target that you need to manually control? -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Re: different version numbers?
Greetings, On Mon, Jul 25, 2011 at 10:13:56PM -0500, Paul Elliott wrote: What is the relationship, if any, between the version number of the source pachage and the version number of a library, which has to do with SONAME. What do these have to do with PACKAGE_VERSION in autotools? My up stream, has version number associated with his source tarballs, that have nothing to do with debian or Linux, because he does not develop with Linux in mind. All though he does build a Linux static library. As library packaging is generally regarded as a difficult task, a very good guide at http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html is a recommended reading. That guide contains also very clear background information on the various version numbering systems possibly involved. Best regards, Filippo -- Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu Researcher at CNRS and Debian Developer lopi...@debian.org Author of ``massXpert'' at http://www.massxpert.org signature.asc Description: Digital signature
RFS: mosquitto (new upstream version)
Dear mentors, I am looking for a sponsor for my package mosquitto. This is an updated package for a new upstream version. The new version includes an additional exported symbol in the two libraries. I believe I've updated the .symbols files correctly, but would appreciate it being checked. The package is lintian clean. Thanks, Roger * Package name: mosquitto Version : 0.12-1 Upstream Author : Roger Light ro...@atchoo.org * URL : http://mosquitto.org/ * License : BSD Section : net It builds these binary packages: libmosquitto0 - MQTT version 3.1 client library libmosquitto0-dev - MQTT version 3.1 client library, development files libmosquittopp0 - MQTT version 3.1 client C++ library libmosquittopp0-dev - MQTT version 3.1 client C++ library, development files mosquitto - MQTT version 3.1 compatible message broker mosquitto-clients - Mosquitto command line clients python-mosquitto - MQTT version 3.1 client library, python bindings The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/mosquitto - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.12-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/cah7zdyd3ycfdvs_mipmtc+badyfpquy3t9muy3psyaxca+y...@mail.gmail.com
RE : different version numbers?
As library packaging is generally regarded as a difficult task, a very good guide at http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html is a recommended reading. That guide contains also very clear background information on the various version numbering systems possibly involved. Yes it is a good introduction, but I could not find an answer to that question: libX + libX-dev or libX + lib-dev It is not clear to me what is the best practice. See you Frederic -- 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/a2a20ec3b8560d408356cac2fc148e5320a4e...@sun-dag1.synchrotron-soleil.fr
Re: RFS: mosquitto (new upstream version)
Hi Roger, On Tue, 2011-07-26 at 09:20 +0100, Roger Light wrote: I am looking for a sponsor for my package mosquitto. This is an updated package for a new upstream version. The new version includes an additional exported symbol in the two libraries. I believe I've updated the .symbols files correctly, but would appreciate it being checked. The package is lintian clean. - dget http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.12-1.dsc Thanks for your work. Your package still has rev 135 of DEP-5 in debian/copyright. That may be worth updating with the next upload. The files in debian/ are reported as in the future. You may want to check your system clock. ;-) Regarding the symbols: As I see it you're having C++ symbols in libmosquittopp0. I think it'd make sense to use the c++ feature. See the list archive of this list for a number of hints and references/best practice etc.. Other than that no problems I would see there. Your patches don't have a DEP-3 header making it impossible to tell whether they have been pushed upstream. I guess upstream would be interested in at least some of them. You have debian/pyversions which you might also want to document in debian/control as XS-Python-Version. The binaries python-mosquitto, libmosquitto0-dev, libmosquittopp0-dev, python-mosquitto do not have any arch dependent code AFAICT yet they are marked as arch=any. Do you see any problem making them arch=all? Anyway, built, signed, uploaded. Cheers. -- Best regards, Kilian signature.asc Description: This is a digitally signed message part
Re: RE : different version numbers?
Greetings, On Tue, Jul 26, 2011 at 08:26:19AM +, PICCA Frédéric-Emmanuel wrote: As library packaging is generally regarded as a difficult task, a very good guide at http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html is a recommended reading. That guide contains also very clear background information on the various version numbering systems possibly involved. Yes it is a good introduction, but I could not find an answer to that question: libX + libX-dev or libX + lib-dev It is not clear to me what is the best practice. It is my understanding that both are possible, depending on what the packager wishes to actually package. The most general case is that the packager only wants to package the developement files for the last version of the library. In that case, lib-dev is fine, because each time that package gets installed it overwrites the files shipped with the previous version. It might happen, however, that the packager wishes to support the developement of various versions of the library. Because two same files can not belong to two different simultaneousy installable packages (that would be a conflict), then it is required that the developement files for lib1 be packaged in lib1-dev and the development files for lib2 be packaged in lib2-dev. Hope this helps (and is actually a correct understanding of the -dev package naming/numbering process), Kind regards, Filippo -- Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu Researcher at CNRS and Debian Developer lopi...@debian.org Author of ``massXpert'' at http://www.massxpert.org -- 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/20110726092317.GB2834@biophypfr
Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it
* Kilian Krause kil...@debian.org, 2011-07-26, 09:18: I'm not too sure what would happen if you'd put %: dh $@ and also .PHONY into debian/rules. Considering the internal stamps of dh that might also be an option. % is supposed to be used for file targets only (though it's common to abuse it for other purposed these days). It won't work with .PHONY. -- Jakub Wilk signature.asc Description: Digital signature
Re: RFS: mosquitto (new upstream version)
* Kilian Krause kil...@debian.org, 2011-07-26, 11:33: You have debian/pyversions which you might also want to document in debian/control as XS-Python-Version. No. Use either debian/pyversions or XS-Python-Version, not both. (Just to be clear: XS-Python-Version is not only for documentation purposes, it's actually used by some packaging helpers.) -- 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/20110726101000.ga7...@jwilk.net
What is needed to upload a package as DM?
hi, I'm trying to upload a package to incoming queue as DM, but it fails. Reject Reasons: lur...@gmail.com is not in Maintainer or Uploaders of source package yaskkserv I'm sure that what tutorial says (http://wiki.debian.org/DebianMaintainer/Tutorial): 1) DMUA: yes 2) my key is in debian-maintainer keyring 3) the old package has my UID in maintainer filed Please teach me what's needed for uploading. -- $ apt-get source yaskkserv Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'yaskkserv' packaging is maintained in the 'Git' version control system at: git://git.debian.org/users/lurdan-guest/yaskkserv.git Need to get 85.1 kB of source archives. Get:1 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5 (dsc) [1251 B] Get:2 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5 (tar) [73.0 kB] Get:3 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5 (diff) [10.9 kB] Fetched 85.1 kB in 0s (474 kB/s) dpkg-source: info: extracting yaskkserv in yaskkserv-0.4.0 dpkg-source: info: unpacking yaskkserv_0.4.0.orig.tar.gz dpkg-source: info: unpacking yaskkserv_0.4.0-5.debian.tar.gz $ egrep '(Allowed|KURA)' yaskkserv_0.4.0-5.dsc Maintainer: KURASHIKI Satoru lur...@gmail.com Dm-Upload-Allowed: yes $ gpg --list-keys 40A2F113 pub 4096R/40A2F113 2009-09-10 uid KURASHIKI Satoru lur...@gmail.com uid KURASHIKI Satoru lur...@debian.or.jp sub 4096R/D7B08969 2009-09-10 $ gpg --keyring /usr/share/keyrings/debian-maintainers.gpg --no-default-keyring --list-keys 40A2F113 pub 4096R/40A2F113 2009-09-10 uid KURASHIKI Satoru lur...@gmail.com uid KURASHIKI Satoru lur...@debian.or.jp sub 4096R/D7B08969 2009-09-10 $ gpg --verify yaskkserv_0.4.0-6.dsc gpg: Signature made Tue Jul 26 08:46:30 2011 JST using RSA key ID 40A2F113 gpg: Good signature from KURASHIKI Satoru lur...@gmail.com gpg: aka KURASHIKI Satoru lur...@debian.or.jp -- regards, -- KURASHIKI Satoru -- 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/CAM0xXk-MrnA5bhUFvhCbKnZ=rgp+kqkpfujq48js++n5tey...@mail.gmail.com
Re: What is needed to upload a package as DM?
Hi, Hi, On Tue, Jul 26, 2011 at 08:30:03PM +0900, Satoru KURASHIKI wrote: I'm trying to upload a package to incoming queue as DM, but it fails. Reject Reasons: lur...@gmail.com is not in Maintainer or Uploaders of source package yaskkserv Have you tried replying to the email and asking ftp-masters what went wrong? I had a similar issue last week and they told me that the issue was caused by a space before the comma in the Uploaders field of a previous upload. They should be able to help you out. Kind regards, Ryan signature.asc Description: Digital signature
RFS: hashalot
Hi! I'd like to ask for a sponsor for an update to hashalot (a tool needed by cryptsetup, obsolete nowadays but some folks still use it). There's just one minor documentation fix, but I also nuked the whole debian/rules replacing it with oh-so-long dh two liner. The copyright is in DEP-5 format as well. dget http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc Readable list of changes: git://gitorious.org/hashalot/hashalot.git https://gitorious.org/hashalot/hashalot/commits/master -- 1KB // Yo momma uses IPv4! -- 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/20110726113254.ga2...@angband.pl
Re: What is needed to upload a package as DM?
On Tue, Jul 26, 2011 at 13:30, Satoru KURASHIKI lur...@gmail.com wrote: $ egrep '(Allowed|KURA)' yaskkserv_0.4.0-5.dsc Maintainer: KURASHIKI Satoru lur...@gmail.com Dm-Upload-Allowed: yes Aren't fields in Deb 822 format case-sensitive? (They are at least if it comes to Packages files and co.) Best regards David Kalnischkies -- 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/CAAZ6_fCPTEAgH4_ygL4=c+JaY-1DcYipe=mylg7kizqmm2w...@mail.gmail.com
Re: RFS: eviacam
Hi, As promised, here is my review. Thanks Paul for your thorough review! I (hopefully) managed to fix all the issues you pointed out. I uploaded an updated version to the mentors site which also appears to be lintian clean. I hope that all these improvement will help to find an sponsor for eviacam. More details are provided below. I am looking for a sponsor for my package eviacam. * Package name: eviacam Version : 1.5.2 Upstream Author : Cesar Maurice...@crea-si.com * URL : http://viacam.org * License : GPL Version 3 or higher according to your copyright file. Right. Section : x11 It builds these binary packages: eviacam- A cross platform webcam based mouse emulator For Debian it is not relevant that this software is cross platform. Also the synopsis should not start with A. I would suggest: eviacom - webcam based mouse emulator Updated debian/control I was able to fix most Lintian errors and warnings, but I feel that to fix the remaining warnings I would need some help. W: eviacam source: non-native-package-with-native-version This should be solved by adding a DEBIAN version to the version number in your changelog. I.e. 1.5.2-1. Done. W: eviacam source: empty-debian-diff This is because your upstream package already includes the debian directory and there are no changes to be put in the diff and you are using source 1.0 (implicit). If you want to continue also distributing the debian directory in the upstream release I strongly suggest using source version 3.0 (quilt) to avoid problems with NMU's. See also dpkg-source(1). OK. Switched to source version 3.0. Further, my comments on your debian/* files: changelog - As mentioned above, include the Debian version in the first line - Close your ITP bug in the first entry like so: * Initial release (closes: #634840 ) - Please update the time stamp to something more appropriate Done. changelog.in - Not sure if this will be useful in the future. You will most likely be editing the changelog manually (with the help of dch) changelog.in removed and left changelog alone. compat - I believe ideas about which version should be used for new packages varies from sponsor to sponsor, but 7 or 8 is most common nowadays. Of course this influences your build dependencies. Set to 7 control - Your standards version is very old. The current version is 3.9.2. Check what you need to change, and update accordingly. Updated standards version to 3.9.1 - Any reason for not having priority optional? None. Set priority from extra to optional. - Consider putting your Debian packaging in a VCS and add the appropriate tags Can you provide additional details about this? - I don't think it is appropriate to mention the website in the description. The Homepage field is made for this purpose. Fixed. - As mentioned above, improve the short description Done. - I am no native speaker but I believe a software is rather strange. If you want to improve the description you could ask on debian-l10n-engl...@lists.debian.org Changed software by program - I don't have understanding of wx2, but do your recommends work, i.e. does the package find the right version, depending on the development package used in the build-depends? Removed old dependency to wx2.6 which also generated the compilation error you point below. copyright - Not mandatory, but quite some sponsors want it: consider to change your copyright file to the DEP5 format [1]. - Please link to the versioned GPL in common-licenses. - You did not include the copyright information of all the files. The copyright file MUST list all the copyright holders and all licenses of ALL files in your project. Done dirs - I don't think you need this with this content. Done. File removed. docs - NEWS is empty, don't install it. Old (manually maintained in upstream) ChangeLog file renamed as NEWS file and added automatic ChangeLog generation from git - Why install README.ca and not README.es? Fixed. Now installs both. rules - I find the clean target a little strange, why copy the config.sub and config.guess there? Removed. - Clean up commented lines Done. - Not sure, but I think quite some options in your ./configure line are added by the builder automatically. Not sure also. Further comments: Please include a watch file. Included. Your package is newer than the latest upstream release. As you are upstream yourself, why didn't you create this new release yet? Just in case the debianization triggers some changes in upstream. The package FTBFS (fails to build from sourse) with the following error: configure: error: Couldn't find linux/videodev.h nor libv4l1-videodev.h Adding libv4l-dev to the build-depends helps to start building the package. It would help to build your own packages in a clean environment to check against such problems (and
Re: RFS: hashalot
* Adam Borowski kilob...@angband.pl, 2011-07-26, 13:32: I'd like to ask for a sponsor for an update to hashalot (a tool needed by cryptsetup, obsolete nowadays but some folks still use it). There's just one minor documentation fix, but I also nuked the whole debian/rules replacing it with oh-so-long dh two liner. Did you verify that your new d/rules does everything that the old one did? http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc Rather than debhelper (= 8.0.0) I'd simply use debhelper (= 8). That way the build-dependency will be satisfied by debhelper 8.0.0~bpo50+2, which is currently in backports/lenny. You bumped debian/compat, bumped standards version, added Homepage field - none of these things are documented in the changelog. -- 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/20110726123051.ga8...@jwilk.net
[done] RFS: libbs2b
Hi Andrew,
On 2011-07-25 13:48, Andrew Gainer wrote:
Alright, thanks for the clarification. I've bumped each package to
*-2, added changelog entries, and uploaded again.
I just uploaded it to the Debian's NEW queue. Thank you for the
contribution to Debian.
One minor detail (for the next upload) I didn't notice before: there is
no substitution variable '{misc:Pre-Depends}', so you can remove that
Pre-Depends line of libbs2b0 altogether.
You can send requests regarding bs2b packages directly to me for next
uploads.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer
--
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/20110726123540.GA28201@r500-debian
Re: RFS: hashalot
On Tue, Jul 26, 2011 at 02:30:51PM +0200, Jakub Wilk wrote: * Adam Borowski kilob...@angband.pl, 2011-07-26, 13:32: I'd like to ask for a sponsor for an update to hashalot (a tool needed by cryptsetup, obsolete nowadays but some folks still use it). There's just one minor documentation fix, but I also nuked the whole debian/rules replacing it with oh-so-long dh two liner. Did you verify that your new d/rules does everything that the old one did? Yes, actually it does a bit more: the old one failed to install the upstream changelog. I just checked that it cross-builds correctly too, dh is smart enough to disable the testsuite on cross builds like the old d/rules did. http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc Rather than debhelper (= 8.0.0) I'd simply use debhelper (= 8). That way the build-dependency will be satisfied by debhelper 8.0.0~bpo50+2, which is currently in backports/lenny. Good point, did it and re-uploaded to mentors (same URL). You bumped debian/compat, bumped standards version, added Homepage field - none of these things are documented in the changelog. I do believe that such entries are spam that is counterproductive and hides real changes: * debian/compat is implied by migrating to dh * updating standards is something every single sane sourceful upload does (lintian screaming at people helps here) * Homepage is just moving around stuff that used to be in debian/copyright Thus, I'd prefer to avoid useless entries. Of course, if giving up on this cosmetic issue would let me mooch an upload from you, I'll concede. Meow! -- 1KB // Yo momma uses IPv4! -- 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/20110726132414.ga4...@angband.pl
Re: jampal_02.01.05-1_amd64.changes REJECTED
Hi Torsten The looks/*.jar files are not distributed in the package. They are present in the source because I do distribute them with the Windows version of jampal. Jampal runs fine without them, and some of them are available as separate packages in Debian, so the user can install them if he wants to. What do I need to do about this? Do I need a repackaged source? Peter On 7/26/2011 9:30 AM, Torsten Werner wrote: Hi, there is no source code for the binaries looks/*.jar. Torsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. -- 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/4e2ed018.9090...@comcast.net
Re: jampal_02.01.05-1_amd64.changes REJECTED
Hi Peter, Am 26.07.2011 16:32, schrieb Peter Bennett: The looks/*.jar files are not distributed in the package. They are present in the source because I do distribute them with the Windows version of jampal. Jampal runs fine without them, and some of them are available as separate packages in Debian, so the user can install them if he wants to. What do I need to do about this? Do I need a repackaged source? yes, that would be an option. Torsten -- 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/4e2edfa6.30...@debian.org
Re: jampal_02.01.05-1_amd64.changes REJECTED
Hi Peter, On Tue, Jul 26, 2011 at 05:39:18PM +0200, Torsten Werner wrote: Am 26.07.2011 16:32, schrieb Peter Bennett: The looks/*.jar files are not distributed in the package. They are present in the source because I do distribute them with the Windows version of jampal. Jampal runs fine without them, and some of them are available as separate packages in Debian, so the user can install them if he wants to. What do I need to do about this? Do I need a repackaged source? yes, that would be an option. I guess that would be one preferred method. Or as you're upstream yourself you can as well leave the compiled *.jar out of any release tarball and compile them as part of the windows build process. Alternatively you can ship them in the *.zip for Windows and leave them excluded in the *.tar.gz for Linux. Which one you prefer is up to you. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: hashalot
Jakub, On Tue, Jul 26, 2011 at 06:28:23PM +0200, Jakub Wilk wrote: * Adam Borowski kilob...@angband.pl, 2011-07-26, 15:24: I'd like to ask for a sponsor for an update to hashalot (a tool needed by cryptsetup, obsolete nowadays but some folks still use it). There's just one minor documentation fix, but I also nuked the whole debian/rules replacing it with oh-so-long dh two liner. Did you verify that your new d/rules does everything that the old one did? Yes, actually it does a bit more: the old one failed to install the upstream changelog. FWIW, that's because of bumping debheleper compat to 7. I just checked that it cross-builds correctly too, dh is smart enough to disable the testsuite on cross builds like the old d/rules did. What raised my suspicion was that that the old d/rules had: | ifneq $(wildcard /usr/share/misc/config.sub) | cp -f /usr/share/misc/config.sub config.sub | endif | ifneq $(wildcard /usr/share/misc/config.guess) | cp -f /usr/share/misc/config.guess config.guess | endif dh certainly doesn't do anything like that. Granted, this code was silly[0] and, in this particular case, completely unnecessary[1], but I'd prefer to learn about such changes from the changelog. On the contrary! dh can very well do such things! But it's required to pass --with autotools_dev as argument (see man dh for more detail). Regarding the rest I'm perfectly with you that all intended changes are to be documented in debian/changelog even if they're abbreviated in a form like bump all of debian/compat and Build-Depends and debian/copyright to latest standards or something like this. But it needs to be clear that any change a DD can find in the debdiff is valid and intentionally put there. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: eviacam
Hi César, On Tue, Jul 26, 2011 at 02:30:24PM +0200, Cesar Mauri wrote: [...] control - Your standards version is very old. The current version is 3.9.2. Check what you need to change, and update accordingly. Updated standards version to 3.9.1 Without futher review of the actual package: Why not to 3.9.2? [...] - Consider putting your Debian packaging in a VCS and add the appropriate tags Can you provide additional details about this? The VCS (version control system) for the Debian packaging would be the Svn, Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly alioth.debian.org is a good starting point if you've nowhere else that's already publically offering your VCS tree. [...] rules - I find the clean target a little strange, why copy the config.sub and config.guess there? Removed. I hope you changed that to autotools-dev use. Usually it's a sensible default to use autotools-dev (e.g. dh --with autotools_dev) if your package does use autotools. [...] - Not sure, but I think quite some options in your ./configure line are added by the builder automatically. Not sure also. See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact details. -- Best regards, Kilian signature.asc Description: Digital signature
Re: jampal_02.01.05-1_amd64.changes REJECTED
Thanks Kilian I will create a repackaged source with a new version number 02.01.05-2, with the looks directory excluded. I will add a get-orig-source target that creates the repackaged source, and try to conform with Debian developers Reference (6.7.8.2 Repackaged upstream source). At this time I will not change the upstream source. Peter On 7/26/2011 12:29 PM, Kilian Krause wrote: Hi Peter, On Tue, Jul 26, 2011 at 05:39:18PM +0200, Torsten Werner wrote: Am 26.07.2011 16:32, schrieb Peter Bennett: The looks/*.jar files are not distributed in the package. They are present in the source because I do distribute them with the Windows version of jampal. Jampal runs fine without them, and some of them are available as separate packages in Debian, so the user can install them if he wants to. What do I need to do about this? Do I need a repackaged source? yes, that would be an option. I guess that would be one preferred method. Or as you're upstream yourself you can as well leave the compiled *.jar out of any release tarball and compile them as part of the windows build process. Alternatively you can ship them in the *.zip for Windows and leave them excluded in the *.tar.gz for Linux. Which one you prefer is up to you. -- 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/4e2efa78.7000...@comcast.net
Re: jampal_02.01.05-1_amd64.changes REJECTED
Hi Peter, On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote: Thanks Kilian I will create a repackaged source with a new version number 02.01.05-2, with the looks directory excluded. I will add a get-orig-source target that creates the repackaged source, and try to conform with Debian developers Reference (6.7.8.2 Repackaged upstream source). At this time I will not change the upstream source. please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball should have an upstream version of 02.01.05~dfsg. If you feel extra caution for new repackaging mimic should already be added use 02.01.05~dfsg1-1. -- Best regards, Kilian signature.asc Description: Digital signature
Please try expo.debian.net -- a replacement for mentors.debian.net
Hi all people on debian-mentors, Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. It has the following improvements over http://mentors.debian.net/ : * Maintainable code base * More color on the front page * Publicly-shown lintian results I have been spending the past couple of days at Debconf fixing up the code and the deployment. I'm hereby asking for testing and feedback: * Please try uploading a package and tell me if it works (especially tell me if it fails!). * Please tell me if there are features we need before it can replace mentors.debian.net. Frankly, I think it's ready as-is! Go to http://expo.debian.net/ to try it. My goal with this debexpo work is to get the app and the deployment into a usable, documented state so it can replace mentors.debian.net. Then I will shift into the background and do only patch review and documentation writing. Anyone interested in working on Debexpo, a Python + Pyons web app, should grab the source code. Some fixes require changing only the templates, and I promise to review your patches quickly (within four days, tops). Bug tracker: https://alioth.debian.org/tracker/index.php?group_id=100127atid=413115 (You can get the latest deployed source from git://expo.debian.net/live . I will push that to Alioth once I sort out some confusion with my SSH key.) -- Asheesh. P.S. There is no known way to change the Needs a sponsor field. Just delete the package if you don't need a sponsor, for now. P.P.S. Any bugs that can be fixed by just editing the templates, I hope to see people submitting patches for! -- 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/alpine.deb.2.00.1107261224050.6...@rose.makesad.us
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Asheesh, On Tue, Jul 26, 2011 at 01:55:00PM -0400, Asheesh Laroia wrote: Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. that's great news! I think you saw already at http://expo.debian.net/package/trafficserver: sh: uscan: command not found Looks like there's a path missing for your uscan test. -- Best regards, Kilian signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Asheesh, Le mardi 26 juil. 2011 à 19:55:00 (+0200 CEST), Asheesh Laroia a écrit : Hi all people on debian-mentors, Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. Thanks for working on this. Looks very promising! On the package details page, it would be great if URL's could be clickable (Homepage, VCS-Browser). Also Lintian tags could be linked to their description on lintian.d.o I also think it is not necessary to show missing optional fields (eg. various VCS-* fields). It may also help to know whether the package is already in Debian (with a link to packages.d.o in order to know more about the history of the uploads) or if it is a new package. As from the maintainer personal package archive page, I understand that binary packages will be made publicly available? The page states 'deb ...' entries in sources.list. If so, I think it is a bad idea. Only source packages should be available to avoid people use this as a standard repository (I remember it used to be the case for mentors.d.n). Keep up the good work. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- 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/20110726183736.gg7...@kirya.net
Re: RFS: espctag
Le lundi 25 juillet 2011, Kilian Krause a écrit : having already signed off the according lib, I've also built, signed and uploaded this package. ;-) Hi, Thank you. -- Jérôme SONRIER signature.asc Description: This is a digitally signed message part.
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi, On Tue, Jul 26, 2011 at 08:37:36PM +0200, Julien Valroff wrote: It may also help to know whether the package is already in Debian (with a link to packages.d.o in order to know more about the history of the uploads) or if it is a new package. packages.qa.d.o please. And while we're writing the wishlist, please also inclulde: * output from lintian -IX --pedantic * changelog entry with colorized RC-bugs that are fixed * whether or not the orig.tar.gz is original * if there is a previous version in debian, debdiff to the source basically more similar to http://ftp-master.debian.org/new.html -- Best regards, Kilian signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Tue, 26 Jul 2011, Julien Valroff wrote:
Hi Asheesh,
Le mardi 26 juil. 2011 à 19:55:00 (+0200 CEST), Asheesh Laroia a écrit :
Hi all people on debian-mentors,
Debexpo is a replacement for http://mentors.debian.net/. I hereby
request testers! It is of beta quality -- I think it works fully
and has enough features to replace mentors.debian.net.
Thanks for working on this.
Looks very promising!
(-:
I am grateful to all the people who put energy into this: Signum
(Christopher Haas) and Jonny Lamb, first, who started the project. Andrey
(wRAR), who helped bring the project back to life about nine months ago.
Christine Spang, for providing the hosting. Arno Toell and Karl Goetz, for
urging me on in #debexpo, filing bugs, and giving feedback. Jan Dittberner
and Ondrej Certik and Paul Wise and Serafeim Zanikolas, for the code they
committed and pushed to git. Signum again, for his patience with me over
the past year.
It's a lot of names, and it's been a lot of work for all those people!
My role here, as I will try to repeat and make clear, is to provide our
community with something that we can use, and that we can improve. My role
will not be to build any more features, but instead focus entirely on
making sure that community maintenance is possible.
I will be quite happy to deploy patches written by others. The policy for
SSH access to the deployment is that anyone who successfully gets a patch
merged may have SSH access to the deployment.
To encourage that to happen faster, I'm going to reply to many of these
requests with the information it would take to write a fix. I won't
myself. If the community wants it fixed, someone other than me is going to
have to fix it. I'll try to rank things in difficulty 0 (stringfix) to 5
(a full day's work).
Some of the more difficult or sysadmin-esque issues I might handle myself,
but in general the above is what I'll do.
On the package details page, it would be great if URL's could be
clickable (Homepage, VCS-Browser).
Difficulty: 1
To fix this, you'll probably want to add a 'linkify' string processor to
the template system.
Steps to fix:
Step 0: Do a 'git clone' of debexpo and set up a dev environment
Step 1: Add an htmlify function to the app
You can copy-paste this one, so long as you cite it, and rtain the Apache
License.
https://github.com/facebook/tornado/blob/master/tornado/escape.py
Step 2: Change the templates to use that htmlify function
You can be inspired by
http://188.40.52.54/cgit/anzu/commit/demos/chat?h=performanceid=f732f98063f8a0bf9f7e331876964bedbbdc8462
Step 3: Make sure it works
In the near future I will get the expo-dev.debian.net site working, but
until then, test locally.
Step 4: Submit a patch
'git format-patch origin/master' will generate some files. Email them to
the debexpo list (debexpo-devel at lists.alioth.org)
Also Lintian tags could be linked to their description on lintian.d.o
Difficulty: 0.5 (super easy; requires writing code)
Step 0: Do a git clone
Step 1: Edit debexpo/plugins/lintian.py
The call to:
self.failed(outcome, output, severity)
(currently line 70) is what passes the information to be logged into the
database, where the package page will pull it out. 'output' is the line of
text from lintian.
Change it so that outcome is an HTML string that contains the link.
I also think it is not necessary to show missing optional fields (eg.
various VCS-* fields).
Difficulty: 0 (super easy)
Step 0: Get a git clone
Step 1: Edit debexpo/plugins/controlfields.py
This line:
self.info('%s-is-not-present' % item.lower(), None)
Just remove it.
Step 2. Submit a patch to the mailing list
It may also help to know whether the package is already in Debian (with
a link to packages.d.o in order to know more about the history of the
uploads) or if it is a new package.
That would be great!
Difficulty: 1.5 (requires writing a plugin, and understanding how plugins
are written -- but they are quite easy)
Step 0: Get a git clone
Step 1: Read a sample plugin
Take a look at debexpo/plugins/ubuntuversion.py
That's a good, simple quality-assurance plugin.
Step 2: Write a new plugin to check if the package is in Debian
You'd probably want to do a urllib.urlopen() on some URL --
packages.debian.org/sid/ + packagename, maybe -- and check its value. If
the package is in Debian, generate a string that contains a link to the
package page.
You pass that down the chain by just calling self.info() (if you descend
from BasePlugin, as you should).
Step 3: (Preferable but not necessary) Write a test
It would be great if you submit a test case for this. If you're not sure
how to do that, I would explain how.
Step 4: Submit a patch
As from the maintainer personal package archive page, I understand
that binary packages will be made publicly available? The page states
'deb ...' entries in sources.list. If so, I think it is a bad idea. Only
source packages should be
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Tue, 26 Jul 2011, Kilian Krause wrote:
Hi,
On Tue, Jul 26, 2011 at 08:37:36PM +0200, Julien Valroff wrote:
It may also help to know whether the package is already in Debian (with
a link to packages.d.o in order to know more about the history of the
uploads) or if it is a new package.
packages.qa.d.o please.
And while we're writing the wishlist, please also inclulde:
Same story from before. I'm going to write up how these can be fixed!
* output from lintian -IX --pedantic
Difficulty: 0 (super easy)
(step 0: get the latest code from git)
Step 1: edit debexpo/plugins/lintian.py
Right now, we call lintian like this:
output = commands.getoutput('lintian %s' % self.changes_file)
You can adjust the command however you see fit.
Step 2: Submit a patch
* changelog entry with colorized RC-bugs that are fixed
Difficulty: 1
(step 0: get the latest code from git)
Step 1: read how we do I/O to the bug tracker now
Read debexpo/plugins/closedbugs.py
Step 2: Adjust that plugin, or write a new one, to generate the new
report you want
Step 3: Make sure it shows up properly w/r/t HTML escaping
Step 4: Submit a patch
* whether or not the orig.tar.gz is original
How do we detect this programmatically?
* if there is a previous version in debian, debdiff to the source
basically more similar to http://ftp-master.debian.org/new.html
That would be a really good thing! I would suggest tying that to a new
URL. If there is a previous version in Debian, the package page on
expo.debian.net can link to the expo.debian.net/$package/$version/debdiff
URL.
Difficulty: 2 (a non-trivial bit of code, but no major architecture
changes)
Step 0: Get the code
Step 1: Read the lintian plugin to have a sense of how a non-trivial
plugin works
That's in debexpo/plugins/lintian.py
Step 2: Read the code that makes the package page display
That would be:
* debexpo/config/routing.py
* debexpo/controllers/package.py
* debexpo/model/packages.py
* debexpo/templates/package/index.mako
Step 3: Create a new URL that displays nothing
Do that by creating a new method in debexpo/controllers/package.py and
tying it to a route in routing.py.
Make sure your browser successfully loads it.
Step 4: Create a new plugin that will store these debdiffs
You'll need to make a new model, also.
Step 5: Make the plugin actually run debdiff, which will include
downloading the package from Debian
Step 6: Make the plugin store those results in the database
Step 7: Make the package info page link to the debdiff URL if
there is any debdiff content
Step 8: Make the debdiff URL actually show the debdiff contents
Step 9: Submit a patch
-- Asheesh.
--
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/alpine.deb.2.00.1107261538490.9...@rose.makesad.us
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On 2011-07-26 22:01, Asheesh Laroia wrote:
On Tue, 26 Jul 2011, Kilian Krause wrote:
[...]
* output from lintian -IX --pedantic
Difficulty: 0 (super easy)
(step 0: get the latest code from git)
Step 1: edit debexpo/plugins/lintian.py
Right now, we call lintian like this:
output = commands.getoutput('lintian %s' % self.changes_file)
You can adjust the command however you see fit.
Step 2: Submit a patch
[...]
Hi
To anyone interested in this, it might be a good idea to set up a
lintianrc file and use it (e.g. via --cfg) to keep the options separated
from the code.
~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/4e2f1e8f.3000...@thykier.net
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Asheesh, On Tue, Jul 26, 2011 at 04:01:26PM -0400, Asheesh Laroia wrote: On Tue, 26 Jul 2011, Kilian Krause wrote: [...] * whether or not the orig.tar.gz is original How do we detect this programmatically? Thanks for taking the time to even explain that detailled how to get the code working in the new way we're all proposing! That's an awesome help for any of us having the free time to actually code something together and lend this new project a helping hand! As for the above, I'll happily throw in the technical background I had in mind: - detect whether debian/watch is there and useful - if so and if the version is not mangled (like ~dfsg etc.), run uscan --force-download in a patched version that does not involve uupdate or svn-update (i.e. does call any programs that an attacker might want to turn against us) - diff that against the orig.tar.* uploaded - if different, put up a warning, unpack both and list the diff -urN if any I'm not entirely sure if we want to run get-orig-source targets to rebuild ~dfsg tarballs and compare them. Or rather how we could sandbox that process to make sure we're on the safe side but still don't allow any attacker to abuse the system. -- Best regards, Kilian signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kilian, On 26.07.2011 22:25, Kilian Krause wrote: I'm not entirely sure if we want to run get-orig-source targets to rebuild ~dfsg tarballs and compare them. I don't think, you really want to consider to run /anything/ which has been supplied by a completely untrusted sponsoree. Being it a full or partial or just a get-orig-source target run. This is an immediate risk for the infrastructure, being it well protected or not for little benefit. (just my 2c) - -- 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/ iQIcBAEBAgAGBQJOLyTpAAoJEMcrUe6dgPNtB40P/jKI4+ml59JN8jZ6Ps+3pDic pgU8lVMjb1QMeRsCc4RjM14+khYmjgja31HpNP/s3GeDnHdjDZha29oPAmTuGLkt 9CC05g9dELKS/eRiY7JHOeEG6o/Y9csnQR96bhaAzcHiSmYqF1NMj4Gl4pPN5RT6 WTOTLog1E6S5kcdfAvtCo7RWU1OWdOV6u8yI+fEFpsEFnc4bx3lIkbJXXI3vJVjH uhWDIP1zDBUmw6Wn8LAWpa9wQPbonx2lX/ByzaccnraCk/fF36hDotoDnhqDM6iG k7d5jo06xU/1HidtZ1BJIFMYCKP8DJT/sdExXjA+AqzC+g04fArQXMftRVRofRkb ffAlTy+kP/PMv4SnWwRtnqdUpoBoU5VGKSWJsiz8MjUdU8OQ4x0prK+pF0BCvShe ZtklUo4JAs3WYOwuTtb/VCDtcHPzZr9RzgV9FHin0Pz7zW4bD51ewgRWLN/rWYip Pbt3BQKp1ZxtrvfA+FabocKyvvC55vjhuG/XY07hCSUg0KEIppg9lMq3PXBkDPy9 y4laBriwO/SyfBl/nLRhSVs8May3bNfu1nQa7XlFFar326O95Gdh6S7jWfBSnDqD RqfhnhEPSHJsrI1dasS4Ay1BvrmNklGCG98K9Vy1vfyBzOejG/8BeE+TPrqv1xWB 1aRy1WEJhg/jhmjlOaI+ =Ou/Z -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/4e2f24ea.20...@toell.net
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
* Kilian Krause kil...@debian.org, 2011-07-26, 22:25: - detect whether debian/watch is there and useful - if so and if the version is not mangled (like ~dfsg etc.), run uscan --force-download in a patched version that does not involve uupdate or svn-update (i.e. does call any programs that an attacker might want to turn against us) It's a shame that uscan is insecure-by-design. I use my wrapper script to add a bit sanity to it: https://bitbucket.org/jwilk/debian-misc/src/tip/upscan -- 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/20110726204044.ga9...@jwilk.net
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Arno, On Tue, Jul 26, 2011 at 10:34:50PM +0200, Arno Töll wrote: On 26.07.2011 22:25, Kilian Krause wrote: I'm not entirely sure if we want to run get-orig-source targets to rebuild ~dfsg tarballs and compare them. I don't think, you really want to consider to run /anything/ which has been supplied by a completely untrusted sponsoree. Being it a full or partial or just a get-orig-source target run. This is an immediate risk for the infrastructure, being it well protected or not for little benefit. that was pretty much my point. I've currently no idea on how to secure the setup enough so that we can safely sandbox the get-orig-source call sufficiently to be terminated unconditionally after a timeout from the outside and unable to speak to anything except some remote (web) servers and a local disk cachedir where we'd pull a file from once completed. I bet however it'd make an interesting SELinux challenge to put such thing together. ;-) That's nothing urgent and nothing that we should put efforts into now(TM). -- Best regards, Kilian signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Jakub, On Tue, Jul 26, 2011 at 10:40:44PM +0200, Jakub Wilk wrote: * Kilian Krause kil...@debian.org, 2011-07-26, 22:25: - detect whether debian/watch is there and useful - if so and if the version is not mangled (like ~dfsg etc.), run uscan --force-download in a patched version that does not involve uupdate or svn-update (i.e. does call any programs that an attacker might want to turn against us) It's a shame that uscan is insecure-by-design. I use my wrapper script to add a bit sanity to it: https://bitbucket.org/jwilk/debian-misc/src/tip/upscan that one isn't packaged by chance and scheduled to also be able to do multiple orig.tar.* as per dpkg-source v3? ;-) Would make it a perfect drop in replacement for my review process. *g* -- Best regards, Kilian signature.asc Description: Digital signature
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Tue, 26 Jul 2011, Kilian Krause wrote: Hi Asheesh, On Tue, Jul 26, 2011 at 04:01:26PM -0400, Asheesh Laroia wrote: On Tue, 26 Jul 2011, Kilian Krause wrote: [...] * whether or not the orig.tar.gz is original How do we detect this programmatically? Thanks for taking the time to even explain that detailled how to get the code working in the new way we're all proposing! That's an awesome help for any of us having the free time to actually code something together and lend this new project a helping hand! As for the above, I'll happily throw in the technical background I had in mind: - detect whether debian/watch is there and useful - if so and if the version is not mangled (like ~dfsg etc.), run uscan --force-download in a patched version that does not involve uupdate or svn-update (i.e. does call any programs that an attacker might want to turn against us) - diff that against the orig.tar.* uploaded - if different, put up a warning, unpack both and list the diff -urN if any Out loud, I just found myself saying: Who so cool! That would be pretty awesome. I would completely love to see that. I'm not entirely sure if we want to run get-orig-source targets to rebuild ~dfsg tarballs and compare them. Or rather how we could sandbox that process to make sure we're on the safe side but still don't allow any attacker to abuse the system. To do get-orig-source would be pretty amazingly great. You're right that safety would a challenge when running code from within the debian/rules file. It would be pretty superb to lock that process into a chroot. I would suggest using something like sbox http://packages.debian.org/lenny/sbox-dtc to do it. -- Asheesh. -- 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/alpine.deb.2.00.1107261652250.9...@rose.makesad.us
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Asheesh, On Tue, Jul 26, 2011 at 05:00:45PM -0400, Asheesh Laroia wrote: On Tue, 26 Jul 2011, Kilian Krause wrote: [...] - detect whether debian/watch is there and useful - if so and if the version is not mangled (like ~dfsg etc.), run uscan --force-download in a patched version that does not involve uupdate or svn-update (i.e. does call any programs that an attacker might want to turn against us) - diff that against the orig.tar.* uploaded - if different, put up a warning, unpack both and list the diff -urN if any Out loud, I just found myself saying: Who so cool! That would be pretty awesome. I would completely love to see that. :-) I'm not entirely sure if we want to run get-orig-source targets to rebuild ~dfsg tarballs and compare them. Or rather how we could sandbox that process to make sure we're on the safe side but still don't allow any attacker to abuse the system. To do get-orig-source would be pretty amazingly great. You're right that safety would a challenge when running code from within the debian/rules file. It would be pretty superb to lock that process into a chroot. I would suggest using something like sbox http://packages.debian.org/lenny/sbox-dtc to do it. just for the record: neither chroot nor sbox will be sufficient to protect a production system. Maybe LXC will be, maybe SELinux, maybe XEN. That's the least protection I'd settle for. Maybe even a combination of those (if we put up an official description we'll be pretty open to being hacked due to the foreseeable results of our architecture). Thus neither document too publically how we do it nor what the exact internal versions are. This being said, of course bringing more complexity will also make the construct more fragile and more error-prone (read: more unsafe). That's why I said it'd be a challenge to put this up in a manageable and yet secure way. Most probably an interpreter with a whitelisting of commands will come in most handy in the end. ;-) -- Best regards, Kilian signature.asc Description: Digital signature
Re: jampal_02.01.05-1_amd64.changes REJECTED
Kilian I will have to use +dfsg1 instead of ~dfsg1, because ~ sorts before the base version and now uscan thinks there is a newer version available (unless I have failed to understand something here - which is quite likely) jampal: Newer version (02.01.05) available on remote site: http://qa.debian.org/watch/sf.php/jampal/jampal-source-02.01.05.tar.gz (local version is 02.01.05~dfsg1) jampal: Successfully downloaded updated package jampal-source-02.01.05.tar.gz and symlinked jampal_02.01.05.orig.tar.gz to it On 7/26/2011 2:00 PM, Kilian Krause wrote: Hi Peter, On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote: Thanks Kilian I will create a repackaged source with a new version number 02.01.05-2, with the looks directory excluded. I will add a get-orig-source target that creates the repackaged source, and try to conform with Debian developers Reference (6.7.8.2 Repackaged upstream source). At this time I will not change the upstream source. please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball should have an upstream version of 02.01.05~dfsg. If you feel extra caution for new repackaging mimic should already be added use 02.01.05~dfsg1-1. -- 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/4e2f3401.8000...@comcast.net
Re: RFS: eviacam
Hi, Thanks Kilian for your feedback which helped me to improve the package. I've updated and uploaded it again to the mentors site. The package appears to be lintian clean. [...] Updated standards version to 3.9.1 Without futher review of the actual package: Why not to 3.9.2? I had chosen that version to make lintian (stable version) happy. OK. Changed to 3.9.2 (and updated lintian on my box to the latest version). [...] - Consider putting your Debian packaging in a VCS and add the appropriate tags Can you provide additional details about this? The VCS (version control system) for the Debian packaging would be the Svn, Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly alioth.debian.org is a good starting point if you've nowhere else that's already publically offering your VCS tree. I already use git on sf.net for upstream. May be the best approach is to adopt the scheme described here [1]. Isn't it? [1] http://documentation.debian-projects.org/other/debian-packaging-git/ [...] rules - I find the clean target a little strange, why copy the config.sub and config.guess there? Removed. I hope you changed that to autotools-dev use. Usually it's a sensible default to use autotools-dev (e.g. dh --with autotools_dev) if your package does use autotools. Finally I've decided to adopt the newer debian/rules format (shorter) and I've added the --with autotools_dev option. [...] - Not sure, but I think quite some options in your ./configure line are added by the builder automatically. Not sure also. See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact details. Not a problem any more with the new debian/rules format. Best regards, César Mauri -- 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/4e2f3ca8.5080...@crea-si.com
Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it
Kilian Krause kil...@debian.org writes: Hi Ben, On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote: Lintian recommends (via tag ‘debian-rules-missing-recommended-target’): = N: Note that the following form is recommended however: N: N: build: build-arch build-indep N: build-arch: build-stamp N: build-indep: build-stamp N: build-stamp: N: build here = If you're sure that you want to use dh but .PHONY then just put into your rules something like: build-indep: dh $@ build-arch: dh $@ build: build-arch build-indep No need for a stamp as dh is already producing stamps internally. This doesn't match Lintian's recommendation. Nor does the common ‘%:’ style rule. Should Lintian's recommendation be changed? -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\Brain, but why would anyone want to see Snow White and the | _o__) Seven Samurai?” —_Pinky and The Brain_ | Ben Finney pgp2LamnFJtDj.pgp Description: PGP signature
Re: Looking for mentor to package dolibarr erp/crm - ITP 634783
I made all changed suggested by all answers i recevied after my first mentor request to upload Dolibarr ERP CRM : Package provided is now a source package built with dpkg-source : DSC:http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.dsc Source tgz: http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.tar.gz I still provide binary built with dpkg if needed (but should not): Binary: http://www.dolibarr.org/files/debian/dolibarr_3.1.0-dev_all.deb I removed most Lintian warnings. There is still 3 kinds of warnings: * W: embedded-javascript-libraryThis can't be avoid because package use embedded library that are different version than one provided by debian default packages and are modified specially for Dolibarr software. * W: embedded-php-library This can't be avoid because package use embedded PHP library that are different version of one provided by debian default packages and are modified specially for Dolibarr software. * W: extra-license-file This can't be avoid without removing licence files of js and php embedded library (see 2 previous points). Licence of embedded libraries are reported also into the copyright file. I tried to provide a complete copyright file, fix packages dependencies, removed not necessary embedded libraries (those remainings can't be removed and we can't use another version than the one embedded). I am waiting next feedbacks with this second try to guide me if something must be changed/fixed again. Le 21/07/2011 01:53, Arno Töll a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Laurent, On 20.07.2011 23:05, Laurent Destailleur (eldy) wrote: The package can be found on URL: http://www.dolibarr.org/files/dolibarr-3.1.0-dev.deb and Because Dolibarr is a PHP application, binary package is also source package (no compiled binaries inside). I'm afraid, but this is not true. For sponsoring, a source package is required, not a binary (.deb) package, being architecture independent or not. So please, re-upload your source package if you want to have it reviewed. However, before you do, please fix problems with it. Lintian tests report no errors. Please run lintian --pedantic -E -I dolibarr-3.1.0-dev.deb (or even better on your *.changes file) and come back if you reduced Lintian warnings to something in a more sane magnitude. Moreover please read again the maintainer guide and the policy. You are massively abusing most^W^Wsome standards, including but not limited to package relationships, embedded code copies, purpose of maintainer scripts, source code distributions and a massively too shallow copyright file. - -- 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/ iQIcBAEBAgAGBQJOJ2pgAAoJEMcrUe6dgPNtWSIQALARqTr3dY4yBKiqcXVHw3+s /CplriZKJVifQ5PjJNROLcr6G6tgLZTTvA4SPvQ5fWZVPXd47J3wm1XqUndrj+Ia 4Cm32TCpJvh+UY4ukBdtNRBb9whLVkNwp0KChBprINYoatB4e7jNYq8rdNejfoxX RMy9gBrWaSTchQ+2sNrOWm/POpnPo+4dFCc7sTeUnYZaJTCZyFYm8YoTT2tTlscD pyoigp5Ihxg6iY8gfyHR5yJw1Hp3NKmLlSlRdK5vkYU483CA4ZU7sA0epzkDQvix KcaV/aGm1xmZfKR5OyR+Jhb8vSx3hs+mGlbpDyQxWDX7Cr8JBUs0krKmgAXmAzRy ODSffhbQPLoJ1F5nd88C+9bhnFvWCPS7diEqA+zl+Wexz2iHoVxQQ42QTNDw4f4M RYREkK7r1uSt3P3MAq9UnFQwQJm43opp53O4z7SwzUT4bpic0L8ycaXI+/qzAbLE HTtqQK5XqSZHGAvpLBMh7PM6psFc46BtCduWAbOt41Y1/4TeHNKpykFov60nUDq6 HlgoE+IH8hGTGsJkmyoUOdxCA4VBheYy0FT44c21WU1IZ4PS+9wF2BdWIb3WZ7YG SCGFUdxe3/p8D8x43BaAGRHn2TXR94F1xno8SEcpj3MZDGMbQPbK/o0DEM76rG5q xPudhs47Q4wutKz8Q8M1 =h3gv -END PGP SIGNATURE- -- Eldy (Laurent Destailleur). --- EMail: e...@destailleur.fr Web: http://www.destailleur.fr Dolibarr (Project leader): http://www.dolibarr.org To make a donation for Dolibarr project via Paypal: cont...@destailleur.fr AWStats (Author) : http://awstats.sourceforge.net To make a donation for AWStats project via Paypal: cont...@destailleur.fr AWBot (Author) : http://awbot.sourceforge.net CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net -- 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/4e2f4598.1060...@destailleur.fr
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Asheesh Laroia ashe...@asheesh.org writes: Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. Like many people, I have far too many online credentials already. Signing up to a new service with new site-specific credentials is a barrier to entry. What hope is there for this new service to make use of existing credentials from mentors.debian.net? -- \ “Working out the social politics of who you can trust and why | `\ is, quite literally, what a very large part of our brain has | _o__) evolved to do.” —Douglas Adams | Ben Finney -- 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/8762mor6af@benfinney.id.au
Re: jampal_02.01.05-1_amd64.changes REJECTED
I have repackaged the source, built, signed, uploaded Version is now 02.01.05+dfsg1-1 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/j/jampal - dget http://mentors.debian.net/debian/pool/main/j/jampal/jampal_02.01.05+dfsg1-1.dsc If all is OK please upload it. Thanks Peter On 7/26/2011 2:00 PM, Kilian Krause wrote: Hi Peter, On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote: Thanks Kilian I will create a repackaged source with a new version number 02.01.05-2, with the looks directory excluded. I will add a get-orig-source target that creates the repackaged source, and try to conform with Debian developers Reference (6.7.8.2 Repackaged upstream source). At this time I will not change the upstream source. please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball should have an upstream version of 02.01.05~dfsg. If you feel extra caution for new repackaging mimic should already be added use 02.01.05~dfsg1-1. -- 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/4e2f4abc@comcast.net
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Wed, 27 Jul 2011, Ben Finney wrote: Asheesh Laroia ashe...@asheesh.org writes: Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. Like many people, I have far too many online credentials already. Signing up to a new service with new site-specific credentials is a barrier to entry. What hope is there for this new service to make use of existing credentials from mentors.debian.net? There are a few major options: 1) Import the mentors.debian.net authentication data 2) Integrate OpenID logins, so you can use existing credentials (e.g. Google Account, your own personal OpenID, 3) Just use a silly password like 'password' 4) See if DSA will create a central authentication web thing, which they are considering (called Shibboleth) 5) Login by asking you to GPG-sign a random message generated by the backend I'm open to other ideas. One difficulty for this is that I don't plan to write much new code for debexpo -- just enough to get it to the point where it can replace mentors.debian.net. But if we come to a community decision about how we want login to work, and specify it well, I think we can find the energy to build it. -- Asheesh. -- 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/alpine.deb.2.00.1107261916420.9...@rose.makesad.us
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
On Tue, 26 Jul 2011, Asheesh Laroia wrote: * Please tell me if there are features we need before it can replace mentors.debian.net. Arno found one showstopper bug, and I just fixed it. If there are any others, let me know. Otherwise, about 24 hours from now, I plan to ask signum if we can turn mentors.debian.net off, and make it a debexpo instance. That will mean losing the existing uploaded packages. But I think that's not such a huge loss. (If Signum is around, and we can work out a way to do it, I will try to copy the accounts over.) -- Asheesh. -- 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/alpine.deb.2.00.1107262007010.18...@rose.makesad.us
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Asheesh Laroia ashe...@asheesh.org writes: 2) Integrate OpenID logins, so you can use existing credentials (e.g. Google Account, your own personal OpenID, This would be the option I'd most like to see, for the reason you give: it allows a huge number of existing identities, including identities managed by the person and not a corporation, to be re-used if the visitor chooses to. One difficulty for this is that I don't plan to write much new code for debexpo -- just enough to get it to the point where it can replace mentors.debian.net. But if we come to a community decision about how we want login to work, and specify it well, I think we can find the energy to build it. +1 to having DebExpo be an OpenID Relying Party for registration and login. URL:http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Practices -- \ “Pinky, are you pondering what I'm pondering?” “I think so, | `\ Brain, but three round meals a day wouldn't be as hard to | _o__) swallow.” —_Pinky and The Brain_ | Ben Finney -- 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/871uxcr1tu@benfinney.id.au
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Asheesh Laroia ashe...@asheesh.org writes: Otherwise, about 24 hours from now, I plan to ask signum if we can turn mentors.debian.net off, and make it a debexpo instance. Gak! I didn't realise the proposal was for existing mentors.debian.net service to be replaced immediately. In that case, please ensure existing credentials continue to work for login to the new service. (If Signum is around, and we can work out a way to do it, I will try to copy the accounts over.) Thank you in advance. -- \ “Everything you read in newspapers is absolutely true, except | `\for that rare story of which you happen to have first-hand | _o__) knowledge.” —Erwin Knoll | Ben Finney -- 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/87wrf4pn60@benfinney.id.au
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Asheesh Laroia wrote: If there are any others, let me know. Otherwise, about 24 hours from now, I plan to ask signum if we can turn mentors.debian.net off, and make it a debexpo instance. That will mean losing the existing uploaded packages. But I think that's not such a huge loss. Don't do that. Such actions tend to piss off a significant portion of the users. Someone may *just* have spent half a day figuring m.d.n out, creating an account, and uploading their packages. Not saying m.d.n shouldn't go away, but don't treat people's work as if it was worthless (not such a huge loss, meaning not worth my time to migrate the data). Just some advice based on experience. -Julian signature.asc Description: This is a digitally signed message part.
