Re: version format for git snapshot
On Tue, Sep 15, 2015 at 1:24 AM, Colin Watson wrote: > > This is what I generally do: last release + "git" + ISO 8601 date and > time > > + 10-char substring of the commit id. I. e: > > > > 0.5+git20150531T211420-cdd9d98f2c-1 > > IME it is in fact useful to have version numbers that stand a chance of > fitting in people's short-term memory. > > That's definitely an advantage of your schema over my schema. The idea of having the commit id in the version string was to make versions (easily) machine processable. But if one is not going to release more than one snapshot a day (and I guess very few people do -- I rarely do!), then it's something to consider, definitely. Hmmm I'll have to think what to do next time I'm going to package snapshots! :-) Thank you for sharing! -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 10:46:10AM +0200, Pau Garcia i Quiles wrote: > On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote: > > I wouldn't put the commit identifier in the package version at all. It > > isn't sortable, so clearly doesn't belong in a version string; it can be > > documented in the changelog instead. I'd put a date in the version. > > The problem with date is searching in git log is difficult. You can still add the commit ID to the changelog as plain text for your later convenience when searching git log. That doesn't imply putting it in the version string, which (depending on how it's done) is either a non-sortable obstacle or simply cruft. Version numbers don't need to contain essays on the provenance of the code. > This is what I generally do: last release + "git" + ISO 8601 date and time > + 10-char substring of the commit id. I. e: > > 0.5+git20150531T211420-cdd9d98f2c-1 IME it is in fact useful to have version numbers that stand a chance of fitting in people's short-term memory. -- Colin Watson [cjwat...@debian.org]
Bug#799015: ITP: rasdaemon -- utility to receive RAS error messages
Package: wnpp Severity: wishlist Owner: Al Stone * Package name: rasdaemon Version : 0.5.6 Upstream Author : Mauro Carvalho Chehab * URL : https://apps.fedorahosted.org/packages/rasdaemon * License : GPL-2 Programming Lang: C Description : utility to receive RAS error messages rasdaemon is a RAS (Reliability, Availability and Serviceability) logging tool. It currently records memory errors, using the EDAC tracing events. EDAC are drivers in the Linux kernel that handle detection of ECC errors from memory controllers for most chipsets on x86 and ARM architectures. This userspace component consists of an init script which makes sure EDAC drivers and DIMM labels are loaded at system startup, as well as a utility for reporting current error counts from the EDAC sysfs files. While the edac-utils package provides similar information, the intent of this project is to add extensive RAS information provided by the ACPI APEI (ACPI Platform Error Interfaces, Section 18 of the specification) over time. Hence, the plan is that this package will grow beyond reporting EDAC information. This package will be maintained by the submitter as part of his daily job responsibilities. And while the submitter is currently a new user of this tool, he will be using it much more frequently and will be providing new and extended functionality over time.
Bug#799011: ITP: biblesync -- multicast protocol to support Bible co-navigation
Package: wnpp Severity: wishlist Owner: Unit 193 * Package name: biblesync Version : 1.1.2 Upstream Author : Karl Kleinpaste * URL : https://github.com/karlkleinpaste/biblesync * License : public-domain Programming Lang: C++ Description : multicast protocol to support Bible co-navigation This is a C++ single class library encapsulating a protocol conduit. The premise is that there is a local network over which to multicast Bible navigation, and someone, possibly several someones, will transmit, and others will receive. The choices for when you decide to xmit and what to do when you recv are up to you as the application designer. This package is a new build-dep for Xiphos. https://anonscm.debian.org/cgit/pkg-crosswire/biblesync.git/
Bug#799001: ITP: python-arrayfire -- Python bindings for ArrayFire
Package: wnpp Severity: wishlist Owner: Ghislain Antony Vaillant * Package name: python-arrayfire Version : 3.0.20140914 Upstream Author : ArrayFire Development Group * URL : https://github.com/arrayfire/arrayfire-python * License : BSD Programming Lang: Python Description : Python bindings for ArrayFire ArrayFire is a high performance library for parallel computing wih an easy-to-use API. This project provides Python bindings for the ArrayFire library. It enables the users to write scientific computing code that is portable across CUDA, OpenCL and CPU devices. This package will be co-maintained by the Debian science team, alongside the existing ArrayFire-based ecosystem of packages.
Bug#798987: ITP: django-uwsgi -- uWSGI related tools for Django
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: django-uwsgi Version : 0.1.3 Upstream Author : Eugene MechanisM * URL : https://github.com/unbit/django-uwsgi * License : Expat Programming Lang: Python Description : uWSGI related tools for Django django-uwsgi provides several features for Django projects deployed to uWSGI: . * Admin page with uWSGI stats (options to reload/stop uWSGI, clear uWSGI cache) * uWSGI Cache Backend for Django * uWSGI Email Backend for Django(send emails via uWSGI's spooler) * Debug Panel for django-debug-toolbar (offers same functions as admin page) * Django template loader for embedded into uWSGI files * Django Management Command runuwsgi (with live autoreload when DEBUG is True) * uWSGI config generator * Django CBV Mixins based on uWSGI decorators -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJV9wazAAoJEGlMre9Rx7W2tMkQAIdBWjMYoy9fZh9SQBS9S/QH PE/fIdfE93usCs/JQ4gQoM5XPnVNn2gIc71tw3jFDiTGkjV8CX7ZUe5sVRfPZNVd dnv5vK4qi1wwzC8HSck6QPLg/abhiwASV7cSpJ7oMCKFodSNpKHbTRv+Hz44TJMn EH6EnRmwuhUEdma1jgCEepcfqWl0kn50eGt5wSLnLK2FGTNRTwnmSDrUBNGkjDfD 9daphqCqmHXF4mmID56FTgsfIL82ugN15oZoBFO+WIori1kE23g1AIobWYR/Wp2i NdfGAOIrVbMaaPKusD2agIwS+/TqEoFsnoTzr28YIdGdQTCG6xt30aFIVN03kvOs oKXFXH0kX/A8HOGVod1XSHiD5297txizsR1OOUITH8ZkFQUteEJvwum8PeqnD+UP HtT3lStv3l9CbFFg0UfA087ug5Zz4/1gUALmLMpP9iu1RNUO2M4dhKXdKpoFZoa5 5g3SnkbzGLPrCP4GqiXsWM6jbnTXr9jw8c/usk66h5YBxMyFfgC2MgcbX9eVh5U/ w3w3ML9We9OzPzMe6Sh90BxeOtLkqbw6jm74J3xkpBHz3X6CMmVTdsOrRkwa5TvD GEj3choTlO9+2kZpdBNv1bHwCxZ0p7Kqe9GElbOhNXNOjFQ2UpSOrff52PgPLxwY RHf2TI4CQsipfqoodFcn =S2A5 -END PGP SIGNATURE-
Re: is the whole unstable still broken by gcc-5?
* Andrey Rahmatullin , 2015-09-14, 20:42: The single thing that I found aptitude useful for is finding and removing packages that are unavailable in current debian release anymore :) Try apt-show-versions Try "apt list". -- Jakub Wilk
Re: is the whole unstable still broken by gcc-5?
On Sat, Sep 12, 2015 at 11:17:32PM +0300, Виталий Филиппов wrote: > The single thing that I found aptitude useful for is finding and removing > packages that are unavailable in current debian release anymore :) Try apt-show-versions -- WBR, wRAR signature.asc Description: Digital signature
Re: is the whole unstable still broken by gcc-5?
Виталий Филиппов yourcmc.ru> writes: > > Try using aptitude instead of apt. It sometimes does a better job, and > I've tried and it offered me 100500 different insane ways of solving the > situation... :) that's why I don't use it, its solver seems really insane. > apt-get is far more rational :) Heh, true. > The single thing that I found aptitude useful for is finding and removing > packages that are unavailable in current debian release anymore :) I use dselect for that. During the transition (which seems to be mostly over now), I just used 'apt-get upgrade --with-new-packages' and a bunch of manual 'apt-get install libfoov5; apt-mark auto libfoov5' to help it along. Occasionally, set things on hold. I have this in apt.conf: debug::pkgproblemresolver "true"; APT::Install-Recommends "0"; Dpkg::Progress-Fancy "false"; The output of the pkgproblemresolver is virtually illegible, but sometimes helps tracking down stuff. bye, //mirabilos
Re: version format for git snapshot
Quoting Pau Garcia i Quiles (2015-09-14 12:23:57) > > On Monday, September 14, 2015, Jonas Smedegaard wrote: >> Makes perfect sense to me to add only the date for snapshot releases >> - both revision control system and commit id is irrelevant in version >> string - those belong (if at all) in changelog along with release >> nickname and whether release coincided with your birthday. >> >> I will use this scheme from now on: >> >> 0.4+20150911 > > What if you take a second snapshot on that day? 0.4+20150911.1 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: version format for git snapshot
On 2015-09-14 at 05:04, Jakub Wilk wrote: > * Pau Garcia i Quiles , 2015-09-14, 10:46: > >> 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 > > Still shorter than > 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. You're not > trying hard enough. I am reminded of this entry from the fortunes database: * In anticipation of 2.10.02 release, updated to patchlevel +ircu2.10.01+.config6-7.config7-8.lgline3.iwho.limit.glibc.motdcache2.trace.whois1-2.config8-9.statsw.sprintf2-3.msgtree2.memleak1-2+.msgtree2-3.gline8-9.gline9-10.invite2.rbr.stats.numclients.whisper.whisper1-2.stats1-2.nokick1-2.chroot.config9-11.snomask7-8.limi+t1-3.userip1-3.userip3-4.config11-12.config12-13.umode2-3.akillsbt.who4-5.kn.kn1-2.freebsdcore2.msgtree3-5.y2k.glibc1-2.rmfunc.msgf+lags2.who5-6.nickchange2.glibc2-3.modeless3 -- From the annoucement of ircd 2.10.01-3 for Debian GNU/Linux -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Re: [DH] Planning to remove deprecated commands and compat levels in debhelper
On 14 September 2015 at 11:11, Matthias Klose wrote: > On 09/14/2015 08:38 AM, Niels Thykier wrote: >> On 2015-09-13 21:02, Matthias Klose wrote: >>> [...] >>> >>> still using the globbing feature for command line arguments in DH_COMPAT=2 >>> mode. >>> Was this re-added in higher levels again? >>> >>> Matthias >>> >> >> Hi Matthias, >> >> Ok, I was not aware of this feature. To be honest, I suspect it was an >> artefact of the old implementation rather than being intentional. >> Digging through the documentation and the commit logs, I could not find >> any mention of it. >> >> Are you using dh_movefiles here because dh_install does not support wild >> arguments? Or would dh_install not work for you regardless? > > I didn't check if dh_install supports wild card arguments. I'm using > dh_movefiles to check if I package every relevant file, so assuming dh_install > would support the globbing, this still leaves the question how to check for > the > completeness of the packaging. And I'm not going to write 150 .install files > just to be able to use dh_install --missing. If there's no solution, I just > would embed a dh_movefiles copy in the packaging. dh_install does not support renaming, unlike dh_movefiles. This is the only limitation that I am aware off. One can write out $pkg.install files, or even make them executable generators, or just specify pairs in the dh_install invocation. Or use a mix of args & $pkg.install files. -- Regards, Dimitri.
Re: [DH] Planning to remove deprecated commands and compat levels in debhelper
On 14/09/15 11:11, Matthias Klose wrote: > On 09/14/2015 08:38 AM, Niels Thykier wrote: >> Are you using dh_movefiles here because dh_install does not support wild >> arguments? Or would dh_install not work for you regardless? > > I didn't check if dh_install supports wild card arguments. I'm using > dh_movefiles to check if I package every relevant file, so assuming dh_install > would support the globbing, this still leaves the question how to check for > the > completeness of the packaging. And I'm not going to write 150 .install files > just to be able to use dh_install --missing. If you're referring to this pattern in e.g. gcc-5: DH_COMPAT=2 dh_movefiles -p$(p_cpp) $(files_cpp) then you can do a very similar thing with dh_install: override_dh_install: dh_install -pmypackage 'usr/share/mypackage/*' dh_install -pmypackage debian/myscript usr/bin ... dh_install --remaining-packages --list-missing (src:dbus uses this trick, for instance.) S
Re: version format for git snapshot
On Mon, 14 Sep 2015 07:51:09 +0200 Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current > master commit a5e5f9e that is 24 commits after 0.4. Please assume > that this makes sense... > > How would you format the upstream part of the packages version > number? How about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? One of the steps I use is to look at the rev-list to get a sequential number which is based on the actual commits but is in a sane sequence. https://git.linaro.org/lava/lava-dispatcher.git/blob/HEAD:/version.py git rev-list --count HEAD These are local developer builds, not usually released, but still - could be useful for someone. As well as sticking the short hash in the changelog entry, we also append it to the version. ava-dispatcher 2015.9.3908.875bd74-1 amd64 The rev-list takes care of the hash not being a reliable sort as the hash is effectively hidden from the sort algorithm. It's added because it's a simple way of looking up the commit on gitolite etc. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpRg2XdPKY57.pgp Description: OpenPGP digital signature
Re: version format for git snapshot
On Monday, September 14, 2015, Jonas Smedegaard wrote: Makes perfect sense to me to add only the date for snapshot releases - > both revision control system and commit id is irrelevant in version > string - those belong (if at all) in changelog along with release > nickname and whether release coincided with your birthday. > > I will use this scheme from now on: > > 0.4+20150911 > > What if you take a second snapshot on that day? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: [DH] Planning to remove deprecated commands and compat levels in debhelper
On 09/14/2015 08:38 AM, Niels Thykier wrote: > On 2015-09-13 21:02, Matthias Klose wrote: >> [...] >> >> still using the globbing feature for command line arguments in DH_COMPAT=2 >> mode. >> Was this re-added in higher levels again? >> >> Matthias >> > > Hi Matthias, > > Ok, I was not aware of this feature. To be honest, I suspect it was an > artefact of the old implementation rather than being intentional. > Digging through the documentation and the commit logs, I could not find > any mention of it. > > Are you using dh_movefiles here because dh_install does not support wild > arguments? Or would dh_install not work for you regardless? I didn't check if dh_install supports wild card arguments. I'm using dh_movefiles to check if I package every relevant file, so assuming dh_install would support the globbing, this still leaves the question how to check for the completeness of the packaging. And I'm not going to write 150 .install files just to be able to use dh_install --missing. If there's no solution, I just would embed a dh_movefiles copy in the packaging. Matthias
Re: version format for git snapshot
Quoting Colin Watson (2015-09-14 08:51:48) > On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: >> How would you format the upstream part of the packages version >> number? How about 0.4+24+git+a5e5f9e? > > I wouldn't put the commit identifier in the package version at all. > It isn't sortable, so clearly doesn't belong in a version string; it > can be documented in the changelog instead. I'd put a date in the > version. Makes perfect sense to me to add only the date for snapshot releases - both revision control system and commit id is irrelevant in version string - those belong (if at all) in changelog along with release nickname and whether release coincided with your birthday. I will use this scheme from now on: 0.4+20150911 - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 11:04 AM, Jakub Wilk wrote: * Pau Garcia i Quiles , 2015-09-14, 10:46: > >> 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 >> > > Still shorter than 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. > You're not trying hard enough. Oh well, I'm just trying to get all the required information with minimal verboseness :-) You don't need the full commit id, 10 chars is usually more than enough in a repository -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
* Pau Garcia i Quiles , 2015-09-14, 10:46: 0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1 Still shorter than 1.31~pre0.8052aabdd159bc9050e7dc264f33782c5acce05f-1. You're not trying hard enough. -- Jakub Wilk
Bug#798933: ITP: libtie-hash-expire-perl -- Perl module providing hashes with keys that expire after a user-set period
Package: wnpp Owner: Florian Schlichting Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org * Package name: libtie-hash-expire-perl Version : 0.03 Upstream Author : Jeff Yoak * URL : https://metacpan.org/release/Tie-Hash-Expire * License : Artistic or GPL-1+ Programming Lang: Perl Description : Perl module providing hashes with keys that expire after a user-set period Hashes tied to Tie::Hash::Expire behave like normal hashes in all respects except that when a key is added or the value associated with a key is changed, the current time is stored, and after 'expire_seconds' the key and value are removed from the hash. Resolutions finer than seconds are available if the module finds access to Time::HiRes. The package will be maintained under the umbrella of the Debian Perl Group.
Re: version format for git snapshot
On Mon, Sep 14, 2015 at 8:51 AM, Colin Watson wrote:
On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote:
> > How would you format the upstream part of the packages version number?
> How
> > about 0.4+24+git+a5e5f9e?
>
> I wouldn't put the commit identifier in the package version at all. It
> isn't sortable, so clearly doesn't belong in a version string; it can be
> documented in the changelog instead. I'd put a date in the version.
>
The problem with date is searching in git log is difficult.
This is what I generally do: last release + "git" + ISO 8601 date and time
+ 10-char substring of the commit id. I. e:
0.5+git20150531T211420-cdd9d98f2c-1
It includes all the information:
- Last release (0.5)
- It's screaming "I'm a git snapshot!" ("git")
- It's sortable thanks to the ISO 8601 date *and* time (20150531T211420)
- Commit id, for easier search in git log, git describe, etc (cdd9d98f2c)
- Debian packaging version (1)
- It's consistent: it's always the same regex, with no room for optional
fields
Using the time is required, otherwise if there are two snapshots in one
day, they may get the wrong sorting order due to the git commit id.
Do you think it's ugly? Wait to see what it gets to when I upload packages
to my Ubuntu PPA :-)
0.5+git20150531T211420-cdd9d98f2c-1~vivid~pgquiles1
IMHO it'd be great if we could standardize on something, not matter what it
is.
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
Re: version format for git snapshot
Hello Thomas Koch! On Mon, Sep 14, 2015 at 07:51:09AM +0200, Thomas Koch wrote: > Hi, > > my upstream tagged 0.4 a year ago and I want to package the current master > commit a5e5f9e that is 24 commits after 0.4. Please assume that this makes > sense... > > How would you format the upstream part of the packages version number? How > about 0.4+24+git+a5e5f9e? > > The git describe output is v0.4-24-ga5e5f9e. > > Is there any established best practice? I see there are already multiple suggestions, so here's yet another color suggestion for the bikeshed... The below mentioned format is understood by /usr/share/gnome-pkg-tools/1/rules/gnome-get-source.mk which will download (or in this case generate) the orig tarball on fakeroot debian/rules get-orig-source for all pkg-gnome packages. (But ofcourse, even though there are alot of packages supporting this format we rarely do git snapshots so you won't find many of them in the archive currently.) # search for a GIT revision in the version of the changelog # accepted formats: foo+git20090430.42ad43 (or ~ instead of +) DEB_UPSTREAM_GIT_REV ?= $(shell echo $(DEB_UPSTREAM_VERSION) | sed -rn 's/^.*[\.~+\d]+git[0-9]+\.([0-9a-f]+)$$/\1/p') In my opinion this formatting is good, simple and reasonably short (compared to similar suggestions). Regards, Andreas Henriksson
Bug#798920: ITP: djangorestframework-extensions -- custom extensions for Django REST framework
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: djangorestframework-extensions Version : 0.2.7 Upstream Author : Gennady Chibisov * URL : https://github.com/chibisov/drf-extensions * License : Expat Programming Lang: Python Description : custom extensions for Django REST framework a collection of custom extensions for Django REST Framework. It provides several mixins and extensions to code mechanics of Django REST framework. . Some of the features included: * DetailSerializerMixin * Collection level @action and @link controller decorators * Custom endpoint name for @action and @link decorators * Caching * Conditional requests * Customizable key construction for caching and conditional requests -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJV9nLyAAoJEGlMre9Rx7W2iuoP/3aAq6d2u4AdlyAG3tfK1CLQ xmtqwS6syYqXSwn/LC8JJN89LHwiXGZEojkzTcJcbcK8qjzWhISxlGwlupUS8jgd kM12Bxuu6vhy65e+ZNoghvnOoeKaTh98piVF34upCGJNy4LfEy1zyTMHFW6fPRmj D5Fl97mJCb68VgZQqH28z1YUCXe7iRjAPSpJjFE+W68GdKS0bEp+1b0tagsF1Gh7 +VP9wDkG8fSVj5GiUqO4st+1iq+7/NsZi/ABAB6s+RX0GBV9/HnHbO8QhpKI98q5 IPbeCFCSp1q7J3VynPq7bsFhmWQ+vO2USAt3WhM4OXtsjFnizlxESj3H0FY13W8b ltzJJcxUx/Mmcp9r1S8pCMnpJggv82v8sGiWTsPMalkSHjrbyWPMtoVQARj2WgCw b3xViiwi6NwbGLvE9TetoASYZ95RRPed3rFzKjoT4rj4DPSPG23Voy7BeuAa3dUa TXtzI5YGXp4ARgFyzAdkad23ibRjT4tB4EHwlygaZAR17q4wWPBOZHkTOzyJEtCO LsvrbjD9zrHWoyuSo5jcjfQ+GZyBxPAyfGACzXiNmSjGugfWfpm6jLbT4W+AcLKN ggMGDZQQXAPA+2vLWha1XgCsBs8dy1JAo6C5Ex0gzTLcXE24ZFyGJnvIzXFTW9Hr RDayc3z/igM14zLZ89DQ =c6pS -END PGP SIGNATURE-
