Re: fastest hack-build-run iteration
Paul Wise p...@debian.org wrote on 2012-02-21 09:28: On Tue, Feb 21, 2012 at 8:40 AM, David Roguin wrote: I'm making some changes to the evolution package and every time I want to test a tiny change I build a deb, install and run it. As you can imagine that takes a lot of time. That's why I'm asking if there's a faster way to iterate over changes. maint-guide used to recommend running ./debian/rules binary for that, not sure if it does now. And use ccache for using compiling results for the next time. --- Have a nice day. Joachim (Germany) -- 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/20120221095845.7f516...@jupiter.home
Re: fastest hack-build-run iteration
David Roguin nesda...@gmail.com wrote on 2012-02-20 21:40: Hi, I'm making some changes to the evolution package and every time I want to test a tiny change I build a deb, install and run it. As you can imagine that takes a lot of time. That's why I'm asking if there's a faster way to iterate over changes. Thanks a lot! Another way is compiling sources without making debian packages: e.g. make ... make install e.g. autoreconf ... make ... make install e.g. cmake ... make ... make install --- Have a nice day. Joachim (Germany) -- 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/20120221100127.29a7a...@jupiter.home
regarding the code to test from Carl-Valentin Schmitt
I am not subscribed to this list. Hi! I suggest you not to put any more energy into it - in case you didn´t already notice yourself. From what I have seen from Carl-Valentin Schmitt - whether that is his real name or not I do not know - on debian-user-german[1], kernel-testers mailinglist[2] and elsewhere for example about a hack of having a password that is one terabyte long, I do not have the impression that it is reasonable to expect any code from him to do anything useful. I would also be reluctant about the usefulness of his other posts - except for some amusement. At least not based on the posts I have seen from him so far. And it is not that we - quite some experienced debian-user-german readers - didn´t try to teach him some useful stuff about Debian and Linux initially. [1] I think one thread should be enough as an example: e-mail verpasst wegen github http://lists.debian.org/debian-user-german/2012/02/msg00645.html (in german tough) [2] holy bim-bam ! kernels obviously have no bugs ! http://permalink.gmane.org/gmane.linux.kernel.kernel-testers/11600 Thanks, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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/201202211029.49272.mar...@lichtvoll.de
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
block 660125 with 660128 thanks Hi Daniel, Daniel Martí wrote: I am looking for a sponsor for my package heybuddy. * Package name: heybuddy Version : 0.2.3-1 Upstream Author : Jezra Johnson Lickter je...@jezra.net * URL : http://www.jezra.net/projects/heybuddy * License : GPLv3 Section : net It builds those binary packages: heybuddy - light identi.ca microblogging client I had a look at your package: - Your watch file doesn't seem to work; I get the following warning: uscan warning: In debian/watch, no matching hrefs for watch line http://launchpad.net/heybuddy/+download http://launchpad.net/heybuddy/.*/heybuddy-(.*)\.tgz - You should drop the update-menus line in debian/postinst, it's already added by debhelper. In the same file, you run compileall unconditionally; I guess it should only run during configure. You do not honor the settings from /etc/python/debian_config [1]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation These last two issues would be moot if you used dh_python2. - Your debian/rules could be much simpler if you used dh --with python2 $@ possibly with a few overrides. - Why is your man page in section 7? It seems to me it should be in section 1. It's also a bit scarce, it doesn't even tell me how to run heybuddy. If it has no options at all, you should state that fact. And please consider removing the AUTHORS and COPYRIGHT sections (see man-pages(7)). - The man page lists troorl as copyright holder for the 2009-2010 period, but debian/copyright doesn't mention it. - Do you really mean to Recommend both python-gtkspell and aspell? Seems like one spelling utility is enough. I wonder if they shouldn't be downgraded to a Suggests anyway. - Your long description partly repeats the short description; see [2] for guidelines. [2] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc Cheers, -- Benoît Knecht -- 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/20120221123617.ga12...@marvin.lan
Processed: Re: Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
Processing commands for cont...@bugs.debian.org: block 660125 with 660128 Bug #660125 [wnpp] ITP: heybuddy - light identi.ca microblogging client Was not blocked by any bugs. Added blocking bug(s) of 660125: 660128 thanks Stopping processing here. Please contact me if you need assistance. -- 660125: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660125 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13298278166341.transcr...@bugs.debian.org
Re: fastest hack-build-run iteration
On Tue, Feb 21, 2012 at 09:58:45AM +0100, Joachim Wiedorn wrote: Paul Wise p...@debian.org wrote on 2012-02-21 09:28: On Tue, Feb 21, 2012 at 8:40 AM, David Roguin wrote: I'm making some changes to the evolution package and every time I want to test a tiny change I build a deb, install and run it. As you can imagine that takes a lot of time. Are you testing changes to packaging or actual code? If the latter, I'd run the non-installed binary directly from the build dir. It probably expects support data but that's already installed (unless you changed that as well). If it's a library, you can LD_PRELOAD the new version. maint-guide used to recommend running ./debian/rules binary for that, not sure if it does now. And use ccache for using compiling results for the next time. If the package's makefile is sane, ccache is not needed since unchanged files won't be recompiled. And evolution uses automake which produces sane makefiles (at least in this regard). Too bad, in this case, a no-change rebuild still takes 1/4 of time needed for a clean build. It seems it's mostly: 1. installing mo files 2. dh_shlibdeps 3. debhelper/dpkg-dev It doesn't seem to me you can avoid especially 2. and 3. easily. (And no, I'm not proposing to replace 3. with fine techniques in http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc ☺). If you weren't using cdbs, debhelper can speed up things quite a bit with --parallel[¹], especially for packages with multiple binaries like evolution. And hey, these days if you don't have multiple cores, your phone is aged. [¹]. You need to export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l` as well, but that's something which should have been the default everywhere but on buildds. Packages that are not marked as parallelizable won't be affected so it's a safe thing to do. -- // If you believe in so-called intellectual property, please immediately // cease using counterfeit alphabets. Instead, contact the nearest temple // of Amon, whose priests will provide you with scribal services for all // your writing needs, for Reasonable and Non-Discriminatory prices. signature.asc Description: Digital signature
Bug#660049: typo
Obviously I meant mosh and not 'hello'. It was late. :) Cheers, -- David Banks amoe...@gmail.com -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOBNZ7ZD_9QsEyiC8BeNjjbgBO0nMAD3=c+u+sr9ortaqbk...@mail.gmail.com
Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
Hi all, First of all I'm not a coder or a developer in anyway. So sorry for butting onto the mailing list like this but don't know any place better. So please either tell/share if there is a better mailing list for the same or answer it here. Please CC me in replies as I'm not subscribed to the list. We have an event happening this week-end [01] . For this event we have scheduled a talk about some of the back-end of Debian with a topic about the Debian infrastructure (i.e. autobuilders,the mirrors, package builders and so on). I have seen couple [02] [03] of webpages and while those are great pages in themselves as people have an idea about which packages are failing, are uninstallable and so on and so forth, is there a public page where some of the info. about the autobuilders themselves can be had. The info. I'm looking for is the physical infrastructure as to the kinda specs (hardware specs of the machines) on the network are and if they are located at diverse locations (or not). I do know that there is a mailing list dedicated for DD,DM's wanna-build [04] but am not sure if my query would be entertained there (as I'm no DD,DM or even a package uploader, just an interested user who uses stuff from Debian). The page I would be looking for could be a wiki page or just a landing page which is not connected in anyway to the infrastructure but is just there to inform the public-at-large the kind of infrastructure Debian needs/uses in order to give us the service (i.e. the all the packages/goodies.) It would be nice if it also gave some sort of idea as to the nature of bandwidth needed for those services to function. (Have no idea for instance if autobuilders have direct access to the archive [05] and if they don't what kind of bandwidth is needed. I do know that in the past vendors like HP and others have donated machines for autobuilding and things. I also do remember seeing Stefano Zacchiroli's e-mail when he does share some tit-bits as he did couple of months ago[06] . I do know that there is also a team called DSA which actually oversees all of this [07] but don't really know how to connect with them. Its also possible that such a service does exist only I'm not aware of them. I have seen for instance announces which share about recent/joined autobuilders and developer machines such as the one for GNU/Hurd in the recent past [08] Unfortunately though, most of the URI's shared don't seem to get/have a public-facing webpage . For instance to take the above e.g. both [09] [10] and don't seem to have a public-facing webpage via browser. Sorry for taking your time and noise. Looking forward to any help or/and advice of the same. 01. http://wiki.debian.org/DebianIndia/DebianUtsav2012 - please see the third entry. 02. https://buildd.debian.org/ 03. http://www.debian.org/devel/buildd/ 04. http://lists.debian.org/debian-wb-team/ 05. ftp.debian.org 06. http://lists.debian.org/debian-devel-announce/2012/01/msg1.html 07. http://lists.debian.org/debian-devel/2011/08/msg00504.html 08. http://www.debian-news.net/2012/02/04/bits-from-the-debian-gnuhurd-porters-3/ 09. ironforge.sceen.net 10. exodar.debian.net -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/cadddzrm1y6r04fvapx_fhtpfadb+thatw0zuzggm6dpa-sf...@mail.gmail.com
Re: Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
at bottom :- 2012/2/21 shirish शिरीष shirisha...@gmail.com: Unfortunately though, most of the URI's shared don't seem to get/have a public-facing webpage . For instance to take the above e.g. both [09] [10] and don't seem to have a public-facing webpage via browser. Did get my answer https://db.debian.org/machines.cgi , it does not have any stats but good enough to show off :) -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/cadddzrmttx_dah3rzqsfr+u2_et1m8_8pwhraqzl9jbzuoe...@mail.gmail.com
Re: Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
Hi, I think -project@ might be a better list for this. On 02/21/2012 03:14 PM, shirish शिरीष wrote: The info. I'm looking for is the physical infrastructure as to the kinda specs (hardware specs of the machines) on the network are and if they are located at diverse locations (or not). [DB] has a list of machines in use by Debian, you want to look for hosts which have listed buildd purpose. For bandwidth usage, you could try the munin instance maintained by DSA [MUNIN]; access details can be found on [DSA]. [DB] http://db.debian.org/machines.cgi [MUNIN] http://munin.debian.org/ [DSA] http://dsa.debian.org/ I do know that there is a mailing list dedicated for DD,DM's wanna-build [04] but am not sure if my query would be entertained there (as I'm no DD,DM or even a package uploader, just an interested user who uses stuff from Debian). Just try asking them, most people don't bite (or at least not too hard). You might also be interested in [ORG] and [TEAMS] which has a bit more information. [ORG] http://www.debian.org/intro/organization [TEAMS] http://wiki.debian.org/Teams (Have no idea for instance if autobuilders have direct access to the archive [05] and if they don't what kind of bandwidth is needed. I do know that in the past vendors like HP and others have donated machines for autobuilding and things. Hmm, I am not sure if there is much documentation about this, but as far as I know buildds usually have access to the archive (they can use mirrors as well), including packages not yet pushed to the mirror network (similar to [INCOMING] but with signed Packages indices for use with APT). [INCOMING] http://incoming.debian.org 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/4f43b12e.3030...@debian.org
Re: Is there a public-facing page of the various autobuilders ? more specifically hardware specs.
in-line :- 2012/2/21 Ansgar Burchardt ans...@debian.org: Hi, I think -project@ might be a better list for this. On 02/21/2012 03:14 PM, shirish शिरीष wrote: The info. I'm looking for is the physical infrastructure as to the kinda specs (hardware specs of the machines) on the network are and if they are located at diverse locations (or not). [DB] has a list of machines in use by Debian, you want to look for hosts which have listed buildd purpose. For bandwidth usage, you could try the munin instance maintained by DSA [MUNIN]; access details can be found on [DSA]. [DB] http://db.debian.org/machines.cgi [MUNIN] http://munin.debian.org/ [DSA] http://dsa.debian.org/ Dear Angsar, First of all thanx for replying. I feel I should have given a bit more info about the day-long event . Its basically an event targeted towards college-students and IT Professionals. The crowd would probably be an eclectic crowd of the two. ( http://wiki.debian.org/DebianIndia/DebianUtsav2012 - please see the third entry.) . The idea is to generate awareness about Debian as an OS as well as hopefully get few people interested in packaging and maintaining packages and all. I had seen [DB] http://db.debian.org/machines.cgi and then promptly forgot about it. I am not looking for real-time stats, at the same time I do not want to put a request as that would include having to be secure about a pair of SSH keys and it would just be complicated for me (a bit of a long story) . What would suffice is if its possible to get some sort of random snapshot of bandwidth usage (say either during when Squeeze was released) or any of the snapshots or during some transitions when something interesting happened. If there are such graphs (preferably) or pie-charts which are accessible to public (or either in public domain) it would be nice. This of course depends on munin keeping and having historical records of all the stats which in itself would be quite an undertaking. Have no idea if munin does this. I do know that there is a mailing list dedicated for DD,DM's wanna-build [04] but am not sure if my query would be entertained there (as I'm no DD,DM or even a package uploader, just an interested user who uses stuff from Debian). Just try asking them, most people don't bite (or at least not too hard). You might also be interested in [ORG] and [TEAMS] which has a bit more information. [ORG] http://www.debian.org/intro/organization [TEAMS] http://wiki.debian.org/Teams Looked at both of them, nice. (Have no idea for instance if autobuilders have direct access to the archive [05] and if they don't what kind of bandwidth is needed. I do know that in the past vendors like HP and others have donated machines for autobuilding and things. Hmm, I am not sure if there is much documentation about this, but as far as I know buildds usually have access to the archive (they can use mirrors as well), including packages not yet pushed to the mirror network (similar to [INCOMING] but with signed Packages indices for use with APT). [INCOMING] http://incoming.debian.org Actually what would be nice if there is some kind of (even if its a bit incorrect/historical) block diagram which tells how the whole thing flows. Regards, Ansgar Interested to know more. Thanx again. -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com 065C 6D79 A68C E7EA 52B3 8D70 950D 53FB 729A 8B17 -- 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/cadddzrnts9w60s6nv3gt3aafcnqhjypffyk1qq8ah0ieayn...@mail.gmail.com
Re: RFS: dwarf-fortress
On Tue, Feb 21, 2012 at 04:47:42PM +0100, Beren Minor wrote: I am looking for a sponsor for my package dwarf-fortress. That's good news. Unfortunately, the package is not ready yet. dwarf-fortress-bin - Dwarf Fortress binaries dwarf-fortress-data - Dwarf Fortress data files dwarf-fortress-mod-ironhand - Dwarf Fortress graphic mod Ironhand dwarf-fortress-mod-mayday - Dwarf Fortress graphic mod Mayday dwarf-fortress-mod-phoebus - Dwarf Fortress graphic mod Phoebus To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dwarf-fortress Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/non-free/d/dwarf-fortress/dwarf-fortress_0.34.2.0-1.dsc I would be glad if someone uploaded this package for me. -- Please don't include '-- ' in the middle of your emails, it marks the end of the message text. There's already an ITP for this package in debian but it has been inactive for a long time and without any. Did you try to contact the previous ITP owner? I'm not a Debian Maintainer and I'm also looking for advices and comment on the way the game has been packaged, as the available upstream binaries are 32bits only, and I had to embed 32bit libraries with the package in order to have it work. You should not embed libraries. You also should not set Architecture: any. If you want to see a i386-only binary packaged for amd64, you may look at zsnes (though the proper way is multi-arch dpkg but it is not available in unstable now). You have a build system that uses git magic and branches while an unpacked Debian source package is a directory with upstream sources from upstream tarball(s) and debian/ directory with build files. Also, as you include 3rd-party mods, you should ask about their distribution licenses and mention them in debian/copyright. There are some more or less minor things such as copyright notices in descriptions and old Standards-Version, but they are not important for now, as I could not even build the package. -- WBR, wRAR signature.asc Description: Digital signature
Re: Mentors upload authentication
]] Michael Gilbert In this case, I think it would be possible to use ssh public keys as that authentication. The process would be: This seems overly complex, why not just have the user put all those files in a well-known location on alioth (or some other host) and have the mentors code download and DTRT with that bunch of files. As for removing non-distributable files, that's not something we're going to entrust to another team, any such removal requests will go through admin@alioth. [...] Just to be clear, alioth is not a regular debian.org machine. It isn't admined by the same team, accounts are not handled in the same way, and privileged groups on Debian machines have no special privilege on alioth machines. I understand that, but I don't see how that has to do with the DMUP, which is a usage policy intended for debian machines of which alioth is one. Otherwise, it seems like it fine to misuse alioth in ways that violate the DMUP, but not any other machine. That a machine is not subject to agreement to the DMUP does not mean any other use of said machine is ok. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/874nukjip2@qurzaw.varnish-software.com
Re: RFS: dwarf-fortress
Hi and thanks for you interest, On Tue, Feb 21, 2012 at 5:24 PM, Andrey Rahmatullin w...@wrar.name wrote: Did you try to contact the previous ITP owner? I did, a year ago and before as well. The answer I got was it's still work in progress, we are trying to talk with the upstream author to have a more FHS compliant game. No updates since. I haven't asked again, but it has been WIP for almost two years now and without any release. I don't want to hijack the package, but I've got something working for a year already and I took the opportunity of the new upstream release for uploading it to debian mentors. You should not embed libraries. You also should not set Architecture: any. If you want to see a i386-only binary packaged for amd64, you may look at zsnes (though the proper way is multi-arch dpkg but it is not available in unstable now). I've been already told like half a year ago that the correct way was to use multi-arch package. However as you said, muti-arch isn't available and I couldn't even make it work with experimental dpkg/aptitude, so I gave up [1]. The other correct way, as far as I could see, to have an i386 package available on amd64 is to use ia32-libs package, however this package does not contain all the required dependencies for dwarf-fortress (sdl-ttf, sdl-image and glew are missing). I asked the ia32-libs maintainer if it was possible to add these libraries, but I've been told that ia32-libs should not be used and that I should use multi-arch (cf [1]). Therefore, embed libraries it is. You have a build system that uses git magic and branches while an unpacked Debian source package is a directory with upstream sources from upstream tarball(s) and debian/ directory with build files. Also, as you include 3rd-party mods, you should ask about their distribution licenses and mention them in debian/copyright. I'm using git-buildpackage for building, and patch queue maintained with the same tool. Patches aren't commited to debian branch (maybe they should), but can be regenerated with gbp-pq export command before running git-buildpackage. Regarding the copyright thing, I understand that and I'll add the copyrights to the corresponding files, and ask/tell/talk upstream authors about it. There are some more or less minor things such as copyright notices in descriptions and old Standards-Version, but they are not important for now, as I could not even build the package. I'm not sure what the procedure is to build the package from the mentors uploaded files, if you can tell me the issues you are facing, I can try to solve them. -- Beren Minor -- 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/caonpvzxfvxpcg98d+a8gjqiyp5tje71xo+q84yjlcwargs3...@mail.gmail.com
Re: RFS: dwarf-fortress
I'm not a Debian Maintainer and I'm also looking for advices and comment on the way the game has been packaged, as the available upstream binaries are 32bits only, and I had to embed 32bit libraries with the package in order to have it work. You should not embed libraries. You also should not set Architecture: any. If you want to see a i386-only binary packaged for amd64, you may look at zsnes (though the proper way is multi-arch dpkg but it is not available in unstable now). Hello, I had a look at your package. I also confirm that it does not build in a chroot, unfortunately. The package should build without being in a git repository (and without internet access). As a maintainer of the zsnes package, I second the suggestion of having a look at it as the requirements are similar. Feel free to ask here if something is unclear :) -- Etienne Millon -- 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/20120221165158.GA3516@klow
Re: RFS: dwarf-fortress
On Tue, Feb 21, 2012 at 05:48:50PM +0100, Beren Minor wrote: The other correct way, as far as I could see, to have an i386 package available on amd64 is to use ia32-libs package, however this package does not contain all the required dependencies for dwarf-fortress (sdl-ttf, sdl-image and glew are missing). For the reference: #598909. Also, glew doesn't seem to be needed. You have a build system that uses git magic and branches while an unpacked Debian source package is a directory with upstream sources from upstream tarball(s) and debian/ directory with build files. Also, as you include 3rd-party mods, you should ask about their distribution licenses and mention them in debian/copyright. I'm using git-buildpackage for building, and patch queue maintained with the same tool. Patches aren't commited to debian branch (maybe they should), but can be regenerated with gbp-pq export command before running git-buildpackage. I'm not talking about patches, gbp and gbp-pq. I mean git checkout magic in your Makefile. There are some more or less minor things such as copyright notices in descriptions and old Standards-Version, but they are not important for now, as I could not even build the package. I'm not sure what the procedure is to build the package from the mentors uploaded files As with any other standalone Debian package, dget --build for .dsc URL or dpkg-source -x and dpkg-buildpackage for downloaded one. You should learn these tools before learning git-buildpackage. -- WBR, wRAR signature.asc Description: Digital signature
Re: RFS: dwarf-fortress
On Tue, Feb 21, 2012 at 6:05 PM, Andrey Rahmatullin w...@wrar.name wrote: For the reference: #598909. Also, glew doesn't seem to be needed. That's what I was talking about. There's no answer to this bug and no willing to add the sdl libraries to ia32-libs, because the ia32-libs is though to be obsolete, replaced with multi-arch that is still not available. Kafka himself would be impressed. I'm not talking about patches, gbp and gbp-pq. I mean git checkout magic in your Makefile. As with any other standalone Debian package, dget --build for .dsc URL or dpkg-source -x and dpkg-buildpackage for downloaded one. You should learn these tools before learning git-buildpackage. That's what I've just realised, indeed. I'm maintaining the upstream sources and third party mods on different git branches for clarity purpose and to keep things clean and separated. I should probably introduce a new fake upstream branch with all these merged together. I'll work on it. -- Beren Minor -- 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/CAONPvZy2chiYObSWpCQJxGfwAmW12pmpKbX=awZ_FbiGXb=e...@mail.gmail.com
Re: RFS: dwarf-fortress
On Tue, Feb 21, 2012 at 06:15:00PM +0100, Beren Minor wrote: I'm not talking about patches, gbp and gbp-pq. I mean git checkout magic in your Makefile. As with any other standalone Debian package, dget --build for .dsc URL or dpkg-source -x and dpkg-buildpackage for downloaded one. You should learn these tools before learning git-buildpackage. That's what I've just realised, indeed. I'm maintaining the upstream sources and third party mods on different git branches for clarity purpose and to keep things clean and separated. I should probably introduce a new fake upstream branch with all these merged together. I'll work on it. Or make use of format 3.0 multi-orig feature. -- WBR, wRAR signature.asc Description: Digital signature
Re: RFS: dwarf-fortress
Or make use of format 3.0 multi-orig feature. That seems interesting, is it supported by git-buildpackage? #561071 makes me think it is not... -- Beren Minor -- 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/caonpvzyzxunbtb0dkruto3qt1rnxtcohhrnmc8xpxzc-udz...@mail.gmail.com
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
* Benoît Knecht benoit.kne...@fsfe.org, 2012-02-21, 13:36: In the same file, you run compileall unconditionally; I guess it should only run during configure. What's wrong with running it unconditionally? As far as I know, none of the Python helpers in the wild create maintainer script fragments that'd check the first argument. You do not honor the settings from /etc/python/debian_config [1]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation Righto. Implementing byte-compiling is not really straight-forward. If you do it yourself, there's a great chance you'll do it wrong. Apart from the issue mentioned by Benoît: - Modules are not re-byte-compiled when the default Python version changes. - postrm doesn't remove anything (unless /bin/sh is a symlink to bash, which is not the default these days). -- 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/20120221181905.ga...@jwilk.net
Bug#660774: RFS: gnash [DM uploads to bpo]
Package: sponsorship-requests Hi, following [0], first upload has to be sponsored. Could anyone please upload gnash to backports for me? http://mentors.debian.net/debian/pool/main/g/gnash/gnash_0.8.10-3~bpo60+1.dsc [it should go in testing tomorrow] Thanks. -- Gabriele [0] http://lists.debian.org/debian-backports/2011/12/msg00011.html -- 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/4f43e7a3.8050...@gmail.com
Bug#658235: RFS: libjreen, the xmpp library (3rd try, 2 months later)
Dear Benoît, I'm very thankful for your package review. I've just fixed most of the things you mentioned. However, there're a couple of moments I'm unsure. I: libjreen1: no-symbols-control-file usr/lib/libjreen.so.1.0.1 There was a long C++ vs symbols discussion[1] recently with pros and contras. I suppose, that symbols really doesn't make sense for C++ and too hard to maintain (just to create the appropriate symbols file, I have to somehow upload the package with initial .symbols version, wait for build fails everywhere, collect buildd logs, and only there I'll be able to create real .symbols file). For example, dpkg-gensymbols generates 1633 lines of .symbols for this library. Are you sure that it's really needed? The dh_auto_install override could also be replaced by using debian/package.install files (see dh_install(1) for details). I'm unsure that .install is better solution. The one of mine should work in most cases, even if one change library and package names, I'll have to change only a package name in dh_auto_install override. In the case of .install files there would be more work. Am I right? I've uploaded new version to mentors[2], if you agree with my comments above, could you review and probably sponsor the fixed version, please? [1] http://lists.debian.org/debian-devel/2012/01/thrd2.html#00671 [2] http://mentors.debian.net/debian/pool/main/libj/libjreen/libjreen_1.0.1-1.dsc Best wishes and have a nice day, Vsevolod Velichko 2012/2/20 Benoît Knecht benoit.kne...@fsfe.org: Hi Vsevolod, Vsevolod Velichko wrote: I am looking for a sponsor for my package libjreen (and do this for the 3rd time, because I've got no answer, neither positive nor negative since November 2011). * Package name : libjreen Version : 1.0.1-1 Upstream Author : Ruslan Nigmatullin euroeles...@yandex.ru * URL : http://qutim.org/jreen * License : GPL2+ Section : libs It builds those binary packages: libjreen-dev - powerful Jabber/XMPP library - development files libjreen1 - powerful Jabber/XMPP library implemented in Qt/C++ I took a look at your package, here are a few things you may want to look into: - Some warnings from lintian: I: libjreen source: binary-control-field-duplicates-source field section in package libjreen1 P: libjreen source: unversioned-copyright-format-uri http://dep.debian.net/deps/dep5 I: libjreen1: no-symbols-control-file usr/lib/libjreen.so.1.0.1 - In debian/control, your long description repeats the synopsis, and it doesn't consist of full sentences. See [1] for guidelines about writing good descriptions. [1] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-pkg-desc If you're not using a VCS, you should remove those commented-out lines. - In debian/rules, the dh_installchangelogs override isn't needed; debhelper will pick up the upstream changelog automatically. The dh_auto_install override could also be replaced by using debian/package.install files (see dh_install(1) for details). - In debian/copyright, you should use the predefined short names for licenses; what you call MIT/X11 (BSD Like) is the Expat license. And even though it's more cosmetic than anything, GPL-2.0+ could be replaced by GPL-2+. I'm also not sure your debian/README.source is particularly relevant. First of all, one _should_ care about that copyright in Debian since those files are shipped in the source package (so clauses about distribution of those files certainly apply). If you want to say that the binary package doesn't contain any code from these files, perhaps a Comment in the relevant File paragraph in debian/copyright would be better (as this file is actually installed along with the binary package). I've built your package, but I haven't installed and tested it, so I cannot comment on that. Cheers, -- Benoît Knecht -- 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/caatb-vrurpbwmyrmwku-165qgo6epnq36gf9tg7nexummw6...@mail.gmail.com
Re: RFS: lftp-gtk
Hi, maintai...@lftp-gtk.com writes: I am looking for a sponsor for my package lftp-gtk. * Package name: lftp-gtk Version : 1.5 * URL : [http://www.lftp-gtk.com] * License : [gpl-2.0] Section : web the package is far from meeting requirements for a package in Debian, please read [NM-Guide], [DevRef] and [Policy] if you have not done so yet. [NM-Guide] http://www.debian.org/doc/manuals/maint-guide/ [DevRef] http://www.debian.org/doc/manuals/developers-reference/ [Policy] http://www.debian.org/doc/debian-policy/ Personally I also believe that the upstream code is currently not very good and needs serious work before -- 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/87ty2kf1z0@eisei.43-1.org
Bug#660128: RFS: heybuddy/0.2.3-1 [ITP] - light identi.ca microblogging client
Jakub Wilk wrote: * Benoît Knecht benoit.kne...@fsfe.org, 2012-02-21, 13:36: In the same file, you run compileall unconditionally; I guess it should only run during configure. What's wrong with running it unconditionally? Nothing wrong per se, it just seemed unnecessary... As far as I know, none of the Python helpers in the wild create maintainer script fragments that'd check the first argument. ...but if python helpers do it that way, I guess it's fine then. I didn't know it was the usual behavior, thanks for the heads up. You do not honor the settings from /etc/python/debian_config [1]. [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation Righto. Implementing byte-compiling is not really straight-forward. If you do it yourself, there's a great chance you'll do it wrong. Apart from the issue mentioned by Benoît: - Modules are not re-byte-compiled when the default Python version changes. - postrm doesn't remove anything (unless /bin/sh is a symlink to bash, which is not the default these days). Oh, right, good catch. That brings up another point actually, Daniel; both maintainer scripts are missing a #! line, declaring which shell should run them, and you may want to use set -e [2]. [2] http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s6.1 Cheers, -- Benoît Knecht -- 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/20120221204333.ga1...@marvin.lan
Bug#658235: RFS: libjreen, the xmpp library (3rd try, 2 months later)
Vsevolod Velichko wrote: I'm very thankful for your package review. I've just fixed most of the things you mentioned. However, there're a couple of moments I'm unsure. I: libjreen1: no-symbols-control-file usr/lib/libjreen.so.1.0.1 There was a long C++ vs symbols discussion[1] recently with pros and contras. I suppose, that symbols really doesn't make sense for C++ and too hard to maintain (just to create the appropriate symbols file, I have to somehow upload the package with initial .symbols version, wait for build fails everywhere, collect buildd logs, and only there I'll be able to create real .symbols file). For example, dpkg-gensymbols generates 1633 lines of .symbols for this library. Are you sure that it's really needed? I was merely reporting the lintian output, in case you hadn't seen it (people often run it without any additional flags and miss some relevant warnings); but the severity of this particular tag is 'wishlist', so you can ignore it if it doesn't make sense in your case. The dh_auto_install override could also be replaced by using debian/package.install files (see dh_install(1) for details). I'm unsure that .install is better solution. The one of mine should work in most cases, even if one change library and package names, I'll have to change only a package name in dh_auto_install override. In the case of .install files there would be more work. Am I right? Well it just seems awfully convoluted for just moving two files; with wildcards, you could achieve the same thing with just one line in libjreen1.install (I'm not sure why you worry about library or package name changes, that shouldn't happen too often, right?) But of course your solution is not wrong, and it's ultimately your decision what to do; I just find it more complex than necessary. I've uploaded new version to mentors[2], if you agree with my comments above, could you review and probably sponsor the fixed version, please? Hmm, I thought it was clear from my email address, but I guess it's not; I'm not a DD, so I can't sponsor your package. I'm just trying to help out however I can, by reviewing other people's packages. [1] http://lists.debian.org/debian-devel/2012/01/thrd2.html#00671 [2] http://mentors.debian.net/debian/pool/main/libj/libjreen/libjreen_1.0.1-1.dsc Cheers, -- Benoît Knecht -- 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/20120221215553.gb1...@marvin.lan
Re: RFS: dwarf-fortress
I've updated the packages on mentors and splitted the original one in two. There's the main dwarf-fortress with binaries, data files and scripts for modding support, and the default graphic mod package that is also required. I've not re-uploaded the other third-party mods for now but they would be packaged as separate packages as well. Both should build without Git. http://mentors.debian.net/package/dwarf-fortress http://mentors.debian.net/package/dwarf-fortress-mod-default Kind Regards, -- Beren Minor -- 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/caonpvzxgn1y0bf9jjd7i43ofu5euj8f6rwfhd1p8t+ok0vs...@mail.gmail.com
Processed: merge
Processing commands for cont...@bugs.debian.org: block 627141 with 660519 Bug #627141 [wnpp] ITP: manaplus -- Advanced client Evol for Online and The Mana World Bug #627142 [wnpp] ITP: manaplus -- Advanced client Evol for Online and The Mana World Was blocked by: 658713 Added blocking bug(s) of 627141: 660519 Was blocked by: 658713 Added blocking bug(s) of 627142: 660519 merge 658713 660519 Bug#658713: RFS: manaplus/1.2.2.5-1 [NEW] -- Extended client for Evol Online and The Mana World Bug#660519: RFS: manaplus/1.2.2.19 Merged 658713 660519. End of message, stopping processing here. Please contact me if you need assistance. -- 658713: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658713 660519: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660519 627141: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627141 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13298712431506.transcr...@bugs.debian.org
versioning trouble
Hello List: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: how can I can manage it ? May I force version 2.54 ? may I use some work around here ? Thanks in advance, Jerome -- 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/4f443add.90...@rezozer.net
Re: Bug#652826: Bug#624991: Bug#652826: RFS: logkeys (fixing RC bugs)
On 19.02.2012 14:11, Julien Cristau wrote: Hi Vedran, Hey, On Thu, Jan 12, 2012 at 12:18:52 +0100, Vedran Furač wrote: On 12.01.2012 11:21, Alexander Reichle-Schmehl wrote: Hey, since you're DD, and I am not, would you be so kind and sponsor the upload? I am and I would be willing. Could you please provide a package also fixing that RC bug? I'll upload it as soon as I could test it, however so far logkeys fails for me with the following error message: Hey, ok, I'll prepare a package this weekend and let you know. That was a month ago. Any progress? Sorry for a late reply. I've made the package (I'm not sure if I uploaded it on mentors), but I waited for Alexander's reply on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655564 so I can fix that one as well in a single upload. Anyway, I'll upload it to mentors without the fix for 655564 this week. Regards, Vedran attachment: vedran_furac.vcf
Bug#660519: RFS: manaplus/1.2.2.19
Here is another review of manaplus: If you contact upstream as a result of this review, please point them at these two pages: http://wiki.debian.org/UpstreamGuide http://www.freedesktop.org/wiki/Games/Upstream Did you intend for this to be maintained as part of the Debian games team? Do you intend to package the servers for manaplus too? All the servers appear to require a login to play, are there any I could use for 'testing' the game without registering? Please consider wrapping debian/menu with one item per line. description= is not valid in debian/menu, you want longtitle= IIRC. xz compression is better than bzip2, have you considered switching? Personally I don't think the package is large enough to bother switching from gzip though. Some of the images were created in Inkscape or GIMP but there are no source SVG or XCF images, that might be a GPL/DFSG violation. There is one pre-mixed, pre-encoded audio file, could you ask upstream about how it was created? In the upstream .desktop files, none of the language-specific Icon or Name lines appear to be needed. You are installing the upstream PNG icon into the wrong location, it should be /usr/share/pixmaps since none of the /usr/share/icons/hicolor/*/apps/ dirs are for the same resolution as the image. Please also install manaplus.svg into /usr/share/icons/hicolor/scalable/apps/ and use python-scour to strip down the installed image. The manaplus.svg file looks slightly different to manaplus.png and the other files, it looks like that means the source SVG for manaplus.png is missing and there is a GPL/DFSG violation. There is no need to install manaplusttest at all IMO since it does nothing useful to users, please get upstream to disable that. If they are not willing to do that, please at least remove the desktop file for it. Please ask upstream to use fontconfig to find font files on Linux or switch to a font rendering system that does that (such as SDL-Pango, QuesoGLC). Then you will not need to use those symlinks, which are fragile when font paths move around and are not portable between Linux distros. Some of the upstream code has the wrong address for the FSF in the license grant, please let them know about that. Some of the copyright/license information is missing from debian/copyright. Please audit every file, licensecheck --copyright helps to find missed stuff though. You are missing a depends on x11-utils because the code uses xmessage to display errors. I'm not sure if any of the errors contain untrusted network/other input, but it is not a good idea to use the system() function for anything other than constant commands. Please send upstream a patch to use the exec family of functions, they are the only ones that are guaranteed to be safe from arbitrary code execution in the face of untrusted input. I note that the upstream help system uses plain text files for translations, has upstream considered using standard po files for that? There are some duplicate files (I detect them using fdupes), you might want to ask upstream to remove them from the source package and in the meantime reduce the size of the package slightly using symlinks: rdfind -outputname /dev/null -makesymlinks true debian/manaplus/ symlinks -r -s -c debian/manaplus/ cppcheck warnings (send upstream): [src/graphicsvertexes.h:140]: (error) Memory leak: ImageVertexes::ogl [src/game.cpp:1828]: (error) Possible null pointer dereference: newMap - otherwise it is redundant to check if newMap is null at line 1823 Lintian complaints: O: manaplus-data: package-contains-empty-directory usr/share/manaplus/data/themes/classic/ I: manaplus: spelling-error-in-binary usr/games/manaplus dont don't -- 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/caktje6fjqngjwwq0zeq8+m8bz_qdcefbhsymmmadukuvf5u...@mail.gmail.com
Re: versioning trouble
On Wed, Feb 22, 2012 at 8:46 AM, Jerome BENOIT wrote: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. You should have used 2.54~cvs20120219 instead, since that sorts before 2.54 (note the special ~ character). Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: how can I can manage it ? May I force version 2.54 ? may I use some work around here ? If the package has not yet been uploaded to Debian, just edit the changelog with your favourite text editor and change 2.54+cvs20120219 to 2.54 then update the packaging if needed. -- 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/caktje6hpk12wzszt27kqezgixijde5g-sfa6hwesgkhzcnk...@mail.gmail.com
Re: versioning trouble
* Jerome BENOIT g62993...@rezozer.net, 2012-02-22, 01:46: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: This is correct. You should have used ~ instead of +, because: 2.54~cvs20120219 2.54 2.54+cvs20120219 how can I can manage it ? May I force version 2.54 ? may I use some work around here ? It would have been slightly easier for us if you said whether or not the package with such bad version has been uploaded to the archive, or at least mentioned the package name. I will assume that we're talking about bibtool, which has been already uploaded to unstable. You cannot use a lower version than the existing one. dak would reject such upload. The options you have are: 1) Use an epoch. However, once use epoch, you have to carry it forever. 2) Invent a version that is bigger than 2.54+cvs20120219, e.g: - 2.54+cvssucks or - 2.54+really or - 2.54.. 3) Instead of uploading 2.54, upload a CVS snapshot with a version number like 2.54+cvs20120212. 4) Wait until upstream releases 2.55. -- 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/20120222014105.ga7...@jwilk.net
Re: versioning trouble
Thanks for the prompt reply. On 22/02/12 02:34, Paul Wise wrote: On Wed, Feb 22, 2012 at 8:46 AM, Jerome BENOIT wrote: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. You should have used 2.54~cvs20120219 instead, since that sorts before 2.54 (note the special ~ character). My mistake: I will keep it in mind for next cvs based packages. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: how can I can manage it ? May I force version 2.54 ? may I use some work around here ? If the package has not yet been uploaded to Debian, it was. just edit the changelog with your favourite text editor and change 2.54+cvs20120219 to 2.54 then update the packaging if needed. I will work around it by creating a Debian source package, 2.54+ds is greater than 2.54+cvs20120219: it planed to do so sooner or later, so I do it right now. Cheers, Jerome -- 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/4f44480b.3020...@rezozer.net
Re: versioning trouble
On 22/02/12 02:41, Jakub Wilk wrote: * Jerome BENOIT g62993...@rezozer.net, 2012-02-22, 01:46: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: This is correct. You should have used ~ instead of +, because: 2.54~cvs20120219 2.54 2.54+cvs20120219 my mistake: I should understand this part of the story before how can I can manage it ? May I force version 2.54 ? may I use some work around here ? It would have been slightly easier for us if you said whether or not the package with such bad version has been uploaded to the archive, or at least mentioned the package name. I will assume that we're talking about bibtool, which has been already uploaded to unstable. hence my request. You cannot use a lower version than the existing one. dak would reject such upload. The options you have are: 1) Use an epoch. However, once use epoch, you have to carry it forever. 2) Invent a version that is bigger than 2.54+cvs20120219, e.g: - 2.54+cvssucks or - 2.54+really or - 2.54.. 2.54+ds 3) Instead of uploading 2.54, upload a CVS snapshot with a version number like 2.54+cvs20120212. 4) Wait until upstream releases 2.55. bibtool is maintained, but the upstream version period is of order of half year: this option is not reasonnable. 5) Build a Debian Sourced package: 2.54+ds So I got my lesson. Thanks, Jerome -- 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/4f4449a8.3040...@rezozer.net
Re: fastest hack-build-run iteration
On Tue, 2012-02-21 at 13:59 +0100, Adam Borowski wrote: On Tue, Feb 21, 2012 at 09:58:45AM +0100, Joachim Wiedorn wrote: Paul Wise p...@debian.org wrote on 2012-02-21 09:28: On Tue, Feb 21, 2012 at 8:40 AM, David Roguin wrote: I'm making some changes to the evolution package and every time I want to test a tiny change I build a deb, install and run it. As you can imagine that takes a lot of time. Are you testing changes to packaging or actual code? If the latter, I'd run the non-installed binary directly from the build dir. It probably expects support data but that's already installed (unless you changed that as well). If it's a library, you can LD_PRELOAD the new version. That did it! After the 'make' command I'm using dh_auto_install to generate the debian/tmp dir and then use LD_PRELOAD with the .so I'm modifying (I think if I just copy the .so It'll speed up things a little more) maint-guide used to recommend running ./debian/rules binary for that, not sure if it does now. And use ccache for using compiling results for the next time. If the package's makefile is sane, ccache is not needed since unchanged files won't be recompiled. And evolution uses automake which produces sane makefiles (at least in this regard). Too bad, in this case, a no-change rebuild still takes 1/4 of time needed for a clean build. It seems it's mostly: 1. installing mo files 2. dh_shlibdeps 3. debhelper/dpkg-dev That's right. It doesn't seem to me you can avoid especially 2. and 3. easily. (And no, I'm not proposing to replace 3. with fine techniques in http://angband.pl/debian/pool/main/g/goodbye/goodbye_0.2-1.dsc ☺). If you weren't using cdbs, debhelper can speed up things quite a bit with --parallel[¹], especially for packages with multiple binaries like evolution. And hey, these days if you don't have multiple cores, your phone is aged. That speeded up things a little, thanks for the tip! [¹]. You need to export DEB_BUILD_OPTIONS=parallel=`grep ^processor /proc/cpuinfo|wc -l` as well, but that's something which should have been the default everywhere but on buildds. Packages that are not marked as parallelizable won't be affected so it's a safe thing to do. -- 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/1329875390.8806.4.camel@davidMac
Re: versioning trouble
W dniu 22.02.2012 02:42, Jerome BENOIT pisze: Thanks for the prompt reply. On 22/02/12 02:34, Paul Wise wrote: On Wed, Feb 22, 2012 at 8:46 AM, Jerome BENOIT wrote: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. You should have used 2.54~cvs20120219 instead, since that sorts before 2.54 (note the special ~ character). My mistake: I will keep it in mind for next cvs based packages. For future uploads in your scenario another correct approach would be 2.53+cvs20120219, since it's really 2.53 + some changes from CVS dated 20120219. The tilde (~) character is useful if an upstream released alpha/beta/release-candidate. Then you can upload 2.70~beta1 for example and when there's final 2.70 version then 2.70-1 is still newer than this beta. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: how can I can manage it ? May I force version 2.54 ? may I use some work around here ? If the package has not yet been uploaded to Debian, it was. just edit the changelog with your favourite text editor and change 2.54+cvs20120219 to 2.54 then update the packaging if needed. I will work around it by creating a Debian source package, 2.54+ds is greater than 2.54+cvs20120219: it planed to do so sooner or later, so I do it right now. Cheers, Jerome -- 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/4f44727e.9070...@fenski.pl
Re: versioning trouble
Thanks for the precision: versionning with cvs really confused me. On 22/02/12 05:43, Bartosz Feński wrote: W dniu 22.02.2012 02:42, Jerome BENOIT pisze: Thanks for the prompt reply. On 22/02/12 02:34, Paul Wise wrote: On Wed, Feb 22, 2012 at 8:46 AM, Jerome BENOIT wrote: Three days ago I uploaded for sponsoring my package with version 2.54+cvs20120219 which obviously cvs version. You should have used 2.54~cvs20120219 instead, since that sorts before 2.54 (note the special ~ character). My mistake: I will keep it in mind for next cvs based packages. For future uploads in your scenario another correct approach would be 2.53+cvs20120219, since it's really 2.53 + some changes from CVS dated 20120219. The tilde (~) character is useful if an upstream released alpha/beta/release-candidate. Then you can upload 2.70~beta1 for example and when there's final 2.70 version then 2.70-1 is still newer than this beta. Meanwhile, more precisely yesterday, the upstream maintainer finally released version 2.54, so now I plan to upload an upstream version of my package with version 2.54. But, according to `dch', version 2.54 is less than 2.54+cvs20120219: how can I can manage it ? May I force version 2.54 ? may I use some work around here ? If the package has not yet been uploaded to Debian, it was. just edit the changelog with your favourite text editor and change 2.54+cvs20120219 to 2.54 then update the packaging if needed. I will work around it by creating a Debian source package, 2.54+ds is greater than 2.54+cvs20120219: it planed to do so sooner or later, so I do it right now. Cheers, Jerome Jerome -- 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/4f448385.7010...@rezozer.net
