Bug#863076: RM: dballe/7.21-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello. I've been confused about #845833 because I was sure I had fixed it. I checked in git and I had, and now I'm confused about what git version I actually uploaded. I'd like to fix that RC bug by removing dballe from stretch, and then restart in buster with a new upload that sorts out the confusion. To the best of my knowledge, it is a leaf package with no reverse dependencies. Enrico -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
User-testing of testing?
Hello, I've just installed an up to date testing for an academic friend, and while things installed and worked really quite well sysadmin-wise, we're now stuck on such a trivial thing as clicking on a PDF attachment in thunderbird/icedove does not open the PDF in evince. While we could say it is an upstream bug and not really a packaging problem, it's not the kind of thing that would look good on a stable release. So I was wondering if we shouldn't have a list of user-centered "stable release goals", such as "open a PDF attachment in icedove", "open an OpenDocument attachment in icedove", "watch youtube videos", "copy a file to a USB key", which people trying a fresh testing install could test. I guess such a list could be kept in the wiki, with some step-by-step description of how to do it, which could then double as documentation once testing is released. Ideally this should provide a way for users to contribute to QA testing of the new release, which would be great. I however do not see an obvious way of collecting feedback for such user tasks, or for having fights over which user tasks are the most significant, without having people submit tasks to the release managers and the release managers deciding which ones are worth making official, which would be quite a burden to them. Are there ways to set up such a thing so that it mostly manages itself? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Freeze exception for cfget 0.17-1
Hello,
I've uploaded yesterday cfget 0.17-1 to unstable. Testing has 0.16-1.
This is the changelog:
* New upstream version
- Fixed a DeprecationWarning with python 2.6
- Allow empty values, treating them as unsets
- Round function returns an int, not a float
Although it is a new upstream version, the change from 0.16 is rather
minimal and it is mostly bugfixing. I am the maintainer as well as
upstream, so when I fix minor problems like a DeprecationWarning it
makes sense for me to do a new upstream release rather than a new debian
release with a patch.
The changelog has no "Closes:" entries because the bugs were found by a
customer, reported to me directly and fixed right away.
There are no packages that depend on cfget.
Debdiff:
diff -Nru cfget-0.16/cfget cfget-0.17/cfget
--- cfget-0.16/cfget2010-07-16 10:51:29.0 +0200
+++ cfget-0.17/cfget2010-08-26 17:23:11.0 +0200
@@ -9,7 +9,7 @@
import cPickle as pickle
import __builtin__
-VERSION="0.16"
+VERSION="0.17"
# Functions to report different levels of feedback. They will be redefined
# according to command line options
@@ -50,7 +50,7 @@
"Normal .ini file format"
RE_EMPTY = re.compile(r"^\s*(?:[#;].+)?$")
RE_SECTION = re.compile(r"^\s*\[([^\]]+)\]\s*$")
-RE_VALUE = re.compile(r"^\s*([^=]+)=(.+)$")
+RE_VALUE = re.compile(r"^\s*([^=]+)=(.*)$")
section = None
for lineno, line in enumerate(open(pathname)):
@@ -66,7 +66,11 @@
path = key.strip().lower()
else:
path = section + "/" + key.strip().lower()
-yield path, value.strip()
+value = value.strip()
+if value:
+yield path, value
+else:
+yield path, None
else:
raise ParseError(pathname, lineno+1, "line not a comment, and not
in the form [section] or key=value")
@@ -385,7 +389,7 @@
self.add_templater("autoconf", autoconf_replacer)
self.add_function("query", lambda db, x: db.query(x))
self.add_function("int", lambda db, x: int(x))
-self.add_function("round", lambda db, x: round(x))
+self.add_function("round", lambda db, x: int(round(x)))
self.interpreter = Interpreter(self)
def normalise_path(self, path):
@@ -401,7 +405,10 @@
for path, value in parser(pathname):
path = self.normalise_path(path)
if path is None: continue
-self.staticdb[path] = value
+if value is None:
+self.staticdb.pop(path, None)
+else:
+self.staticdb[path] = value
def load_plugin(self, pathname):
"""
@@ -734,7 +741,7 @@
sys.exit(1)
except UserError, e:
if opts.debug: raise
-warning(e.message)
+warning(str(e))
sys.exit(1)
sys.exit(0)
diff -Nru cfget-0.16/debian/changelog cfget-0.17/debian/changelog
--- cfget-0.16/debian/changelog 2010-07-16 10:52:40.0 +0200
+++ cfget-0.17/debian/changelog 2010-08-26 17:23:09.0 +0200
@@ -1,3 +1,12 @@
+cfget (0.17-1) unstable; urgency=low
+
+ * New upstream version
+ - Fixed a DeprecationWarning with python 2.6
+ - Allow empty values, treating them as unsets
+ - Round function returns an int, not a float
+
+ -- Enrico Zini Thu, 26 Aug 2010 17:23:00 +0200
+
cfget (0.16-1) unstable; urgency=low
* New upstream version
diff -Nru cfget-0.16/PKG-INFO cfget-0.17/PKG-INFO
--- cfget-0.16/PKG-INFO 2010-07-16 10:53:07.0 +0200
+++ cfget-0.17/PKG-INFO 2010-08-26 17:23:25.00000 +0200
@@ -1,6 +1,6 @@
Metadata-Version: 1.0
Name: cfget
-Version: 0.16
+Version: 0.17
Summary: get information out of config files
Home-page: UNKNOWN
Author: Enrico Zini
diff -Nru cfget-0.16/setup.py cfget-0.17/setup.py
--- cfget-0.16/setup.py 2010-07-16 10:51:29.0 +0200
+++ cfget-0.17/setup.py 2010-08-26 16:17:10.00000 +0200
@@ -3,7 +3,7 @@
setup(
name='cfget',
-version='0.16',
+version='0.17',
description='get information out of config files',
author='Enrico Zini',
author_email='enr...@enricozini.org',
diff -Nru cfget-0.16/testdata/general.ini cfget-0.17/testdata/general.ini
--- cfget-0.16/testdata/general.ini 2010-07-15 19:35:08.0 +0200
+++ cfget-0.17/testdata/general.ini 2010-08-26 16:15:48.0 +0200
@@ -4,6 +4,7 @@
start = 2009-08-07 06:05:04
end = 2009-09-08 07:06:05
answer = 42
+nothing =
[test_underscore]
works = true
diff -Nru cfget-0.16/tests/__init__.py cfget-0.17/tests/__init__.py
--- cfget-0.16/tests/__init__.py2010-07-16 10:51:29.0 +0200
+++ cfget-0.17/tests/__init__.py2010-08-26 16:15:48.0 +0
Re: LibreOffice and openoffice.org-{hyphenation,thesaurus}-*
On Tue, Jan 11, 2011 at 08:35:00PM +0100, Rene Engelhard wrote: > I discussed this a bit and we came to the following conclusion: > > a) openoffice.org-hyphenation-*: [...] > we should go with hyphen-* (as other distros - like Fedora - already do). > > b) openoffice.org-thesaurus-*: > > TTBOMK there's no other application except OOo/LibO which uses libmythes. > Are you aware of any (or of any else using the same format fwiw). > So we should rename them all to libreoffice-*... If there were some, I'd > go for mythes-*. > > Comments? Looks reasonable to me. I don't know of anything using mythes so libreoffice* sounds like the thing to do, but then again it's not much my field. OTOH one can say we can do mythes-* anyway in case other apps will start using libmythes. OTOH if there are no other users libreoffice-* is clearer. I guess you've already thought of all that, though. The 'do what the other distros are doing' is also a nice default (but then again I'm now at http://distributions.freedesktop.org/wiki/Meetings/AppInstaller2011 so today I'm biased :) Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
A simple migration plan
Hello, I'm reopening the bug since this affects users that upgrade tangogps from lenny to squeeze, and if a simple migration strategy can be found, it could still make sense to add it to a stable update. A very simple way to do it could be to ship a shellscript as /usr/bin/tangogps instead of a symlink. The shellscript being nothing more than: #!/bin/sh test -d ~/.foxtrotgps || ln -s ~/.tangogps ~/.foxtrotgps exec foxtrotgps What do you think? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Re: A simple migration plan
On Wed, Oct 19, 2011 at 06:19:27PM +0200, Philipp Kern wrote: > I guess we concluded on the Debconf stairs that it's a tad late for > this now? That all users will have had their apparent "data loss" > already? :) Indeed we did. Closing the bug. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Freeze exception for debtags 1.7.8
Hello, here is the changelog: debtags (1.7.8) testing-proposed-updates; urgency=low . * Solve name confusion between enum values and template parameters. Closes: #512640 * Improved bash-completion applying patch by Justin B Rye at #403137. * Stop smartsearch help from looping. Closes: #511669. * Don't choke on multi-line Tag: fields (although the continuation lines are currently ignored). See: #481634. * Suggests: wget. See: #478590. * Fixed Homepage: field and updated standards-version. The main point is a fix for #512640, and while I was preparing the release I also fixed or mitigated some other bugs, as long as I judged the change to be minor and uncontroversial. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini signature.asc Description: Digital signature
Freeze exception for apt-xapian-index 0.16
Hello, This is the changelog: apt-xapian-index (0.16) unstable; urgency=low . * Create /var/lib/apt-xapian-index/ in a way that is free of race conditions. Closes: #506766. * Fix cron job to be quiet if the package is removed but not purged. Closes: #502607. * Simplified searchcloud example. Nothing particularly RC, but they are very simple fixes for very annoying bugs. There is also the cleanup of an example, which got committed in and since it's just an example in /usr/share/doc I didn't bother taking it out. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini signature.asc Description: Digital signature
More notes about apt-xapian-index's freeze exception
Hello, I've noticed that apt-xapian-index in lenny is 0.13, I thought it was 0.15. There is a nontrivial change introduced in 0.15, which implements appropriate handling of concurrent updates. This is quite important because it allows a package manager to install apt-xapian-index and then run an update showing progress, without conflicting (actually, cooperating) with the index update automatically run with the package's postinst. It's a nontrivial change, but it's been there since August with no apparent issues (except for #506766 which was fixed in 0.16 with a rather simple patch). On the other hand, 0.13 has bigger problems (#509819). Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini signature.asc Description: Digital signature
Re: Proposed new release goal: Dependency/file list predictability
On Fri, Jun 22, 2007 at 01:49:25AM +0200, Steinar H. Gunderson wrote: > as it's stable.) The idea is to build a package both in a pbuilder and in > a really filled chroot -- it currently contains 18GB of packages, which is > most of the "devel" and "libdevel" sections. What is compared is: This is exciting! Another evil idea that come to my mind is running piuparts preinstalling all packages that a package conflicts on, or replaces. This topic also triggers a continuous thought that I had since the RMLL conference in France, that is to use EDOS' computed "SAT temperature" of packages[1] to make testing even nastier. [1] SAT temperature: I'm not able to explain it precisely, but it's a number that ends up being proportional to how complex is the dependency tree of a package. Ideas that come to my mind are: - testing in piuparts *couples* of packages, both with high SAT temperature; - during testing, solving dependencies so that when a package depends on A | B | C, the package with the highest SAT temperature is pulled in; - test/audit the dependencies of high-SAT-temperature packages more throughly; - compute a "delicateness" index of a package by summing the SAT temperature of all packages that depend on it, and then give special attention to the most "delicate" packages to see RC bugs, maintainer activity and so on. I'm working on creating a sample data, but I'll be away for the week-end. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Proposed new release goal: Dependency/file list predictability
On Fri, Jun 22, 2007 at 11:25:44PM +0100, Enrico Zini wrote: > - compute a "delicateness" index of a package by summing the SAT >temperature of all packages that depend on it, and then give special >attention to the most "delicate" packages to see RC bugs, maintainer >activity and so on. I'm working on creating a sample data, but I'll >be away for the week-end. I managed to hack it together just in time: a sample of the 50 most 'delicate' packages is in: http://people.debian.org/~enrico/2007-06/sample-reverse-sat.txt Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Upload of libept and apt transition
Hello, Frans told me there's an apt transition going on, but I'd like to upload a fixed libept for #455748. My plan is to upload tonight (about 6 hours from now) a new version, urgency=low. If this is a bad idea, please let me know. A Cc would be essential as I'm not on this list. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: apt transition - please bump urgency of libept
On Mon, Dec 17, 2007 at 12:51:35AM +0100, Luk Claes wrote: > Unfortunately is not going to happen as soon as we wanted due to a new > aptitude upload... This kind of scenario made me think... would it make sense to publish in a fixed location a machine-readable scenario of current ongoing transitions, then have dput fetch it and print a warning in case one is going to upload a package that would step in someone's feet? Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: apt transition - please bump urgency of libept
On Sun, Dec 16, 2007 at 08:32:31PM -0800, Daniel Burrows wrote: > I wonder if it would be a good idea to announce apt transitions on > [EMAIL PROTECTED] aptitude is not special in its dependency structure; any > upload of an apt-related package will do the same thing, and I think > maintainers of those packages are more likely to be subscribed to deity > than to -release. I could be totally mistaken in this belief, of > course. I'm with you. I'd even be happy if a mail was sent to all maintainers of rdepends of apt when a tricky transition is in place. It's quite demotivating to work 2 days on a new version, work another day on testing it and all rdepends, and finally manage to upload it, and the first reaction you get is not "ehi, that's cool!" but "cluebat that guy, he broke the transition". There were many things I was looing forward to do after my last libept upload, that I just postponed to avoid doing them in a moment where they could bring me more frustration than satisfaction. OTOH I'm sure it's even more demotivating for Frans to have to wait weeks before uploading this cool new package. So, as maintainer of C++ packages that use apt and are involved in apt transitions every so often, I would like to have some sort of handy way to know "you're free to upload to sid" or "hang on a sec, or upload to experimental". A way that possibly doesn't require following both deity@ and debian-release@ regularly. I suppose I'm not the only one, and since libapt-pkg is actively maintained and a very useful piece of software, I expect there will be even more in the future. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: apt transition - please bump urgency of libept
On Mon, Dec 17, 2007 at 11:46:00AM +0100, Adeodato Simó wrote: > > This kind of scenario made me think... would it make sense to publish in > > a fixed location a machine-readable scenario of current ongoing > > transitions, > Yes, I've very often thought there is a real need for this, but I > haven't sat down to think how to do it, and no magic idea has suddenly > visited me either. How hard would it be for the release team to maintain a file like this? Build-Depends: libapt-pkg-dev libept-dev Action: block Message: Transition to testing of 140 rdepends of apt: please contact debian-release@lists.debian.org before uploading. Build-Depends: libfoo-dev libbar-dev foobar Action: warn Message: A transition is being planned, you may want to contact xyz if you intend to upload again in the near future If that isn't too much burden, I can patch dput to download the file, check if one of the build-deps in the .dsc shows up on a record an take the appropriate action. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
BinNMU needed for debtags, debtags-edit, libept, packagesearch
Hello, there seems to be a new version of apt in unstable that requires a binNMU of debtags, debtags-edit, libept and packagesearch. Probably also goplay. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
xapian 1.0.7
Hello, I've just uploaded to unstable the Xapian suite version 1.0.7, that was the candidate for lenny. It didn't manage to get uploaded so far because of last minute polishings and work delayed due to me (sponsor) and the maintainer being in opposite timezones. It would be a shame if it didn't go in, so I'm bringing it to your attention. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Exception for debtags 1.7.7
Hello, I've uploaded a new version of the 'debtags' package version 1.7.7. The only update from the previous version is shipping an updated version of the debtags vocabulary, that includes a couple new tags and especially the updated set of tags for the security team. debdiff shows to updates to the code, except some updated autotools files as a result of me rebuilding the package off a new svn checkout. This upload is intended for lenny, and is important to get the security team tags to work. The library toolchain used to build debtags is currently the same in lenny and sid. In the future we can see about packaging the vocabulary as a binary-all package, so that if needed we can upload an updated vocabulary shortly before release without needing to bother with autobuilders: I haven't done it yet because I'm not sure about a package just to ship 60Kb of uncompressed text. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Exception for debtags 1.7.7
On Mon, Aug 18, 2008 at 02:51:54PM +0200, Pierre Habouzit wrote: > unblocked. Thanks. > On Mon, Aug 18, 2008 at 12:46:48PM +, Enrico Zini wrote: > > In the future we can see about packaging the vocabulary as a binary-all > > package, so that if needed we can upload an updated vocabulary shortly > > before release without needing to bother with autobuilders: I haven't > > done it yet because I'm not sure about a package just to ship 60Kb of > > uncompressed text. > Such a change would not meet the release freeze exceptions criteria > anyways ;) For "in the future" I meant "after lenny". I thought about bringing up the discussion here because I wanted to at least inform the release team that debtags is the package shipping the vocabulary file that is needed to accompany the Tag: fields in the Packages file. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: [Urgency] How to make libchewing & scim-chewing into Sarge?
On Fri, Mar 25, 2005 at 03:57:06PM +0800, Andrew Lee wrote: Dear Release Managers, Andrew and Kanru are very active Taiwanese Debian people, and they're working hard on making input methods work fine in Debian. I'll quote the entire message to your attention; maybe you want to coordinate with them on this issue. > Hi Enrico, > > Since debian installer has released rc3, I am quite worry about the > input method support for our users in Taiwan. > > Cause libchewing and scim-chewing are still in NEW queue: > http://qa.debian.org/~anibal/debian-NEW-summary.html > > The current scim package in sarge has well supported tables and IMs > for our users in Hong Kong and mainland China, but missed the > important one - chewing IM for most users in Taiwan. > > Most of our users in Taiwan are need scim-chewing and have been > waitting for it into Sarge for a long time. > > Could you please give me some hits how to make libchewing and > scim-chewing into Sarge as soon as possible? > > And we also hope we can put these two packages into tasksel instead of > xcin(big5 only) input method. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
C++ ABI bump for etch
Hello, from the last Release update: > If you intend to make major changes (like a C++ ABI bump) during the > development of etch, please speak with the release team as soon as > possible, describing the changes you're planning and why. This way, we > can help you to make your transitions as smooth as possible, ensuring > that packages go quickly into testing/etch, don't hold up other packages > or the release in general, and don't take us by surprise. We would > appreciate it if you could send these emails before the end of April > to [EMAIL PROTECTED] I am working on a major change on libtagcoll and libdebtags API and ABI. However, I'm planning to change the package names (from libtagcoll-dev to libtagcoll1-dev and from libdebtags-dev to libdebtags1-dev) and to package -dev libraries only, since the API and ABIs will still be not stable enough to support shlibs. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Uploaded new gnome-pim (1.4.9-2.2) fixes #247192
Hello, I just sponsored a NMU upload of gnome-pim (1.4.9-2.2) that fixes #247192. Since that is release critical, as per my understanding of the current freeze rules I'm notifying it to you. Thanks to Maurizio Lemmo for preparing this fix. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
libxml-libxml-perl status for sarge
Hello, I still haven't received news from you on #240334, and I'm quite concerned about it, as it may cause severe breakage when it is used on a website. I assume that use of the module in websites is quite common, although I don't know much about its usage patterns and thus I'm hesitant in raising the severity to grave. However, personally I only use the module in mod_perl scripting, and axkit also depends heavily on it. Since sarge is about to go out, I'm asking you to have a look at it, possibly updating the severity or just applying the attached patch. I'm Cc-ing the release manager(s) as this may turn out to become an ugly Sarge issue. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Investigation of the bug
Hello, Sorry to have been lingering on this bug: on Igloo's buildd report I saw that some of the packages were still rebuilding and I thought it was just a matter of waiting. Today I investigated a bit more. The problem is indeed connected to the C++ allocator thing, and the recompile was incomplete because debtags links statically with some libraries, and it's nonobvious to find the dependencies. Luckily, thanks to a suggestion of Jonas Smedegaard at Debconf4, I use dh_buildinfo. It turned out that the libtagcoll-dev is still built with libstdc++6 4.0.2-3. It in turn gets statically linked into libapt-front-dev, which in turn gets statically linked into debtags. So, it seems that there are some recompiles to be triggered: Step 1: libtagcoll-dev Step 2: tagcoll, tagcolledit, libapt-front-dev (since they statically link libtagcoll-dev) Step 3: debtags, debtags-edit, packagesearch (since they statically link libapt-front-dev) Thanks, Enrico Thanks also to azeem and peterS who helped me figuring some details of the course of action to follow. -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: Bug#341945: Investigation of the bug
On Sun, Dec 11, 2005 at 12:41:57AM -0800, Steve Langasek wrote: > On Sat, Dec 10, 2005 at 11:18:53AM +0100, Enrico Zini wrote: > > So, it seems that there are some recompiles to be triggered: > > Step 1: libtagcoll-dev > > Step 2: tagcoll, tagcolledit, libapt-front-dev > > (since they statically link libtagcoll-dev) > > Step 3: debtags, debtags-edit, packagesearch > > (since they statically link libapt-front-dev) > Could you perform these steps locally on your system and confirm that it > does correct the failure, before we commit buildd time on all archs to > rebuilding these? Sure. Done. It works. Here's the list of things I did: there are small mismatches with the list I gave above, as I was thinking more in terms of upstream deps than actual debian deps. * tagcoll apt-get source tagcoll cd tagcoll-1.5.1/ debuild -us -uc -rfakeroot cd .. su -c "dpkg -i libtagcoll-dev_1.5.1-1_i386.deb tagcoll_1.5.1-1_i386.deb" * tagcolledit apt-get source tagcolledit cd tagcolledit-1.2/ debuild -us -uc -rfakeroot cd .. su -c "dpkg -i tagcolledit_1.2-1_i386.deb" * libapt-front-dev apt-get source libapt-front-dev cd libapt-front-0.3.4/ debuild -us -uc -rfakeroot cd .. su -c "dpkg -i libapt-front-dev_0.3.4_i386.deb" * debtags apt-get source debtags cd debtags-1.5.2/ debuild -us -uc -rfakeroot cd .. su -c "dpkg -i debtags_1.5.2_i386.deb" * It works! * * debtags-edit apt-get source debtags-edit cd debtags-edit-1.1.2/ debuild -us -uc -rfakeroot cd .. su -c "dpkg -i debtags-edit_1.1.2_i386.deb" Haven't done packagesearch, but I think we have the idea. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#698939: nmu: grib-api_1.9.16-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu grib-api_1.9.16-2 . ALL . -m "Rebuilt with the default gfortran. Closes: #695727" When fortran compilers build a library, they generate a .mod file that is a kind of header file. The syntax of those .mod files changes from compiler to compiler, and at least in the case of gfortran, from version to version of the compiler. grib-api has been built with gfortran 4.6, and the default is now 4.7. Other fortran libraries in wheezy like netcdf are already built with 4.7. In order to be able to compile software that uses both netcdf and grib-api, grib-api needs to be rebuilt with gfortran 4.7. Ciao, Enrico -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130125131514.21595.80480.report...@viaza.enricozini.org
grib-api 1.12.3-1
Hello, I have prepared a new upload of grib-api, version 1.12.3-1. This is the main bit of the changelog: * New upstream version - grib_api has an official soname now! It means that it now builds just a standard libgrib-api0, supported by upstream, and we'd be done with having the library full version in the soname. However, I'm kind of late. Still, I've rebuilt all the reverse build dependencies with it[1], and they build fine with it. This means that the only transition needed would just be a round of binNMUs. It would be nice to have grib_api soname sanity in jessie, but I'm not uploading it without your informed and enthousiastic consent. Please let me know. The new package is on master here: http://anonscm.debian.org/cgit/collab-maint/gribapi.git [1] This is the list as far as I understand: Maintained by Alastair McKinstry: cdo, emoslib, flexpart, magics++, metview, pygrib Maintained by Youhei SASAKI: ruby-grib Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Re: grib-api 1.12.3-1
On Mon, Oct 06, 2014 at 11:44:57AM +0200, Emilio Pozuelo Monfort wrote: > It is great to have a stable soname, but this is too late for Jessie. You > can however file a transition bug now and upload the package to > experimental. But the transition will have to wait till after the freeze. Ok, I'm sad for this but I'll deal with it. Shame I haven't had time earlier. I have uploaded it to experimental. What is the point of filing a transition bug now, if it has to wait for several months before being considered? Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Bug#599281: unblock: apt-xapian-index/0.40
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package apt-xapian-index The current version in squeeze creates the index in /var/lib/ instead of /var/cache/. For people who backup /var/lib this can increase backup storage by an amount in the order of magnitude of 50Mb. It is also in violation of FHS. The bug is #594675. It is not RC because noone has raised its severity so far, and it'd be silly to raise it once the bug has been closed just to prove a point for the unblock request. However, I believe it makes sense to have this fix in squeeze. apt-xapian-index (0.40) unstable; urgency=low * Xapian cache moved to /var/cache/apt-xapian-index. Closes: #594675. -- Enrico Zini Sun, 03 Oct 2010 11:39:28 +0100 unblock apt-xapian-index/0.40 Ciao, Enrico -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101006111419.908.16021.report...@localhost
Bug#601570: unblock: omhacks/0.11-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package omhacks: it fixes #601321. unblock omhacks/0.11-2 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101027121339.20941.99424.report...@localhost
Bug#601572: unblock: libept/1.0.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package libept It fixes #601417. unblock libept/1.0.4 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101027121753.24074.24090.report...@localhost
Bug#601764: unblock: fuss-launcher/0.5-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package fuss-launcher fuss-launcher (0.5-1) unstable; urgency=low * Port to new Xapian API. Closes: #601760 -- Enrico Zini Fri, 29 Oct 2010 12:55:13 +0200 It looks like a new upstream version but it only contains that fix. I am one of the upstreams :) unblock fuss-launcher/0.5-1 -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101029112639.13559.68708.report...@localhost
Bug#602605: unblock: apt-xapian-index/0.41
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Please unblock package apt-xapian-index. It fixes all severe bugs found
after my talk at the MiniDebconf:
apt-xapian-index (0.41) unstable; urgency=low
* Fixed typo in dbus config
* Fixed DeprecationWarning in set_sort_by_value. Closes: #601880.
* Reset cached sort value if --sort is not provided for search.
Closes: #601881.
-- Enrico Zini Sat, 06 Nov 2010 11:25:07 +
A mini feature crept in as part of the fix to #601880, I hope you don't
mind. The deprecation warning required the 2-parameters form of
set_sort_by_value to be used; however, since we were missing reverse
sort (without which sorting by some parameters like package size of age
would be useless), I added the missing parameter with its proper
purpose.
The relevant commit is this:
commit 6d3d2d4ae74d802b3ac1b859c33924feddc492f8
Author: Enrico Zini
Date: Sat Oct 30 15:29:55 2010 +0200
Allow to reverse sort order
diff --git a/axi-cache b/axi-cache
index 69eee8a..531e3a9 100755
--- a/axi-cache
+++ b/axi-cache
@@ -249,8 +249,11 @@ if not helponly:
# TODO: didn't this use to work?
#self.enquire.set_cutoff(int(self.get_cache_last("cutoff",
60)))
+reverse = sort[0] == '-' or sort[-1] == '-'
+sort = sort.strip('-')
+
# Sort by the requested value
-self.enquire.set_sort_by_value(values[sort])
+self.enquire.set_sort_by_value(values[sort], reverse)
def get_matches(self, first=None, count=20):
if first is None:
@@ -329,7 +332,7 @@ class Cmdline(object):
self.parser = Parser(self, usage="usage: %prog [options] command
[args]",
version="%prog "+ VERSION,
description="Query the Apt Xapian index.ENDDESC")
-self.parser.add_option("-s", "--sort", help="sort by the given
value, as listed in %s" % axi.XAPIANDBVALUES)
+self.parser.add_option("-s", "--sort", help="sort by the given
value, as listed in %s. Add a '-' to reverse sort order" % axi.XAPIANDBVALUES)
self.parser.add_option("--tags", action="store_true", help="show
matching tags, rather than packages")
self.parser.add_option("--tabcomplete", action="store",
metavar="TYPE", help="suggest words for tab completion of the current command
line (type is 'plain' or 'partial')")
self.parser.add_option("--last", action="store_true", help="use
'show --last' to limit tab completion to only the packages from the last search
results")
unblock apt-xapian-index/0.41
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101106122521.18540.84578.report...@localhost
Bug#602652: unblock: debtags/1.7.11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: freeze-exception
Please unblock package debtags
It fixes bug #602634.
The debdiff is somewhat polluted by autotools updates. The important bit
is this one:
diff --git a/configure.ac b/configure.ac
index d6a1c0a..fd717ca 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
dnl Process this file with autoconf to produce a configure script.
-AC_INIT(debtags, 1.7.10, [enr...@debian.org])
+AC_INIT(debtags, 1.7.11, [enr...@debian.org])
AC_CONFIG_SRCDIR([configure.ac])
AM_CONFIG_HEADER(config.h)
AM_INIT_AUTOMAKE([foreign])
diff --git a/debian/changelog b/debian/changelog
index 05cec5b..6759936 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+debtags (1.7.11) unstable; urgency=low
+
+ * Update /var/lib/debtags/package-tags. Closes: #602634.
+
+ -- Enrico Zini Sat, 06 Nov 2010 19:33:06 +
+
debtags (1.7.10) unstable; urgency=low
* Build with new libept. Closes: #588546
diff --git a/tools/debtags.cc b/tools/debtags.cc
index 4ec2ea0..27a7de9 100644
--- a/tools/debtags.cc
+++ b/tools/debtags.cc
@@ -544,6 +544,68 @@ public:
}
};
+struct AtomicStdioWriter
+{
+ std::string fname;
+ char* tmpfname;
+ int fd;
+ FILE* out;
+
+ AtomicStdioWriter(const std::string& fname)
+ : fname(fname), tmpfname(0), out(0), fd(-1)
+ {
+ // Build the temp file template
+ tmpfname = new char[fname.size() + 8];
+ strncpy(tmpfname, fname.c_str(), fname.size());
+ strncpy(tmpfname + fname.size(), ".XX", 8);
+ // Create and open the temporary file
+ fd = mkstemp(tmpfname);
+ if (fd < 0)
+ throw wibble::exception::File(tmpfname, "opening file");
+
+ // Pass the file descriptor to stdio
+ out = fdopen(fd, "wt");
+ if (!out)
+ throw wibble::exception::File(tmpfname, "fdopening
file");
+ }
+
+ ~AtomicStdioWriter()
+ {
+ if (out)
+ {
+ if (unlink(tmpfname) == -1)
+ throw wibble::exception::File(tmpfname, "cannot
delete temporary file");
+ fclose(out);
+ }
+ if (tmpfname) delete[] tmpfname;
+ }
+
+ void flush()
+ {
+ // Read the current umask
+ mode_t cur_umask = umask(0);
+ umask(cur_umask);
+
+ // Give the file the right permissions
+ if (fchmod(fd, 0666 & ~cur_umask) < 0)
+ throw wibble::exception::File(tmpfname, "setting file
permissions");
+
+ // Flush stdio's buffers
+ fflush(out);
+
+ // Flush OS buffers
+ fdatasync(fd);
+
+ // Close the file
+ fclose(out);
+ out = NULL;
+
+ // Rename the successfully written file to its final name
+ if (rename(tmpfname, fname.c_str()) == -1)
+ throw wibble::exception::System(string("renaming ") +
tmpfname + " to " + fname);
+ }
+};
+
int main(int argc, const char* argv[])
{
wibble::commandline::DebtagsOptions opts;
@@ -1172,6 +1234,13 @@ int main(int argc, const char* argv[])
// Write out the merged, updated vocabulary
voc.write();
+
+ // Read and merge all tag sources, and write them out
+ {
+ AtomicStdioWriter
writer(debtags::Path::tagdb());
+
env().debtags().output(textformat::StdioWriter(writer.out));
+ writer.flush();
+ }
}
else if (opts.foundCommand() == opts.vocfilter)
{
Code for AtomicStdioWriter comes from ept/debtags/vocabulary.cc in
libept, which is used to atomically write /var/lib/debtags/vocabulary
unblock debtags/1.7.11
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101106221252.15887.8955.report...@localhost
Re: binNMUs for tagcoll, debtags and libapt-front
On Mon, Mar 20, 2006 at 01:42:29AM +0200, Guillem Jover wrote: > Please do bin-NMUs for tagcoll, debtags and libapt-front on i386. > They are linked against gcc 4.1. > Enrico, please clean up your build environment. =) Superfantastically weird: I thought I deinstalled gcc 4.1 before building the packages. Maybe I have some stray library hanging around... Thanks for taking care of this. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: binNMUs for tagcoll, debtags and libapt-front
On Tue, Mar 21, 2006 at 09:44:09PM +0100, Andreas Barth wrote: > > Superfantastically weird: I thought I deinstalled gcc 4.1 before > > building the packages. Maybe I have some stray library hanging > > around... > That's why one should use pbuilder or so. I'd like to. And I get told every time trouble happens. And every time I answer that: - I have a chain of 3 dependecies (libtagcoll -> libapt-front -> debtags) that would require me to rebuild the mirror for pbuilder every time I compile one of them, and I still haven't figured out how to do it automatically. - Maintaining my packages is a big headache already and having to maintain a complex build environment won't help. - I've asked for comaintainers but noone able to do the job has offered help. Well, one has, but every time I asked him something he told me he's busy, so I gave up asking him. - I don't have a local mirror. - I often compile my packages on an airplane. - I'd like to setup a pbuilder + piuparts upload queue on my server at home, but it's an amd64 and I can't upload packages built there yet. And then I wouldn't know how to sign stuff since I don't have the key on that server. And I can't put my key on that server since it's constantly exposed to the internet and I run services on it. This said, I'll welcome anyone who'd sit down with me at the next AnyConf and help me setup a suitable pbuilder environment that: - I can use offline on my laptop. - Allows me to prepare an upload on battery power. - Doesn't require me more effort to maintain the building environment than to maintain my Debian packages. Until that happens, I'll build my packages on the best that my system is able to do. If it'll screw up, I'll try to fix it. If that is not acceptable, either someone offers to comaintain and builds and uploads the packages properly, or I'll be happy to orphan my packages and do the happy upstream. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
debtags-edit
Hello, Hello. I checked the status of my packages at freeze time and I'm happy with all except one: http://qa.debian.org/developer.php?excuse=debtags-edit I wrote to [EMAIL PROTECTED] on december 5 but I got no reply. That release fixes a nasty tag submission bug (the same as #400994). Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
New cnf upload
Hello, I'm the maintainer of the libcnf-dev package which is built as a normal .a file. The upstream build system does not know how to generate shilbs. that package is mainly used to create C libraries that are linked from fortran, and they are usually shlibs. dballe builds one such shlib in libdballef2. Now, working on a development branch of dballe on a 64bit machine I found out that dballe cannot link with cnf because cnf isn't built with -fPIC. The dballe currently in testing gets away with it because I forgot to link the fortran library with -lcnf, but applications needing that fortran library would need to add -lcnf. I've uploaded a new cnf to unstable that builds a .a library with -fPIC code. It's a very simple packaging change that just adds -fPIC to the CFLAGS. I'd be grateful if you could have a look and allow the new version (source package cnf 4.0-2, binary package libcnf-dev 4.0-2) into etch. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Re: New cnf upload
On Wed, Dec 20, 2006 at 04:10:06PM +0100, Andreas Barth wrote:
> * Enrico Zini ([EMAIL PROTECTED]) [061220 10:15]:
> > I've uploaded a new cnf to unstable that builds a .a library with -fPIC
> > code. It's a very simple packaging change that just adds -fPIC to the
> > CFLAGS.
> Your change looks different to what you describe. Can you please
> recheck? (Still approved, because the change looks good as it is to me.)
What do you mean different? Running debdiff, the only significant
change is this:
- $(MAKE) -C cnf build TAR_IN='tar -cvhf' TAR_OUT='tar -xf' CC=$(CC)
FC=$(FC)
+ $(MAKE) -C cnf build TAR_IN='tar -cvhf' TAR_OUT='tar -xf' CC=$(CC)
FC=$(FC) CFLAGS+=-fPIC
Here's the output here:
$ debdiff cnf_4.0-1_i386.changes cnf_4.0-2_i386.changes
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Version: [-4.0-1-] {+4.0-2+}
Installed-Size: [-1724-] {+1728+}
[EMAIL PROTECTED]:~/dev/deb/_uploaded/cnf$ debdiff cnf_4.0-1.dsc cnf_4.0-2.dsc
diff -u cnf-4.0/debian/changelog cnf-4.0/debian/changelog
--- cnf-4.0/debian/changelog
+++ cnf-4.0/debian/changelog
@@ -1,3 +1,9 @@
+cnf (4.0-2) unstable; urgency=medium
+
+ * Build with -fPIC to allow linking in shared libraries.
+
+ -- Enrico Zini <[EMAIL PROTECTED]> Wed, 20 Dec 2006 15:22:49 +0800
+
cnf (4.0-1) unstable; urgency=low
* Initial Release. Closes: bug#389773.
only in patch2:
unchanged:
--- cnf-4.0.orig/Makefile
+++ cnf-4.0/Makefile
@@ -13,7 +13,7 @@
rm -rf cnf
mkdir cnf
tar -C cnf -zxf cnf.tar.Z
- $(MAKE) -C cnf build TAR_IN='tar -cvhf' TAR_OUT='tar -xf' CC=$(CC)
FC=$(FC)
+ $(MAKE) -C cnf build TAR_IN='tar -cvhf' TAR_OUT='tar -xf' CC=$(CC)
FC=$(FC) CFLAGS+=-fPIC
touch build-stamp
install-stamp: build-stamp
Ciao,
Enrico
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
Removal of dballe
Hello. Today I tested dballe on my new laptop and I found out that on 64bit systems its database module just won't work. The next upstream version, which will be fixed, is a major one, and among other things it has changed API. Therefore, I think the best thing to do is to remove it from etch and just keep it in unstable. Packages involved are dballe, libdballe-dev, libdballe2, libdballef2. There are no other packages that depend on it. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
grib_api 1.9.16 uploaded to unstable
Hello, I have just uploaded the new version 1.9.16 of grib_api to sid. The new shlib package is libgrib-api-1.9.16 which should eventually replace libgrib-api-1.9.9. Since upstream has chosen to embed the full package version in the shlib name via "libtool -release", this means that all reverse dependencies of grib_api need to be recompiled with the new version to update their dependencies[1]. The grib_api API is stable enough, so a binary NMU of all reverse dependencies should do. Can it be scheduled whenever you feel like it's a good time? [background info for grib_api users: as of 22 Mar 2012, ECMWF has released version 1.9.16 of grib_api, and since 18 April 2012 at 11:30 UTC, 1.9.16 will be the default version on all ECMWF systems] Ciao, Enrico [1] in case you Debian Ruby Extras Maintainers are wondering what I am talking about: ruby-grib is the package in question -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Bug#673800: transition: grib-api
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition (please explain about the transition: impacted packages, reason, ...) Dear Release team, some time ago I have uploaded version 1.9.16 of grib_api to sid. Since upstream has chosen to embed the full package version in the shlib name via "libtool -release", this means that all reverse dependencies of grib_api need to be recompiled with the new version to update their dependencies. The new shlib package is libgrib-api-1.9.16, which should eventually replace libgrib-api-1.9.9. Unfortunately I didn't realise I had to arrange a transition before uploading the package. That is my fault, sorry. Reverse dependencies according to dak rm -R -n grib-api (arch lists removed): cdo: libcdi0 gnudatalanguage: gnudatalanguage magics++: libmagplus3 pygrib: python-grib ruby-grib: ruby-grib # Broken Build-Depends: cdo: libgrib-api-dev emoslib: libgrib-api-dev (>= 1.9.9~) gnudatalanguage: libgrib-api-dev magics++: libgrib-api-dev pygrib: libgrib-api-dev ruby-grib: libgrib-api-dev libgrib-api-tools The grib_api API is stable enough, so a binary NMU of all reverse dependencies should do. Ben file (as far as I can understand how it works, untested): is_affected = .depends ~ /libgrib-api-1.9.9|libgrib-api-1.9.16/ is_good = .depends ~ /libgrib-api-1.9.16/ is_bad = .depends ~ /libgrib-api-1.9.9/ Thank you, Enrico -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120521140739.16954.42979.report...@viaza.enricozini.org
Bug#718417: transition: grib-api
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I have packaged the new version of grib-api and I'm ready to upload it. Upstream still doesn't want to worry about ABI compatibility and still embeds the full package version in the soname, so a transition is needed. The API has not changed, so only action needed for reverse dependencies is a binary NMU. Let me know when I can upload it. Ben file: title = "grib-api"; is_affected = .depends ~ "libgrib-api-1.9.16" | .build-depends ~ "libgrib-api-dev"; is_good = .depends ~ "libgrib-api-1.10.4"; is_bad = .depends ~ "libgrib-api-1.9.16"; Thank you, Enrico -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130731121809.11626.69882.report...@viaza.enricozini.org
Bug#718417: transition: grib-api
On Sun, Aug 11, 2013 at 02:16:01PM +0200, Niels Thykier wrote: > I have setup a tracker for it at [1]. Can you please confirm that the > tracker contains all the packages you expected. Looks good as far as I understand it. I'm Cc-ing Alastair just in case. > Will emoslib need a binNMU too or is it (build-)dependency unaffected by > the ABI change? It will need a binNMU as well. I may be missing some point, though, because I do not understand how come you singled out that package in particular. Can I go ahead and upload the new grib_api? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
Bug#718417: transition: grib-api
Control: tags -1 confirmed On Sun, Aug 11, 2013 at 02:54:03PM +0200, Niels Thykier wrote: > I singled it out because it does not have a dependency on libgrib-api-X > (but it appears to Build-Depend on libgrib-api-dev). We just had a look in person, it looks like it's used to build some experimental bit that isn't actually packaged. However, it may still make sense to binNMU it in case the new grib_api causes issues during the build. > Once the list is confirmed, I think we are ready. Confirmed. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini signature.asc Description: Digital signature
