Ceramic LED -- New Auto LED In Competitive Price
Mega Lighting Co., LTD Dear Purchasing Manager, How are you? I wish you do best!I am Candy from Mega LED. I hope not to interrupt you since my aim is to introduce our updated products - Ceramic LED, which has lots of advantages to install in your cars(Ultra Bright！Optical Design！）. We also have many other auto LED products. You can browse our website (www.ledmg.com) to get more information. Pls Kindly Click Below Our Other Products, You Can Find It In Details ! Ceramic LED CANBUS LED T10/BA9S Bulb Festoon & Doom LED Braking & Turning LED Changing Color LED LED Fog Light Daytime Running Light DRL LED Strip Angel Eyes & LED Marker LED Undercar Kit LED Wheel Light Flashing Light Accessories Most Favorable Price & Best Service to Support Your Business. E-mail i...@ledmg.com sa...@ledmg.com MSN i...@ledmg.com sa...@ledmg.com Skype mega.led Mega Lighting Co., LTD
Berkeley DB plan for future
Hi, if your package depends on libdbX.Y you probably want to at least look at it: http://wiki.debian.org/BerkeleyDB http://wiki.debian.org/ReleaseGoals/BerkeleyDB O. [Please discuss in pkg-db-devel, or at least Cc me, I am not subscribed to debian-devel] -- Ondřej Surý -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTinuTXC21gm=rp1be6k7mg7z15t...@mail.gmail.com
Re: How to add "quilt" to an existing package?
Le Sat, Apr 23, 2011 at 12:20:33AM +0900, Osamu Aoki a écrit : > > New URLs: > > http://www.debian.org/doc/maint-guide/index.en.html (this is the same) > http://www.debian.org/doc/maint-guide/modify.en.html#quiltrc Hello everybody, by removing “.en.html”, the URLs will become shorter and support content negociation, that is, give the language that the user wishes. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425085624.gd21...@merveille.plessy.net
Re: System users: removing them
On Thu, 31 Mar 2011 09:23:33 +0100, Lars Wirzenius wrote: >Would a debhelper tool to create/remove system users be useful? I >suspect there's only relatively few packages that do that, so perhaps >not. I had that discussion years ago with Joey and his comments were the cause that I submitted patches to adduser --system to allow it to be used in maintainer scripts with as little wrapping code as possible ... >I earlier blogged about an "addsysuser" tool[0], but Stephen Gran >pointed out to me that it's mostly unnecessary scaffolding. ... which is also the cause why I don't understand why an addsysuser tool were useful. If adduser --system needs any additional code in a maintainer script, I'd consider that a bug in adduser which should be filed and addressed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1qejvs-0003cs...@swivel.zugschlus.de
RFH with a couple of packages
Hey, I've recently been having some problems keeping up with my basic debian duties, being overwhelmed by Real Life™ issues, so I thought it would be a good idea to ask for co-maintainers for a couple of my packages. I still very much want to keep maintaining them and would also accept team-maintenance, but I'll admit I'm a bit wary of big teams - where the responsibility can be pushed around too much - and would therefore prefer small teams if possible. The biggest problem is transmission[0]. It's not a complicated package, but it has a few FTBFSs for which I simply don't have the time right now. Upstream is very responsive, friendly and even proactive about debian bugs, so it's really just a matter of man-power. The second item in my list is the statusnet ITP[1]. It has a relatively long story, including a packaging attempt by upstream (Evan is a DD), but it's been kinda stuck lately. The git repo in collab-maint included upstream's repo, so I decided it would be cleaner to create a new one with just debian stuff, which is currently here[2]. AFAICS the only thing missing for a first upload is the debian/copyright file, but since I've been pulling some late shifts for debian work lately, the chance is pretty high I forgot something important. And since I'm already on the subject: I also have a couple of RFAs for packages which probably deserve removal in the long run, but in case there's anyone interested... Cheers [0] http://packages.qa.debian.org/t/transmission.html [1] http://bugs.debian.org/491723 [2] git://git.debian.org/~costela/public_git/statusnet.git -- Leo "costela" Antunes [insert a witty retort here] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db5664c.20...@debian.org
Re: MBF: packages using deprecated GnuTLS functions
Andreas Metzler wrote: [...] > The newer version of GnuTLS marks a couple of interfaces as > deprecated, i.e. they will be removed in future versions of GnuTLS. > Some of these are used in many packages. [...] > The MBF will probably touch about 60 packages, I will submit with > severity normal. [...] Done. I have limited the MBF to deprecated functions whose replacement has been available <= 2.10. http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=deprecated-gnutls-2.12;users=ametz...@downhill.at.eu.org cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8n8g88-ff6@argenau.downhill.at.eu.org
Re: RFH with a couple of packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/25/2011 02:17 PM, Leo 'costela' Antunes wrote: > Hey, > > I've recently been having some problems keeping up with my basic debian > duties, being overwhelmed by Real Life™ issues, so I thought it would be > a good idea to ask for co-maintainers for a couple of my packages. I > still very much want to keep maintaining them and would also accept > team-maintenance, but I'll admit I'm a bit wary of big teams - where the > responsibility can be pushed around too much - and would therefore > prefer small teams if possible. > > The biggest problem is transmission[0]. It's not a complicated package, > but it has a few FTBFSs for which I simply don't have the time right > now. Upstream is very responsive, friendly and even proactive about > debian bugs, so it's really just a matter of man-power. I'd love to help out any way I can with transmission. I currently maintain the transmission PPA on launchpad together with Krzysztof Klimonda. If you need som real brainpower though, I'd ask Krzysztof (CC'd). He has done a lot for the transmission packages in Ubuntu.. > > The second item in my list is the statusnet ITP[1]. It has a relatively > long story, including a packaging attempt by upstream (Evan is a DD), > but it's been kinda stuck lately. The git repo in collab-maint included > upstream's repo, so I decided it would be cleaner to create a new one > with just debian stuff, which is currently here[2]. AFAICS the only > thing missing for a first upload is the debian/copyright file, but since > I've been pulling some late shifts for debian work lately, the chance is > pretty high I forgot something important. > > And since I'm already on the subject: I also have a couple of RFAs for > packages which probably deserve removal in the long run, but in case > there's anyone interested... I'll have a look and see if it's anything I'm interested in, and capable of adopting. Regards Andreas Noteng > > > Cheers > > [0] http://packages.qa.debian.org/t/transmission.html > [1] http://bugs.debian.org/491723 > [2] git://git.debian.org/~costela/public_git/statusnet.git > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJNtX+iAAoJELRG7qgympRaWmYP+wTmXRHKuZ0ZjtHhEmk4dAoZ 5aedCe29m/AZw9LWKKq2Up1E8/lupf6U1eIDtbm3NiDqPWnDCGwF1ph9i0YoLSIR 0vQXhi8nk6jhnaXEIDcV3fANTn5SkwHm/PSNG4XcrIJTTOJ+iDqFOfV+aUSaRWmR Pqj53rld9mrQWFpc/WlzjAnfXJER22EjHcPWYqwmC2uygAUkOwBmNzEmO1TyBg+M sjlNNU2B7Tm0Xtxv4uqJp8jIz3bpk/4OQmYUAAJQyNLYVrTucWDIo2l1GB4M2TDW mTLNlUXMMqehIRTRELwDHK3lHRYG8f9pLNAS16BYWMCnj7wWFHrQDLpYgWChmnR4 OQ2IXRSFXU50l6Cq3VCrneMJzZNYPv0q1wD7USCU58FK7XnymcEl2zCS/2Rhlpfc vSqCqySUd2nOkrZXR3iltAYtgAcldgGcRTFg0uH2qXW+g8ORUH+G1Cc0yr9iHYC2 txRHJ7IEZA/P/HVx1hOpv28EFSWVnP/VsQ1Fzj3vuqhBbemlDAeYU7HbhcY+yUH6 ehTHub3iCuA3SjsbVF/hixY/45Ni1fZhrBWxstj9hPdtPHbXX2vKbi4dgZGJkMGs RWMQDz5gS8FtnOcFkoQyCVhTK+UEZ8Cd7P575QM8IZQgYtphFJoQfqEIleuPkdpk Hlx5mt/yyayaLGybhMqw =6xlR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db57fa6.7090...@noteng.no
Bug#624108: ITP: libclass-dbi-lite-perl -- lightweight ORM for Perl
Package: wnpp Owner: Onur Aslan Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org * Package name: libclass-dbi-lite-perl Version : 1.019 Upstream Author : John Drago * URL : http://search.cpan.org/dist/Class-DBI-Lite/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : lightweight ORM for Perl Class::DBI::Lite offors a simple way to deal with databases in an object-oriented way. . Main difference between Class::DBI and Class::DBI::Lite is Class::DBI::Lite is much more lightweight. Class::DBI::Lite using less resource to deal with database models. . Class::DBI::Lite relies heavily on Ima::DBI::Contextual, SQL::Abstract and Scalar::Util. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425155750.GA6858@localhost
python2.5 removal: dd-list of affected packages
python2.5 source package is planned to be removed from sid soon [0], there are several packages still depending on one of the binaries provided by it, though. Bugs have been already filed, you can see them at [1]. I also provide a dd-list of the affected packages. Adam C. Powell salome (U) Luciano Bello libmimic Jeff Breidenbach pylucene Sargis Dallakyan mgltools-bhtree (U) mgltools-gle (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Debian Games Team libtuxcap Debian Med Packaging Team mgltools-bhtree mgltools-gle mgltools-opengltk mgltools-pyglf mgltools-sff Debian Science Maintainers salome Debian/Ubuntu Zope Team bobo zconfig zope.testing Freevo Debian Dream Team freevo IV salome (U) Matthias Klose zope.testing (U) Georg W. Leonhardt freevo (U) Jeremy Malcolm gozerbot A Mennucc1 freevo (U) Steffen Moeller mgltools-bhtree (U) mgltools-gle (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Python Applications Packaging Team pytagsfs (U) Miriam Ruiz libtuxcap (U) Ritesh Raj Sarraf pytagsfs Brian Sutherland bobo (U) zconfig (U) zope.testing (U) Jason Thomas nagios-statd Andreas Tille mgltools-bhtree (U) mgltools-opengltk (U) mgltools-pyglf (U) mgltools-sff (U) Fabio Tranchitella bobo (U) zconfig (U) zope.testing (U) Davide Truffa obmenu [0] http://bugs.debian.org/623820 [1] http://deb.li/py25 -- .''`. : :' : Luca Falavigna `. `' `- signature.asc Description: OpenPGP digital signature
Bug#624112: ITP: libdancer-plugin-rest-perl -- REST plugin for Dancer
Package: wnpp Severity: wishlist Owner: Jonas Smedegaard * Package name: libdancer-plugin-rest-perl Version : 0.05 Upstream Author : Alexis Sukrieh * URL : http://search.cpan.org/dist/Dancer-Plugin-REST/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : REST plugin for Dancer Dancer is a Perl web application framework. . Dancer::Plugin::REST is a Dancer plugin to transform your Dancer app into a RESTful webservice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425165852.1647.5465.reportbug@localhost.localdomain
Re: limits for package name and version (MBF alert: ... .deb filenames)
Ben Hutchings dijo [Sun, Apr 24, 2011 at 04:54:46AM +0100]: > > If you use "git describe", removing hashes is a bad idea. > > > > They are needed to identify the version. Version numbers that are not > > unique are worthless. > > If versions are not ordered without the inclusion of a commit hash, they > are not ordered *with* it (except by chance). However, the use case described by others in this thread means the hash is the least significant part of the version - Yes, it lengthens the version number with no obvious meaning (and the reason for this thread is precisely limiting the version number length), but it contains important information in order to get to a given precise source. > > You can then checkout 0.9.0-a0-283-g1143071 in any repository that has my > > commits and you'll get that exact version. 0.9.0-a0-283 doesn't give you > > that. > [...] > > Last time I looked, policy required upstream source to be provided as > tarballs, not VCS references. Well, many authors don't ship tarballs but refer to points in their development history. I am maintaining the Githubredir¹ service, even though from the beginning I knew it was a limited and probably near-sighted solution - But yes, I'm limiting its results to tags in the project history, and I'm expecting the tags to be version numbers ordered in a sane fashion. Anyway - Summing up what I'm saying here, tags have a clear meaning: A point where upstream wants us to base our efforts at, mid-devel-cycle breakage should be at a minimum. So, instead of basing our packages off arbitrary commit hashes, why not basing them off tags? I do not believe it is unreasonable to request upstreams to do some tagging... ¹ http://githubredir.debian.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425175017.gj1...@gwolf.org
Re: limits for package name and version (MBF alert: ... .deb filenames)
On 26/04/2011 01:50, Gunnar Wolf wrote: > [...] > > Anyway - Summing up what I'm saying here, tags have a clear meaning: A > point where upstream wants us to base our efforts at, mid-devel-cycle > breakage should be at a minimum. So, instead of basing our packages > off arbitrary commit hashes, why not basing them off tags? I do not > believe it is unreasonable to request upstreams to do some tagging... Because, some times, upstreams don't release at all. See clutter-sharp for a good example of an upstream with not a single tag or release. For the record, I've requested an actual release multiple times before falling back upon packaging a git snapshot. For other times, perhaps there is a reason to want a pre-release snapshot in the Debian archive, perhaps because there is a fix committed in upstream git that fixes an RC bug in Debian but is near impossible to backport. Or perhaps there are a series of fixes that have not been released yet for reasons unrelated to Debian. Honestly, although I gravitate towards the tarball releases (which are tagged), I can think of any number of reasons for an upstream snapshot to be necessary. -- Kind regards, Loong Jin signature.asc Description: OpenPGP digital signature
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Tue, 26 Apr 2011, Chow Loong Jin wrote: > On 26/04/2011 01:50, Gunnar Wolf wrote: > > Anyway - Summing up what I'm saying here, tags have a clear meaning: A > > point where upstream wants us to base our efforts at, mid-devel-cycle > > breakage should be at a minimum. So, instead of basing our packages > > off arbitrary commit hashes, why not basing them off tags? I do not > > believe it is unreasonable to request upstreams to do some tagging... > > Because, some times, upstreams don't release at all. See clutter-sharp for a > good example of an upstream with not a single tag or release. For the record, > I've requested an actual release multiple times before falling back upon > packaging a git snapshot. Then, you use UTC date+time, that's two digits for the best-practice leading of "0.", plus 13 digits for MMDDTHHMM, which is quite precise enough most of the time. Add two more for seconds, and it is almost always precise enough to identify the head commit in a branch, and you already know which branch of which tree because that information must be available and up-to-date in debian/copyright. That still leaves enough space for the debian revision, security updates, bin-NMUs, NMUs and backporting. And you can supplement the version information with the full commit hash and even the repo path in the debian/changelog entry for the upload. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425190711.gc18...@khazad-dum.debian.net
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Mon, Apr 25, 2011 at 04:07:11PM -0300, Henrique de Moraes Holschuh wrote:
[...]
> Then, you use UTC date+time, that's two digits for the
> best-practice leading of "0.", plus 13 digits for MMDDTHHMM,
> which is quite precise enough most of the time. Add two more for
> seconds, and it is almost always precise enough to identify the
> head commit in a branch
[...]
Or use seconds since the epoch (which is what I do) to get the same
precision in only 10 decimal digits, though arguably less
human-readable. For that matter, converting epoch seconds to
hexidecimal gets it down to 8 characters while still sorting
chronologically...
--
{ IRL(Jeremy_Stanley); WWW(http://fungi.yuggoth.org/); PGP(43495829);
WHOIS(STANL3-ARIN); SMTP(fu...@yuggoth.org); FINGER(fu...@yuggoth.org);
MUD(kin...@katarsis.mudpy.org:6669); IRC(fu...@irc.yuggoth.org#ccl);
ICQ(114362511); YAHOO(crawlingchaoslabs); AIM(dreadazathoth); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110425193700.gr1...@yuggoth.org
Re: some suggestions towards a Debian .desktop policy [Was: Warm up discussion about desktop files]
On 22/04/2011 18:05, Josselin Mouette wrote: > Le vendredi 22 avril 2011 à 17:51 +0200, Bernhard R. Link a écrit : >> The difference is that a user has to know more when enabling stuff, as >> they get shown many things were enabling does not make any sense. >> And there is no way to say "show me everything in the menu", which is >> especially bad for environments were assuming you know what they need >> is even more likely wrong. > > You’re missing something. A menu that “shows everything” is unusable. > The Debian menu is a very good example of that kind of problem. It depends on your 'menu' use. I've a few application icons directly in my panel (the applications I always use). For application I sometimes use, I generally start them by typing in a terminal. So, my menu use is: - to drag application icon in the panel - to see all the applications in a domain that are installed on my system when I want to be some unusual things (recording and editing sound recently). The Debian menu is the best way for me to find the info (the gnome menu without the Debian submenu is way to restricted to be useful in this case). I do not understand why you cannot understand that some people do not necessarily use menus as the gnome team wants its "users" to use it (ie as a preselected small list of applications fully integrated with gnome) > Try a lenny system (or a squeeze system with a disabled > gnome-menus-blacklist) and install both KDE and GNOME full desktops. Now > try to use the GNOME panel for an hour. vdanjean@eyak:~$ sudo gnome-menus-blacklist --help vdanjean@eyak:~$ sudo gnome-menus-blacklist -h vdanjean@eyak:~$ sudo gnome-menus-blacklist vdanjean@eyak:~$ man gnome-menus-blacklist Aucune entrée de manuel pour gnome-menus-blacklist vdanjean@eyak:~$ dlocate gnome-menus-blacklist gnome-menus: /usr/sbin/gnome-menus-blacklist vdanjean@eyak:~$ zgrep -i blacklist /usr/share/gnome-menus/* vdanjean@eyak:~$ Where is the information about gnome-menus-blacklist ? Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial packages: http://moais.imag.fr/membres/vincent.danjean/deb.html APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4db5d4db.6080...@free.fr
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote: > On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote: > > On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > > > I would like to see policy forbid the use of commit hashes in versions. > > > They aren't ordered, and the information about exactly which commit the > > > snapshot was can be included in the changelog. > > > > If you use "git describe", removing hashes is a bad idea. > > > > They are needed to identify the version. Version numbers that are not > > unique are worthless. > > If versions are not ordered without the inclusion of a commit hash, they > are not ordered *with* it (except by chance). Remember that version numbers have two purposes: 1. ordering 2. uniquely referencing a snapshot of source (blessed as a release or not) I'd call 2. more important than 1. > > A small portion of the hash is there only to disambiguate potential > > branches, ordering is provided by the number of commits: > > 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it, > > from a branch whose head's hash starts with 1143071. > > > > If I take revision 282 and apply patch X, while you take the same revision > > but apply patch Y instead, we both would have the same version number if > > hash is not included. > > But it is not possible for a branch head to be in two different > positions at different times which 'git describe' will distinguish only > by the hash, unless it is rebased. * git commit --amend * any edit to an earlier commit * reparenting, etc * resetting to another version of the branch that has the same commit count * two developers or one developer with two machines or directories * many, many other ways Mere count of commits is pretty worthless in a distributed system. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425202520.ga15...@angband.pl
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote: > On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote: > > On Sun, 2011-04-24 at 02:31 +0200, Adam Borowski wrote: > > > On Sat, Apr 23, 2011 at 03:06:39PM +0100, Ben Hutchings wrote: > > > > I would like to see policy forbid the use of commit hashes in versions. > > > > They aren't ordered, and the information about exactly which commit the > > > > snapshot was can be included in the changelog. > > > > > > If you use "git describe", removing hashes is a bad idea. > > > > > > They are needed to identify the version. Version numbers that are not > > > unique are worthless. > > > > If versions are not ordered without the inclusion of a commit hash, they > > are not ordered *with* it (except by chance). > > Remember that version numbers have two purposes: > 1. ordering > 2. uniquely referencing a snapshot of source (blessed as a release or not) > > I'd call 2. more important than 1. It's not very important in the Debian archive. > > > A small portion of the hash is there only to disambiguate potential > > > branches, ordering is provided by the number of commits: > > > 0.9.0-a0-283-g1143071 means: tag "0.9.0-a0", with 283 revisions after it, > > > from a branch whose head's hash starts with 1143071. > > > > > > If I take revision 282 and apply patch X, while you take the same revision > > > but apply patch Y instead, we both would have the same version number if > > > hash is not included. > > > > But it is not possible for a branch head to be in two different > > positions at different times which 'git describe' will distinguish only > > by the hash, unless it is rebased. > > * git commit --amend > * any edit to an earlier commit > * reparenting, etc Isn't that what I just said? > * resetting to another version of the branch that has the same commit count > * two developers or one developer with two machines or directories > * many, many other ways > > Mere count of commits is pretty worthless in a distributed system. If your upstream is pulling such tricks then you cannot use this type of version *with or without* the hash, because it will not be ordered properly. You would have to use a date/timestamp. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Mon, Apr 25, 2011 at 10:29:53PM +0100, Ben Hutchings wrote: > On Mon, 2011-04-25 at 22:25 +0200, Adam Borowski wrote: > > On Sun, Apr 24, 2011 at 04:54:46AM +0100, Ben Hutchings wrote: > > > If versions are not ordered without the inclusion of a commit hash, they > > > are not ordered *with* it (except by chance). > > > > Remember that version numbers have two purposes: > > 1. ordering > > 2. uniquely referencing a snapshot of source (blessed as a release or not) > > > > I'd call 2. more important than 1. > > It's not very important in the Debian archive. Telling someone "the bug is in a version I pulled from the VCS but didn't bother noting down which version it was" is not very useful. > > > But it is not possible for a branch head to be in two different > > > positions at different times which 'git describe' will distinguish only > > > by the hash, unless it is rebased. > > > * resetting to another version of the branch that has the same commit count > > * two developers or one developer with two machines or directories > > * many, many other ways > > > > Mere count of commits is pretty worthless in a distributed system. > > If your upstream is pulling such tricks then you cannot use this type of > version *with or without* the hash, because it will not be ordered > properly. You would have to use a date/timestamp. Eh? It is exactly why the hash is there! No matter how many commits were done at a particular date, and whether the commit was cherry-picked, rebased or tossed around in other ways, a hash will let you tell which exactly version it is. A date or timestamp will not. -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. signature.asc Description: Digital signature
Bug#624142: ITP: libapache2-authcookie-perl -- Perl Authentication and Authorization via cookies.
Package: wnpp Severity: wishlist Owner: Keith Lawson * Package name: libapache2-authcookie-perl Version : 3.18 Upstream Author : Michael Schout * URL : http://search.cpan.org/dist/Apache-AuthCookie/ * License : GPL, Artistic Programming Lang: Perl Description : Perl Authentication and Authorization via cookies. Apache2::AuthCookie allows you to intercept a user's first unauthenticated access to a protected document. The user will be presented with a custom form where they can enter authentication credentials. The credentials are posted to the server where AuthCookie verifies them and returns a session key. The session key is returned to the user's browser as a cookie. As a cookie, the browser will pass the session key on every subsequent accesses. AuthCookie will verify the session key and re-authenticate the user. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110425221124.26570.61403.reportbug@vegas
Re: limits for package name and version (MBF alert: ... .deb filenames)
On Tue, 26 Apr 2011, Adam Borowski wrote:
> Telling someone "the bug is in a version I pulled from the VCS but didn't
> bother noting down which version it was" is not very useful.
Now you're being silly.
All you need is the proper date and time to use as a version (for
ordering), and a proper debian/changelog entry:
* New upstream source (git://blah, commit "blah: did something",
[#12030a47ebafdcd]).
I.e. the best current practice. How surprising. Now you either tell
upstream when you checked out his tree (and he can locate the commit by
date/time), or look the hash in debian/changelog and tell him that, and
he might be able to locate the commit even on rebased trees.
Kindly recall we need to limit version string lenght a _LOT_ and will be
doing that shortly one way or the other. $(git describe) is out right
there: it cannot be trusted to fit unless you're just using it to get a tag
with a known to be short pattern, which is not what this is about.
And you certainly should not waste 32 chars for the entire hash since it
is unordered and you need space before it for ordering, and space after
it for all the other stuff we tack at the end, so even that is out.
> > If your upstream is pulling such tricks then you cannot use this type of
> > version *with or without* the hash, because it will not be ordered
> > properly. You would have to use a date/timestamp.
>
> Eh? It is exactly why the hash is there!
No, it isn't. The *FULL* hash is there to identify a commit in that
repository to the VCS. It is certainly not there to identify a release to
human beings or distro packaging systems.
And since the hash is NOT fit for such a job in the first place, you have to
supplement it with ordering for it to become meaningful for release
identification ("which one is newer?"), and we don't have space for all that
stuff in the version string.
Also, it IS worth reminding all that git-describe output has *NO* forward
uniqueness guarantees: for that it would have to always use the full hash,
and even that could break should we be forced to drop sha1 for something
longer.
It also cannot be used [safely] to locate commits that were rebased (and
neither can the hash). So, again, you're down to the full hash, and even
that is not good enough by itself [it is not future-proof when a rebase is
not impossible].
> No matter how many commits were done at a particular date, and whether the
> commit was cherry-picked, rebased or tossed around in other ways, a hash
> will let you tell which exactly version it is.
At one point in time, which is not relevant anymore (a rebase happened), and
the object the hash used to point to might have been lost (garbage
collection).
You're either supposed to not rebase anything that is ever made public, or
to identify a commit by its title when it is unique enough, otherwise by
(author, date, title).
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110426022453.ga6...@khazad-dum.debian.net
Re: limits for package name and version (MBF alert: ... .deb filenames)
Henrique de Moraes Holschuh debian.org> writes:
> On Tue, 26 Apr 2011, Adam Borowski wrote:
> > Telling someone "the bug is in a version I pulled from the VCS but didn't
> > bother noting down which version it was" is not very useful.
>
> Now you're being silly.
>
> All you need is the proper date and time to use as a version (for
> ordering), and a proper debian/changelog entry:
>
> * New upstream source (git://blah, commit "blah: did something",
> [#12030a47ebafdcd]).
>
> I.e. the best current practice. How surprising. Now you either tell
Using date and time as a version is not current best practice. You'll still need
the upstream version part too to sort correctly relative to released versions.
So you'll have the latest upstream version tag, followed by a long timestamp.
That's no shorter than typical 'git describe' output, just a lot less
functional.
> upstream when you checked out his tree (and he can locate the commit by
> date/time), or look the hash in debian/changelog and tell him that, and
> he might be able to locate the commit even on rebased trees.
It's naive to think that identifying revisions by timestamp would be that simple
when dealing with distributed revision control systems. There are at least 3
different timestamp types that are relevant to git:
1) The closest analogue to traditional "svn2005" versions would be the time
when the commit appeared in a certain branch on a canonical central server.
However, information about when the commits were pushed to a particular server
is not stored in the repository history. Thus this form cannot be used for DVCS.
2) The author timestamps stored in commits are the timestamps most prominently
displayed by various tools. However they're not ordered as those timestamps can
come from commits cherry-picked in arbitrary order.
3) The stored committer timestamps are the most realistic alternative, but still
not a good one. If there is only a single relevant "master" branch from which
packaged versions will be taken, history of that branch is never modified, and
everyone creating commits sets the timestamps accurately, then in that case they
will be ordered. But they don't match the time when the changes were publicly
visible, and even less when they were available in that particular master
branch. Also one-second accuracy in version timestamps would not be enough to
identify a particular revision. Cherry-picking, rebasing or applying a series of
mailed patches can create a long run of closely spaced committer timestamps very
rapidly (and rebasing here can be before the changes are first made public, so
would occur in projects that do not modify public history).
Your above "tell upstream when you checked out his tree and he can locate the
commit by date/time" would only work properly for timestamps of type 1). But
that's not an at all realistic alternative.
What you wrote about identifying branches in your other mail ("and you already
know which branch of which tree because that information must be available and
up-to-date in debian/copyright") is also wrong or at least meaningless. Maybe
you'll know that the code was available on the project's public repository under
the branchname "fixes-for-debian" at the time it was downloaded. But what good
will that information do for you later, if the contents of that branch were
merged to another and the obsolete branch name then deleted two days after being
created? In the typical case branch names are not persistent information.
> Also, it IS worth reminding all that git-describe output has *NO* forward
> uniqueness guarantees: for that it would have to always use the full hash,
> and even that could break should we be forced to drop sha1 for something
> longer.
That's wrong in several ways. Even if a hash prefix of the length included in
'git describe' output stopped being unique at some point in the future there
isn't much risk of real confusion (or would you really be unable to tell whether
it's the version from around now or the one from 3 years in the future that's
meant?). And the overall version would still be unique if the tag part changed
before then. "Have to always use the full hash" is wrong; there's no magic
property which makes the hash unique at exactly the full length, that's just the
maximum possible you can take (shorter prefixes will be unique in practice). And
moving from sha1 to something else would not have to invalidate the uniqueness
properties of existing sha1 hashes.
> > No matter how many commits were done at a particular date, and whether the
> > commit was cherry-picked, rebased or tossed around in other ways, a hash
> > will let you tell which exactly version it is.
>
> At one point in time, which is not relevant anymore (a rebase happened), and
> the object the hash used to point to might have been lost (garbage
> collection).
>
> You're either supposed to not rebase anything that is ever made public, or
> to identify a commit by its title when it
Bug#624163: ITP: slapos.tool.grid -- Client to deploy a SaaS system with SLAPos
Package: wnpp Severity: wishlist Owner: Arnaud Fontaine * Package name: slapos.tool.grid Version : 1.0-dev-1 Upstream Author : Vifib SARL * URL : http://www.slapos.org/ * License : GPL-3 Programming Lang: Python Description : Client to deploy a SaaS system with SLAPos SLAPos (acronym for Simple Language for Accounting and Provisioning) provides support for deploying a SaaS system. Slapgrid is the client side of SLAPos and allows you to easily deploy instances of software based on buildout profiles. I will maintain as part of my work. This package will be packaged within the python-apps Debian team. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426055742.13869.71109.reportbug@localhost
Re: Berkeley DB plan for future
Hi. Le lundi 25 avril 2011 à 10:29 +0200, Ondřej Surý a écrit : > Hi, > > if your package depends on libdbX.Y you probably want to at least look at it: > > http://wiki.debian.org/BerkeleyDB > http://wiki.debian.org/ReleaseGoals/BerkeleyDB > Why not interlinking these 2 pages ? > O. > [Please discuss in pkg-db-devel, or at least Cc me, I am not > subscribed to debian-devel] Maybe a list of such rdepends package + maintainers would help. My 2 cents, -- Olivier BERGER http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingénieur Recherche - Dept INF Institut TELECOM, SudParis (http://www.it-sudparis.eu/), Evry (France) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1303797963.16435.1.ca...@inf-8657.int-evry.fr
Bug#624168: ITP: libcgi-session-driver-memcached-perl -- CGI::Session driver for memcached
Package: wnpp Severity: wishlist Owner: Robin Sheat * Package name: libcgi-session-driver-memcached-perl Version : 0.04 Upstream Author : Kazuhiro Oinuma * URL : http://search.cpan.org/~oinume/CGI-Session-Driver-memcached-0.04/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : CGI::Session driver for memcached CGI::Session::Driver::memcached allows CGI session data to be stored in memcached. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110426063217.12750.21036.report...@debmaker32.wgtn.cat-it.co.nz
