Re: Bug#986565: unusable with current git
Hi, >> On Wed, 21 Apr 2021 10:12:03 + Damyan Ivanov wrote: >>> Sigh. Now git reverted to using /usr/lib again, and git-flow is broken. Why sigh? Directories such as /usr/lib/git-core and /usr/libexec/git-core are internal to git. Other packages should not install to either directory. This is not a new thing: the standard way to contribute new git subcommands has been to install them to $PATH from the start. Version 2.31.0-1 of Debian's Git package changed an internal directory from /usr/lib/git-core to /usr/libexec/git-core. That caused problems for people, so 2.31.1-1 reverted the change. See https://bugs.debian.org/985416 for more details, including these should install to /usr/bin/ instead. The exact location where git stores its commands is an implementation detail that packages are not meant to rely on. If I had known about these callers, then I would have filed some preparatory bugs instead of making that change in 2.31.0-1. The change was in experimental for a long time before then, so one way to prevent future such issues is to test against git from experimental. If git-flow wants to depend on Git internals, contacting the git package maintainers is appreciated. That is especially true when the internal details you're depending on are changing. Thanks and hope that helps, Jonathan
Re: Proposal: Repository for fast-paced package backports
Dominik George wrote:
> Jonathan Nieder wrote:
>> 2. I am happy with the current charter of backports and I think it's
>> possible to move forward with fastpaced without having to change
>> that charter.
>
> Yep. That's exactly why the proposal changes nothing about -backports. I
> am still confused why Alex and you keep insisting that anything would be
> changing there.
It has a few points of intersection:
- Should the package begin to migrate to testing again, it must
be moved to stable-backports.
- Using the same ~bpo version namespace
- "treat it as part of backports", which I assume means that
backports users would automatically consume this repo
- new binary uploads to volatile have to undergo the
same NEW queue as backports
I don't think these are deep, inherent things (it's possible to
preserve the spirit of the proposal while removing them), but please
don't accuse me of pulling them out of thin air.
[...]
>> 3. formerer is speaking from experience when he says that it's
>> possible to make this kind of change unofficially first, learn
>> from it, and thus set the groundwork for making it official.
>>
>> If you foresee obstacles to that, can you say more about where
>> they lie? Maybe we can help address them, or maybe we can find
>> another way forward.
>>
>> If you don't see obstacles, why not start today?
>
> I think I already made those obstacles clear: Starting outside means
> buying, installing and operating at least a server vor
> volatile.debian.net (or whatever you call it), setting up and
> maintaining an upload queue, the queued, and everything around it,
> building from source for at least the most important architectures on
> hardware that needs to be there and maintained for that, etc.
Thanks. That points to who you may want to get help from:
- DSA, for hosting
- ftpmasters, in case you'd share their DAK instance
- porters, to find out what level of port + buildd support they want
to maintain
[...]
> - I do not sure I can do it right, because I do not know all the
>technical details.
That's fine. There's no time like the present to learn!
> Thus, because the change as it is proposed has such a low impact on
> anything else, I consider doing all that over again unnecessary.
>
> Don't get me wrong - I would not hesitate to go through it if it were
> for anything that could break things, or make life harder for others, or
> something like that.
I think you're underestimating the impact on other teams. That's
fine: it's probably worth it, but you will need to get buy in.
[...]
> If you know how to start with a new service at
> {volatile,fastpaced,whatever}.debian.net without having to reinvent the
> wheel for acceptign uploads, getting packages built, etc., please
> enlighten me.
backports maintainers, debian-ports maintainers, and others may have
experience with this. I don't know the best place to get advice from
them --- you may already be in the right place. :)
Sincerely,
Jonathan
Re: Proposal: Repository for fast-paced package backports
Hi, Pirate Praveen wrote: > I agree with you, it is the best outcome. But when people with power > (-backports ftp masters) are not willing to consider it, we have to > go with plan B, which is less than ideal, but can move things > forward. Just to avoid this being thought of as an idiosyncrasy of backports ftpmasters, I suppose I should put my own views forward. 1. Nik, I think you're onto something with this fastpaced proposal. I would be happy to see some suite to make it easier for users to consume packages that lack long-term support, like non-ESR firefox. 2. I am happy with the current charter of backports and I think it's possible to move forward with fastpaced without having to change that charter. 3. formerer is speaking from experience when he says that it's possible to make this kind of change unofficially first, learn from it, and thus set the groundwork for making it official. If you foresee obstacles to that, can you say more about where they lie? Maybe we can help address them, or maybe we can find another way forward. If you don't see obstacles, why not start today? 4. Just to reiterate about (2), just like I think it's completely reasonable for release team to exercise discretion about what goes in stable and testing, it's completely reasonable for backports team to exercise discretion about what goes into backports. Please don't take it personally. It's an important part of what they do to make the suite sustainable, and I am very grateful for it. Thanks and hope that helps, Jonathan
Re: please add a chromium-source binary package
Hi, Emilio Pozuelo Monfort wrote: Michael Gilbert wrote: > Major updates to chromium in stable have so far been contingent on it > being a leaf package, where there is no chance for it to break > anything else. Adding CEF as a reverse dependency would change that. ^^ > On 15/10/2018 19:19, Steinar H. Gunderson wrote: >> On Mon, Jul 02, 2018 at 12:29:15PM +0200, Steinar H. Gunderson wrote: >>> Release team, for the short recap: Would it be acceptable to have chromium >>> provide a chromium-source binary package, and then package CEF (Chromium >>> Embedded Framework) Build-Depending on that package, and then have other >>> packages depend on CEF? CEF aims to provide a stable API/ABI on top of >>> Chromium for other software to use, but needs updating whenever Chromium >>> releases a new major version. See #893448 for some more details. >> >> Ping :-) Release team, do you want to weigh in? If nothing else, perhaps we >> could add a CEF package in unstable only (ie., with a testing blocker bug) >> for the time being. >> >> FWIW, I've updated my CEF packages to CEF/Chromium 69; all that was required >> was >> to patch out installation of Swiftshader (since Debian's packages now >> disable it). > > I'm not sure we (RT) need to make any decision here. > > Adding a chromium-src for other packages to build against is not special in > any > way, we don't approve this for other packages. However, you do have some say in whether a package is able to have non-trivial updates in stable. Can we infer from your reply that you're still okay with this for Chromium even if CEF relies on it, provided security team is okay with it? > As for the security support concerns, that's up to the security team. Therefore cc-ing security team. Thanks, Jonathan
Re: Workflow for handling security issues in testing
Hi Niels, Niels Thykier wrote: > Jonathan Nieder: >> With severity=high, a security fix then takes two more days before it >> hits testing. Is there a way to expedite it? My experience with >> https://bugs.debian.org/871823 was "no". [...] > The 2 days are measured from the first time the package has been made > available by dak. And then there are some corner cases in how we handle > "aging" that may slightly complicates how "2 days" are defined here. > > It is *technically possible* to expedite an upload to migrate faster > than "2 days" (including omitting the delay entirely). However, at the > moment a signifiant part of our QA relies on the delay to catch > (obvious) mistakes. As such, we generally reserve such exemptions to > the aging for "very urgent" issues[1]. Thanks. That helps. Git appears to have been blocked today by https://alioth-lists.debian.net/pipermail/piuparts-devel/2018-May/007797.html. Would an "urgent" hint have prevented that? I would like to see the update in unstable to protect users. For example, see [2]. I don't think most users of testing realize that they also need to include stable-backports in sources.list to get security fixes. That said, by the time you read this message it's likely that it will have auto-migrated. :) > I am hoping we will eventually get to a point where the automated QA > tests provided to the testing migration decision can replace the > arbitrary delay we currently use to enable manual testing. Though I > doubt we are ready to do that any time soon. For next time, if I have done sufficient testing (manual piuparts run, having internal users use it in daily life, etc) privately during the embargo period, should I file a bug against the release.debian.org to make an "urgent" hint when the embargo expires? Thanks, Jonathan > [1] Deployed as an "urgent"-hint in britney: > > https://release.debian.org/doc/britney/hints.html#urgent-action-list [2] https://blog.npmjs.org/post/174411769410/how-npm-is-affected-by-the-recently-disclosed-git.
Workflow for handling security issues in testing
Hi, https://security-tracker.debian.org/tracker/CVE-2018-11235 (https://public-inbox.org/git/xmqqy3g2flb6@gitster-ct.c.googlers.com/) reminded me that I don't fully understand the process for handling embargoed security issues in sid and testing. When preparing updates for an embargoed issue in stable (https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#bug-security), the packager uploads to security-master and auto-builders are able to build for supported platforms before the embargo expires. Once the embargo expires, the package is released and available quickly for users to upgrade. After preparing updates for an embargoed issue in sid, the packager uploads to ftp-master once the embargo expires. There is an additional delay for auto-builders to build the package before the binary package is available, unless the packager prepares binary packages locally in advance and uploads them as well. Is that the recommended practice? With severity=high, a security fix then takes two more days before it hits testing. Is there a way to expedite it? My experience with https://bugs.debian.org/871823 was "no". Is my understanding correct? Any other points? Thanks, Jonathan
Bug#871823: unblock: git/1:2.14.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package git. This update fixes CVE-2017-1000117 (arbitrary code execution issues via URLs, https://public-inbox.org/git/xmqqh8xf482j@gitster.mtv.corp.google.com/T/#u). The issue was covered with DSA-3934-1 in jessie and stretch. Please allow the fix to go quickly to buster. Thanks, Jonathan
Bug#862525: unblock: git/1:2.11.0-3
Salvatore Bonaccorso wrote: > Please unblock package git > > The update fixes CVE-2017-8386, which does not have a bug in the BTS. > The issue was covered with DSA-3848-1 in jessie, so please allow the > fix to go to stretch to avoid a regression. Sorry I didn't request it before, and thanks much for taking care of it. Sincerely, Jonathan
Bug#735509: transition: leptonlib
Hi, Jonathan Nieder wrote: Jeff Breidenbach wrote: Leptonica upstream is releasing a new version that will have an increased soname (liblept3 - liblept4). No exotic challenges expected. This is a tiny transition: the only source package that will need rebuilding is tesseract. $ grep-dctrl -FBuild-Depends libleptonica-dev -sPackage * Package: tesseract Based on a quick test, tesseract builds and runs ok against leptonlib from experimental. 'ben' parameters: Affected: .build-depends ~ /libleptonica-dev/ Good: .depends ~ /liblept4/ Bad: .depends ~ /liblept3/ It should presumably wait for the libwebp transition due to the overlap. ... and the libwebp transition is now done. Ok to go ahead and upload leptonlib to unstable? Thanks, Jonathan -- 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/20140203182901.gc30...@google.com
Bug#735509: transition: leptonlib
block 735509 by 731168 quit Hi, Jeff Breidenbach wrote: Leptonica upstream is releasing a new version that will have an increased soname (liblept3 - liblept4). No exotic challenges expected. This is a tiny transition: the only source package that will need rebuilding is tesseract. $ grep-dctrl -FBuild-Depends libleptonica-dev -sPackage * Package: tesseract Based on a quick test, tesseract builds and runs ok against leptonlib from experimental. 'ben' parameters: Affected: .build-depends ~ /libleptonica-dev/ Good: .depends ~ /liblept4/ Bad: .depends ~ /liblept3/ It should presumably wait for the libwebp transition due to the overlap. -- 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/20140127000839.gb9...@google.com
Re: Bug#709947: closed by ty...@mit.edu (Theodore Y. Ts'o) (Bug#708307: fixed in e2fsprogs 1.42.8-1)
Hi, Theodore Ts'o wrote: We have a minor problem with uploading a fix. E2fsprogs currently FTBFS on stable, due to bug #707996, whose root cause is #708061. Personally, I blame glibc (#708061) for once again making a library-visible API change. (If they didn't want programs to use __secure_getenv, they shouldn't have made it visible.) Odd --- wouldn't building e2fsprogs in a wheezy chroot avoid trouble, since libc in wheezy doesn't have that bug? Thanks, Jonathan -- 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/20130812074835.GA7762@elie.Belkin
Bug#678624: pu: package xz-utils/5.0.0-3
Adam D. Barratt wrote: [it's generally considered polite to note when you're adding CCs...] Sorry about that. Will do so next time. [...] Please go ahead with the upload. Now that I look back over it, I would like to drop some changes --- the upload was originally intended for stable, and parts of the upload are less important for oldstable: - static library breakage fix (#673001) - liblzma-dev/doc/examples/ fix - Czech translation typofix (#605762) - Italian translation typofix Fixes to the following would still be included in the update: - invalid output for invalid checksum type - invalid output from python-lzma compressing a zero-length file - incorrect handling of such invalid streams by unxz - wrong buffer refill handling leading to spurious LZMA_BUF_ERROR (Compressed data is corrupt or Unexpected end of input) - NULL pointer dereference on malloc failure - buffer overflow from -v -v --list with malformed input - xzegrep and xzfgrep = xzgrep - loss of exit status from xzdiff foo.xz bar.xz (#635501) - bad SIGPIPE handling in xzgrep Would that be ok? [...] Updates to oldstable and larger updates both tend to suffer due to taking longer to deal with (in the latter case) and generally being less urgent (in the former, due to the gap between point releases). I'm not sure that throwing more people at the problem will necessarily solve either of those in a useful way in the long term. Sure, I agree that taking on new helpers takes time and blindly throwing people at a problem is rarely helpful. And probably, getting the stable update process to scale better would involve changing the process a little (e.g., clearer guidelines for how long a response should take so following up is easier; uploading changes that have not been fully vetted to an archive area where people can help by testing; etc). But the current process is only barely working, no? The number of packages in Debian is still growing, so I'm worried. Thanks, Jonathan -- 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/20130707181442.gc9...@google.com
Bug#678624: pu: package xz-utils/5.0.0-3
In March, Adam D. Barratt wrote: On Sat, 2013-03-16 at 14:40 -0700, Jonathan Nieder wrote: * What this most needs is more testing. I know you have tested it, but I haven't had time to test it myself. I should have some in the next month and do not think this should roll out to s-p-u until then. I'm currently tending towards this, fwiw. As I mentioned on IRC, I've added getting some testing done to my to-do list; the past few days have just been a little... occupied. Ping. I am personally confident about this update being safe and about being capable of dealing with any unforseen problems with it quickly. I am the Debian maintainer of xz-utils (though I'd welcome comaintainers), so that confidence should count for something. I might be missing something, but it looks to me like something is going wrong in the pu/spu process when this kind of request gets stalled in an unactionable way for more than a year. That's not meant to take away from the other good work the team does, but maybe a call for help on debian-devel-announce@ or some other kind of recruiting effort would be warranted? Thanks, Jonathan -- 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/20130707020728.gb4...@google.com
Re: Temporary solution for changelog problem in binNMUs
Hi, Ian Jackson wrote: The real problem is that these changelog files are primarily intended for human beings. They should live in /usr/share/doc, and their location should be transparent. I was convinced of this until I remembered that package descriptions are very similar in this respect. My gut feeling to expect to find changelogs in /usr/share/doc/package is actually mostly due to habit, I suspect. That doesn't mean it makes sense to ignore that habit, though. If we go down this path that dpkg might need to install a symlink under /usr/share/doc to help people get used to the file's new location. dpkg-query --status should give a hint about how to show the changelog, too. The right answer is the IMO the splitting as proposed by Ansgar. One problem that that doesn't solve is what to do when a package would be able to borrow its /doc/package directory from another package (using a symlink) but for the changelog and copyright (which gets even harder when binnmus are involved). See http://bugs.debian.org/556015 Thanks, Jonathan -- 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/20130513201451.gd3...@google.com
Bug#678624: pu: package xz-utils/5.0.0-3
Adam D. Barratt wrote: On Sat, 2013-03-16 at 14:40 -0700, Jonathan Nieder wrote: * What this most needs is more testing. I know you have tested it, but I haven't had time to test it myself. I should have some in the next month and do not think this should roll out to s-p-u until then. I'm currently tending towards this, fwiw. As I mentioned on IRC, I've added getting some testing done to my to-do list; the past few days have just been a little... occupied. Thanks for the update. Jonathan -- 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/20130323052044.GA4428@elie.Belkin
Bug#678624: pu: package xz-utils/5.0.0-3
Hi again, In June, Jonathan Nieder wrote: debian/changelog | 50 + debian/rules | 4 +- debian/source/include-binaries | 2 + debian/symbols | 8 +-- tests/files/bad-1-block_header-6.xz| Bin 0 - 72 bytes tests/files/good-1-lzma2-5.xz | Bin 0 - 52 bytes debian/patches/bcj-flush-to-empty-buffer | 190 + debian/patches/cs-sparse-file | 43 +++ debian/patches/decode-empty-blocks | 41 +++ debian/patches/decode-empty-blocks-test| 28 + debian/patches/encoder-api-checks | 91 ++ debian/patches/encoder-skip-empty-blocks | 61 + debian/patches/index_init-NULL-dereference | 32 + debian/patches/it-stray-N | 48 debian/patches/series | 14 +++ debian/patches/stream_encoder-init-leak| 34 ++ debian/patches/xz-lvv-invalid-free | 60 + debian/patches/xz-lvv-invalid-free-test| 30 + debian/patches/xzdiff-save-diff-status | 123 +++ debian/patches/xzgrep-argv0-parsing| 36 ++ debian/patches/xzgrep-ignore-SIGPIPE | 36 ++ Gentle ping. I would be happy with many kinds of reply other than an ack, for example: * What this most needs is more testing. I know you have tested it, but I haven't had time to test it myself. I should have some in the next month and do not think this should roll out to s-p-u until then. Or: * I have reviewed patches cs-sparse-file and it-stray-N and started to review xz-lvv-invalid-free but didn't finish. The description above the '---' was confusing; maybe a clearer summary would make it easier. Or: * That's way too many patches. Please pick 5, test again, and re-upload, and we can try to get the rest in later. Or: * I don't think squeeze is worth supporting any more except for security issues, given that wheezy is being released so soon. Do any of the above patches have security impact? Or, really, anything but silence. Basically I selfishly want a feeling of progress. Also if there is anything I can do to help with stable maintenance (e.g., patches to review), please don't hesitate to let me know. That goes always, not just when I want something from the SRMs. ;-) Thanks, Jonathan -- 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/20130316214007.GA5105@elie.Belkin
Bug#664793: pu: package libcap2/1:2.19-3
retitle 664793 pu: package libcap2/1:2.19-3+squeeze1 quit Hi Torsten, In May, Torsten Werner wrote: --- libcap2-2.19/debian/changelog 2010-08-16 23:16:35.0 +0200 +++ libcap2-2.19/debian/changelog 2012-03-20 22:22:39.0 +0100 @@ -1,3 +1,9 @@ +libcap2 (1:2.19-3+squeeze1) stable; urgency=low + + * Security: chdir after chroot in capsh tool. (CVE-2011-4099) + + -- Torsten Werner twer...@debian.org Tue, 20 Mar 2012 13:24:23 +0100 Any news on this? Would you still like to upload it? Thanks, Jonathan -- 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/20130310025737.GA6679@elie.Belkin
Re: connman: Connman won't run due to missing libxtables.so.7
reassign 691180 iptables 1.4.14-3 affects 691180 + connman quit Hi Julien, Julien Cristau wrote: On Thu, Jan 24, 2013 at 01:22:21 -0800, Jonathan Nieder wrote: In wheezy, there is instead an unversioned dependency on iptables, which is not enough to ensure the correct shared library is present: [...] NAK. iptables in sid needs to add Breaks on the packages in wheezy that want libxtables.so.7. And 691180 should be reassigned to iptables. Huh? Changing iptables in sid would fix squeeze-to-wheezy upgrades how, exactly? To recap, iptables in squeeze and wheezy contain a shared library (libxtables) used by other packages. The version in squeeze is /lib/libxtables.so.4 The version in wheezy is /lib/libxtables.so.7 This produces upgrade problems. -- 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/20130126150416.GA17186@elie.Belkin
Re: connman: Connman won't run due to missing libxtables.so.7
Julien Cristau wrote:
On Sat, Jan 26, 2013 at 07:04:16 -0800, Jonathan Nieder wrote:
Julien Cristau wrote:
NAK. iptables in sid needs to add Breaks on the packages in wheezy that
want libxtables.so.7. And 691180 should be reassigned to iptables.
[...]
To recap, iptables in squeeze and wheezy contain a shared library
(libxtables) used by other packages. The version in squeeze is
/lib/libxtables.so.4
The version in wheezy is
/lib/libxtables.so.7
This produces upgrade problems.
Well then iptables in wheezy should have breaks on the packages in
squeeze that link against libxtables.so.4, too...
What package expression can iptables/sid use to represent packages
using libxtables built against iptables/wheezy? Dependencies like
Breaks: connman ( 1.0-1.2)
become useless as soon as a newer version of connman is in
wheezy-backports.
I don't know what constraint makes introducing a libxtables7 package a
bad thing to do, so I don't know how to avoid it when coming up with
an appropriate fix. One possibility would be to make iptables
'Provides: libxtables7' and to make shlibs create dependencies on
that.
That said, here's a patch adding appropriate Breaks for
squeeze-wheezy upgrades. Luckily not every package with a build-time
dependency on iptables-dev uses libxtables.
diff --git i/debian/changelog w/debian/changelog
index 6e7f55c2..eaf24993 100644
--- i/debian/changelog
+++ w/debian/changelog
@@ -1,3 +1,11 @@
+iptables (1.4.14-3.1) testing; urgency=low
+
+ * Non-maintainer upload.
+ * Add Breaks against iproute and xtables-addons-common versions
+that relied on libxtables4. Closes: #691180
+
+ -- Jonathan Nieder jrnie...@gmail.com Sat, 26 Jan 2013 08:31:40 -0800
+
iptables (1.4.14-3) unstable; urgency=low
* Fixes iptables comment output error reported by Christoph Anton
diff --git i/debian/control w/debian/control
index 1e9d513c..32e26642 100644
--- i/debian/control
+++ w/debian/control
@@ -9,6 +9,7 @@ Homepage: http://www.netfilter.org/
Package: iptables
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: iproute ( 20120521-3), xtables-addons-common ( 1.42-2)
Description: administration tools for packet filtering and NAT
These are the user-space administration tools for the Linux
kernel's netfilter and iptables. netfilter and iptables provide
--
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/20130126163237.GB17186@elie.Belkin
Re: connman: Connman won't run due to missing libxtables.so.7
found 691180 connman/1.0-1.1+wheezy1 fixed 691180 connman/1.0-1.2 quit Hi Adrian, John Paul Adrian Glaubitz wrote: close 691180 thanks Hi, there have been new uploads of connman both into testing and unstable, the issue has been resolved as the package has been rebuilt in both cases. This has been fixed in sid but not in wheezy. :( In sid, the dependency on libxtables9 avoids trouble: $ cupt show connman/sid | egrep 'Version|Depends|Conflicts|Breaks' Version: 1.0-1.2 Depends: libc6 (= 2.9), libdbus-1-3 (= 1.1.1), libglib2.0-0 (= 2.28.0), libgnutls26 (= 2.12.17-0), libxtables9, dbus, lsb-base In wheezy, there is instead an unversioned dependency on iptables, which is not enough to ensure the correct shared library is present: $ cupt show connman/wheezy | egrep 'Version|Depends|Conflicts|Breaks' Version: 1.0-1.1+wheezy1 Depends: iptables, libc6 (= 2.9), libdbus-1-3 (= 1.1.1), libglib2.0-0 (= 2.28.0), libgnutls26 (= 2.12.17-0), dbus, lsb-base Fixing this properly would presumably require an iptables update in testing (either bumping shlibs or, better, backporting the introduction of a separate libxtables9 package from sid) followed by a binnmu. Hope that helps, Jonathan -- 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/20130124092221.GB4045@elie.Belkin
Re: connman: Connman won't run due to missing libxtables.so.7
Adam D. Barratt wrote: On 24.01.2013 09:22, Jonathan Nieder wrote: Fixing this properly would presumably require an iptables update in testing (either bumping shlibs or, better, backporting the introduction of a separate libxtables9 package from sid) followed by a binnmu. Introducing new binary packages via tpu at this stage of a freeze doesn't immediately meet my definition of better, fwiw... Sure. It's better because without a separate package the upgrade path is complicated. With a separate package: install libxtables9 upgrade packages that use libxtables upgrade iptables Without a separate package: deconfigure packages that use libxtables upgrade iptables upgrade packages that use libxtables In other words, having a separate package allows both versions of the library to coexist on the filesystem. Here are the Reverse-build-dependencies of iptables-dev: collectd, connman, iproute, linux-igd, nufw, perlipq, shaperd, west-chamber, xtables-addons. Of those, only connman and xtables-addons declare a dependency on libxtables9. It looks like the transition wasn't finished in sid. :( -- 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/20130124211920.GA24562@elie.Belkin
Bug#692011: taxbird: version in testing (0.16.x) is completely useless
retitle 692011 RM: taxbird/0.16-0.2 user release.debian@packages.debian.org usertags 692011 = rm quit Jonathan Wiltshire wrote: On Sat, Dec 22, 2012 at 08:46:50PM +, Steven Chamberlain wrote: Then aim to make the version in sid, or any later revisions, available through wheezy-backports. That seems analogous to the 'volatile' idea. This would keep the package available to those who want it, yet reflects the fact it doesn't have the same level or duration of support as a typical package in stable. So, what's the progress on this? I'm strongly of the opinion that this is the most appropriate strategy. Agreed, though not as strongly, so marking so. Thanks, Jonathan -- 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/20130120093651.GB16339@elie.Belkin
Bug#683683: unblock: openswan/1:2.6.38-1
René Mayrhofer wrote: I agree with going for the backports option so as not to delay the freeze period any more than necessary. Thus closing. However, the typical issue with openswan will remain in this case: security updates will be more difficult to backport to the version currently in wheezy (just judging from experience). Wheezy is supported by the security team for at least 3 years, so on one hand a slightly newer version doesn't buy much and on the other hand the support burden is hard. If the version currently in testing is unsupportable or there are any smallish patches that would make it easier to support, please don't hesitate to let the release team know. Thanks for your work, Jonathan -- 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/20130120102414.GA18412@elie.Belkin
Bug#685248: unblock boinc/7.0.34+dfsg-2
(resending to BTS with Steffen's permission) Steffen Möller wrote 7.0.27 does the job. [... lots of interesting details snipped ...] Since the package does something good to the world at large, I do not want any such removal again, [...] On http://boinc.berkeley.edu/download.php you see the latest version that upstream suggests to be installed. My pledge would be to go for that version for the next release. That is 7.0.28 ( = Wheezy + 0.0.1) at the moment. The diffstat from 7.0.27 to 7.0.28 is 69 files changed, 442 insertions(+), 238 deletions(-) Excluding boinc-manager, it is 59 files changed, 217 insertions(+), 165 deletions(-) which is approaching a more reviewable size. Extracting the bugfixes still seems simpler, but if all unimportant changes are unrisky it might be possible to sell the release team on just using the updated upstream version. (Disclaimer: I haven't reviewed the diff for myself.) Steffen also wrote: please ask the release team to allow the next upstream-declared suggested version in. Presumably meaning 7.0.4x or 7.1.0. I fear that will be too large of a change. Thanks, Jonathan -- 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/20130121070555.GB3265@elie.Belkin
Bug#685248: unblock boinc/7.0.34+dfsg-2
Hi Steffen, Steffen Möller wrote: I have mentally given up on Wheezy and BOINC. That's unfortunate to hear. What is your advice for the release team? Is the version currently in wheezy appropriate for release, should it be removed, or are there some fixes missing that would make it appropriate? Thanks for your help, Jonathan -- 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/20130119213115.GB4009@elie.Belkin
Bug#696665: unblock: libdrm/2.4.40-1~deb7u1 (pre-approval, hw support)
Julien Cristau wrote: This would go in from sid, not tpu. Oh, sid libdrm matches wheezy. Sorry, I confused myself through the version number. I still think this would be a useful update. :) I've been using libdrm 2.4.40-1 from experimental since it was uploaded, and it works fine here. In addition to the usual hardware support improvments, it includes the fix 2.4.38~10 (intel: Bail gracefully if we encounter an unknown Intel device, 2012-07-25) without which kernel patches adding support for new devices cause X to hang. -- 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/20130102155212.GB30813@elie.Belkin
Bug#685237: unblock: makehuman/1.0.0~alpha6-5
tags 685237 + moreinfo quit Hi, Muammar El Khatib wrote: I'm writing this report for your consideration. makehuman was removed on 2012-06-19 (revision 1.0.0~alpha6-3). Then, I uploaded two new revisions being the last one on 2012-07-11. I've attached the debdiff files that reflect changes from revision -3 in this report. makehuman is 37 days old, now. As for this moment, it only has a report in the BTS (#683920, severity: normal). Since makehuman was not part of squeeze and the release is close, I think it would be simplest to provide it to wheezy users through wheezy-backports. That should make the release happen faster and provide more flexibility for future bugfixes. What do you think? Thanks, Jonathan -- 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/20130103070027.GA32705@elie.Belkin
Bug#685248: unblock boinc/7.0.34+dfsg-2
tags 685248 + moreinfo quit Hi, Guo Yixuan wrote: we still hope to have an update for boinc. Could you describe what such an update would look like (and attach a debdiff)? The current diff between testing and experimental is 242 files changed, 14119 insertions(+), 10822 deletions(-) which seems a little large for this stage in the release cycle. More targetted fixes for serious bugs could be appropriate if they exist. Thanks and hope that helps, Jonathan -- 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/20130103071158.GA32763@elie.Belkin
Bug#683142: unblock: bdii/5.2.5-2+wheezy3
tags 683142 + moreinfo quit Hi Matthias, In November, Ansgar Burchardt wrote: I have accepted bdii/5.2.5-2+wheezy3 from NEW, however there are still some things that maybe should be improved: There is an empty /etc/sysconfig directory. The postinst uses chown on files in non-root-owned directories. I am not sure if including the symlink /var/lib/bdii/gip/ldif/default.ldif - /usr/share/bdii/default.ldif is correct. The above message was to bug#683142, and I'm not sure if you received it. Any news? Is the version of bdii currently in tpu the right one for wheezy, or are there more updates coming? Thanks, Jonathan -- 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/20130103072558.GA637@elie.Belkin
Bug#685663: unblock nordugrid-arc/2.0.0-3
tags 685663 + moreinfo quit Hi Mattias, Mattias Ellert wrote: Since there was an RC bug reported against version 2.0.0-3 (some missing Replaces/Breaks), allowing this version back in to testing again would not be a good idea. I created a 2.0.0-3+wheezy1 version with the same fix that is in 2.0.0-5 and uploaded it to testing-proposed-updates. If I understand correctly then nordugrid-arc was not part of squeeze, so stable users are not relying on it yet. In that case I would suggest considering providing the package for wheezy through wheezy-backports after the release, which should make later fixes easier. What do you think? Thanks, Jonathan -- 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/20130103073125.GA665@elie.Belkin
Bug#696665: unblock: libdrm/2.4.40-1~deb7u1 (pre-approval, hw support)
Hi, Julien Cristau wrote: I'm considering an update to libdrm for wheezy, to get newer hw support on radeon and intel. Upstream changed the libdrm_nouveau API/ABI in the mean time, so this update would revert nouveau to the current state in wheezy (2.4.33-3). FWIW I think this would be a very good update. Release team, would it make sense for X folks to upload it to tpu for now for interested people like me to test? That way, the package could get at least some token testing before migrating to wheezy. Thanks, Jonathan -- 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/20130102073440.GA19704@elie.Belkin
Bug#682906: unblock: python-defaults/2.7.3-2
unblock 682906 by 683053 tags 682906 + moreinfo quit Piotr Ozarowski wrote: [Jonathan Nieder, 2012-12-09] * pyversions, dh_python2, pycompile: allow to override system's list of supported Python versions via DEBPYTHON_SUPPORTED and default Python version via DEBPYTHON_DEFAULT env. variables Do any packages in wheezy use these envvars? What will happen if they are rebuilt against python-defaults from wheezy? packages are not using it yet. Once they do, they should use it for tests only. Wheezy administrators will be able to easily re-add support for Python 2.4 thanks to these envvars (rebuilding one package to add 2.4 symlinks should be much easier and safer with envvar than with changing list of supported versions system-wide) [... and lots of other helpful information ...] Thanks for clarifying. If someone is interested in getting some appropriate subset of these changes well tested for wheezy, I suspect the next step is to prepare an upload for tpu that does not bump the python2.7 requirement. Marking so. Hope that helps, Jonathan -- 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/20130101004908.GA11450@elie.Belkin
Bug#692011: taxbird: version in testing (0.16.x) is completely useless
Toni Mueller wrote: On Wed, Dec 19, 2012 at 07:49:55PM +, Adam D. Barratt wrote: Potentially, yes. tzdata's debdiff tends not to end up as 83 files changed, 13318 insertions(+), 16724 deletions(-) though. :-( ok, so what do you suggest? I reckon that all tax calculating software should have this problem. In theory, table-driven code or at least good modularity can be a way to minimize the damage from changing facts of life on unrelated aspects of a program's functionality. In practice, isn't taxbird dead and therefore unlikely to change at all in the future? I think if we include it in wheezy, we should include the newest packaged version. Thanks, Jonathan -- 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/20121221081814.GA4568@elie.Belkin
Bug#682906: unblock: python-defaults/2.7.3-2
Hi Scott,
First, a disclaimer: I'm not a python expert or a member of the
release team, so please take anything I say with a grain of salt.
This review is mostly meant to help get this unstuck.
Scott Kitterman wrote:
- Match the version number for python and python2.7.3. Although this is
costmetic, it does cause confusion.
This is why the unblock is blocked by #683053, right?
- Matches the feature set in squeeze between dh_python2 and dh_python3. It
would be difficult for backporters, derivatives, and third party vendors to
keep straight which did what with a skewed feature set. This is better
avoided.
The diff is (including changelog and tests)
45 files changed, 466 insertions(+), 205 deletions(-)
including
dh_python2 | 52 +---
As we've seen shebang normalization is not without complications. So
at this stage in the freeze, this wouldn't be the usual candidate for
an unblock.
On the other hand:
(1) The impact is mostly at build time for rbuilddeps, and this
change has been in sid for half a year already. Any damage it
causes has probably already been done. :)
(2) Worse, most packages are built in unstable and only migrate to
testing later, except for tpu, spu, and security uploads. Some
source packages could be relying on the effect of this upload
already and in that case _not_ migrating would just make trouble
for stable maintenance and security updates.
(3) On the bright side, it's had half a year of testing.
So I am (reluctantly) in favor of including most of these changes
in wheezy, at least in principle.
On to the diff.
[...]
--- python-defaults-2.7.3~rc2/debian/control 2012-06-05 22:59:07.0
-0400
+++ python-defaults-2.7.3/debian/control 2012-07-26 18:26:10.0
-0400
@@ -13,7 +13,7 @@
Package: python
Architecture: all
Priority: standard
-Depends: ${misc:Depends}, python2.7 (= 2.7.3~rc2-1~), python-minimal (=
${binary:Version})
+Depends: ${misc:Depends}, python2.7 (= 2.7.3-1~), python-minimal (=
${binary:Version})
[... etc ...]
-Depends: ${misc:Depends}, python (= ${binary:Version}), python2.7-dbg (=
2.7.3~rc2-1~)
+Depends: ${misc:Depends}, python (= ${binary:Version}), python2.7-dbg (=
2.7.3-1~)
Not currently satisfied by python2.7 in wheezy. Would a tpu upload
that makes the other changes but leaves this one out make sense to
you?
Then the bulk of this upload could cleanly migrate to wheezy and the
python2.7 update could be considered separately and still could happen
if it seems appropriate.
--- python-defaults-2.7.3~rc2/debian/python-policy.sgml 2012-06-05
23:07:12.0 -0400
+++ python-defaults-2.7.3/debian/python-policy.sgml 2012-07-26
18:26:10.0 -0400
@@ -330,7 +330,7 @@
item
p
/usr/share/python/runtime.d/*.rtremove: these are called when
- a runtime is installed or stops being supported. The first
+ a runtime is removed or stops being supported. The first
Sure.
[...]
--- python-defaults-2.7.3~rc2/debian/pyversions.py2012-06-05
22:58:56.0 -0400
+++ python-defaults-2.7.3/debian/pyversions.py2012-07-26
18:26:10.0 -0400
@@ -110,7 +110,8 @@
else:
return _unsupported_versions
-_supported_versions = None
+_supported_versions = [python%s % ver for ver in \
+ os.environ.get('DEBPYTHON_SUPPORTED', '').split()]
That's
* pyversions, dh_python2, pycompile: allow to override system's list of
supported Python versions via DEBPYTHON_SUPPORTED and default Python
version via DEBPYTHON_DEFAULT env. variables
Do any packages in wheezy use these envvars? What will happen if they
are rebuilt against python-defaults from wheezy?
[...]
--- python-defaults-2.7.3~rc2/debpython/depends.py2012-06-05
22:58:56.0 -0400
+++ python-defaults-2.7.3/debpython/depends.py2012-07-26
18:26:10.0 -0400
[...]
@@ -94,11 +94,13 @@
tpl = 'python-dbg' if dbgpkg else 'python'
minv = pub_vers[0]
maxv = pub_vers[-1]
-if dbgpkg:
-tpl2 = 'python%d.%d-dbg'
-else:
-tpl2 = 'python%d.%d'
-self.depend(' | '.join(tpl2 % i for i in debsorted(pub_vers)))
+# generating python2.X | python2.Y | python2.Z dependencies
+# disabled (see #625740):
+#if dbgpkg:
+#tpl2 = 'python%d.%d-dbg'
+#else:
+#tpl2 = 'python%d.%d'
+#self.depend(' | '.join(tpl2 % i for i in debsorted(pub_vers)))
If I understand #625740 correctly, without this change, dh_python2
generates python2.6 | python2.7 dependencies which apt (sometimes?)
takes as defaulting to python2.6. I think this change should be
included in wheezy.
[...]
@@ -112,21 +114,17 @@
if stats['compile']:
Bug#692298: tpu: git/1:1.7.10.4-1+wheezy1 (Re: unblock: git/1:1.7.10.4-2)
Julien Cristau wrote: On Sun, Nov 18, 2012 at 12:16:05 -0800, Jonathan Nieder wrote: In light of [1], I'm happy to skip b8c78e2a git svn: work around SVN 1.7 mishandling of svn:special changes in a tpu upload. Proposed upload attached. [...] Ack, please go ahead. Thanks for the quick turnaround. Pushed to git://repo.or.cz/git/debian/git.git debian-testing git://git.debian.org/~jrnieder-guest/git.git debian-testing and uploaded. -- 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/20121124084024.GA12381@elie.Belkin
Bug#692298: unblock: git/1:1.7.10.4-2
Julien Cristau wrote:
On Sun, Nov 4, 2012 at 11:30:04 -0800, Jonathan Nieder wrote:
Please unblock git/1:1.7.10.4-2 to get fixes to
#678137 -- incompatibility with SVN 1.7
and
#587650 -- Byte order is not compatible at ../../lib/Storable.pm
errors when accessing git-svn repositories created with
perl/squeeze
[...]
The first of those is big, and svn 1.7 is not in wheezy...
In light of [1], I'm happy to skip
b8c78e2a git svn: work around SVN 1.7 mishandling of svn:special changes
in a tpu upload. Proposed upload attached. What do you think?
Thanks,
Jonathan
[1] http://svn.apache.org/viewvc?view=revisionrevision=1406870
From: Jonathan Nieder jrnie...@gmail.com
Date: Fri, 12 Oct 2012 13:26:39 -0700
Subject: debian: use YAML as platform-independent .git/svn/.caches format
On 32-bit arches, attempts to use git svn fetch on repositories
cloned using older perl currently produce
Byte order is not compatible at ../../lib/Storable.pm (autosplit
into ../../lib/auto/Storable/_retrieve.al) line 380, at
/usr/share/perl/5.12/Memoize/Storable.pm line 21
because the byteorder changed from 1234 to 12345678 when perl's
use64bit compile-time option was enabled.
Wait --- isn't Memoize::Storable's nstore option supposed to shield
users from such changing platform details? Unfortunately the 'nstore'
option has no effect due to a typo in its implementation (bug#677292).
Rather than coming up with a transition plan to account for git
repositories shared between machines with and without a fix to that
bug, let's move away from Memoize::Storable completely. A patch
applied upstream in 1.7.11 teaches 'git svn' to use libyaml when
available to read and write its caches under a new filename with a
simpler, platform-independent format. The Debian packaging can
complete the fix by adding a run-time dependency by git-svn on
libyaml-perl.
[jn: backport for wheezy: adjust version number and position in
debian/diff]
Analysis-by: Tim Retout dioc...@debian.org
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
debian/changelog | 11 +
debian/control | 4 +-
...-YAML-format-for-mergeinfo-cache-when-poss.diff | 294 +
3 files changed, 307 insertions(+), 2 deletions(-)
create mode 100644
debian/diff/0013-git-svn-use-YAML-format-for-mergeinfo-cache-when-poss.diff
diff --git a/debian/changelog b/debian/changelog
index 7558b3ab..575cd06a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+git (1:1.7.10.4-1+wheezy1) testing; urgency=low
+
+ * debian/diff/0013-git-svn-use-YAML-format-...diff: new from 1.7.11:
+git svn: use YAML format for mergeinfo cache when possible.
+ * debian/control: git-svn: Depends: libyaml-perl for platform- and
+version-independent .git/svn/.caches format; Build-Depends:
+libyaml-perl for tests (thx Tim Retout for the analysis; closes:
+#587650).
+
+ -- Jonathan Nieder jrnie...@gmail.com Sun, 18 Nov 2012 11:45:41 -0800
+
git (1:1.7.10.4-1) unstable; urgency=low
* new upstream point release (thx Jonathan Nieder).
diff --git a/debian/control b/debian/control
index e1f1a442..a8e188a2 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Gerrit Pape p...@smarden.org
Uploaders: Jonathan Nieder jrnie...@gmail.com
Build-Depends: libz-dev,
libcurl4-gnutls-dev | libcurl3-gnutls-dev, libexpat1-dev,
- subversion, libsvn-perl | libsvn-core-perl,
+ subversion, libsvn-perl | libsvn-core-perl, libyaml-perl,
tcl8.5, gettext,
cvs, cvsps, libdbd-sqlite3-perl,
unzip, libio-pty-perl,
@@ -147,7 +147,7 @@ Description: fast, scalable, distributed revision control
system (cvs interopera
Package: git-svn
Architecture: all
-Depends: git ( ${source:Upstream-Version}), git (
${source:Upstream-Version}-.), libsvn-perl | libsvn-core-perl, libwww-perl,
libterm-readkey-perl
+Depends: git ( ${source:Upstream-Version}), git (
${source:Upstream-Version}-.), libsvn-perl | libsvn-core-perl, libyaml-perl,
libwww-perl, libterm-readkey-perl
Suggests: git-doc, subversion
Replaces: cogito ( 0.16rc2-0)
Description: fast, scalable, distributed revision control system (svn
interoperability)
diff --git
a/debian/diff/0013-git-svn-use-YAML-format-for-mergeinfo-cache-when-poss.diff
b/debian/diff/0013-git-svn-use-YAML-format-for-mergeinfo-cache-when-poss.diff
new file mode 100644
index ..a0f1dfdb
--- /dev/null
+++
b/debian/diff/0013-git-svn-use-YAML-format-for-mergeinfo-cache-when-poss.diff
@@ -0,0 +1,294 @@
+From db8445cce70a6bdb014fb04624ebcce7f39ad905 Mon Sep 17 00:00:00 2001
+From: Jonathan Nieder jrnie...@gmail.com
+Date: Sat, 9 Jun 2012 17:35:35 -0500
+Subject: git-svn: use YAML format for mergeinfo cache when possible
+
+Since v1.7.0-rc2~11 (git-svn: persistent memoization, 2010-01-30),
+git-svn has maintained some private per-repository caches in
+.git/svn/.caches to avoid refetching
Bug#687220: unblock: xz-utils/5.1.1alpha+20120614-2
On 11 October, Julien Cristau wrote: On Mon, Sep 10, 2012 at 16:26:27 -0700, Jonathan Nieder wrote: Unfortunately there has not been a stable release on the 5.1.y branch of XZ Utils. This update is an attempt to make the best of what we have, by: - in existing features, matching behavior of the upstream master branch as closely as possible - not adding any new features - documenting the relationship to upstream (patches applied and patches not applied) in README.Debian [...] Looks fine. Uploaded. Thanks again for the review and followup. -- 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/20121119014519.GA12521@elie.Belkin
Bug#692298: unblock: git/1:1.7.10.4-2
Julien Cristau wrote: On Sun, Nov 4, 2012 at 11:30:04 -0800, Jonathan Nieder wrote: Please unblock git/1:1.7.10.4-2 to get fixes to #678137 -- incompatibility with SVN 1.7 and #587650 -- Byte order is not compatible at ../../lib/Storable.pm errors when accessing git-svn repositories created with perl/squeeze [...] The first of those is big, and svn 1.7 is not in wheezy... Thanks for looking it over. I can prepare an upload for tpu with the fix to the second of those and b8c78e2a git svn: work around SVN 1.7 mishandling of svn:special changes if you like (which is needed to avoid svn update failing with svn 1.7 and newer $ svn up Updating '.': svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \ line 1583: assertion failed (action == svn_wc_conflict_action_edit \ || action == svn_wc_conflict_action_delete || action == \ svn_wc_conflict_action_replace) on changes pushed by git that flip the is a symlink bit). As for the rest of the svn 1.7 compatibility changes, would you be okay with them after some more aging in unstable? They would make it easier for users to upgrade to svn 1.7 privately. Hope that helps, Jonathan -- 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/20121115160756.GA13061@elie.Belkin
Bug#687220: proposed upload: xz-utils/5.1.1alpha+20120614-2
Julien Cristau wrote: On Thu, Oct 11, 2012 at 18:00:36 -0700, Jonathan Nieder wrote: Hi Mohammed, Thorsten, et al, I am looking to upload version 5.1.1alpha+20120614-2 of xz-utils to unstable. The package can be found on alioth.debian.org: - http://alioth.debian.org/~jrnieder-guest/temp/xz-utils/xz-utils_5.1.1alpha+20120614-2.dsc - git://git.debian.org/collab-maint/xz.git master What's up here? Thanks for the ping. I'm guessing Thorsten was hoping that I would upload it on my own[1], but I can't do that until keyring-maint processes the last batch of account requests (a thanksless job). Regards, Jonathan [1] https://lists.debian.org/debian-newmaint/2012/10/msg2.html -- 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/20121115161557.GB13061@elie.Belkin
Bug#692298: unblock: git/1:1.7.10.4-2
Jonathan Nieder wrote: Please unblock git/1:1.7.10.4-2 to get fixes to #678137 -- incompatibility with SVN 1.7 and #587650 -- Byte order is not compatible at ../../lib/Storable.pm errors when accessing git-svn repositories created with perl/squeeze Gentle reminder since this has hit its 10 days. If you have any questions, please don't hesitate to ask. Thanks, Jonathan -- 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/20121112161456.GA4025@elie.Belkin
Bug#692011: taxbird: version in testing (0.16.x) is completely useless, need the latest version for 2012 tax declaration
(cc-ing the bug, hoping that's ok) Hi Toni, Toni Mueller wrote: On Thu, Nov 08, 2012 at 07:32:18AM -0800, Jonathan Nieder wrote: You can track progress at http://bugs.debian.org/692011. Also if you I suggest that taxbird goes into volatile. Volatile doesn't exist any more. It's called stable (using the stable-updates channel to get fixes in more quickly) these days. [...] Also, the release cycle of taxbird, or any other such program, is largely determined by changes in federal law, and not by Debian's (or any other distribution's) release cycle. That would be analagous to tzdata, which also gets updates through stable-updates. Regards, Jonathan -- 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/20121108160519.GA23055@elie.Belkin
Bug#692010: unblock: raptor2/2.0.8-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Hi,
Please unblock raptor2/2.0.8-2, which adds a Breaks against raptor1
versions without symbol versioning, fixing the important bug#656928:
| raptor_sequence.c:385: (raptor_sequence_get_at) assertion failed: object
pointer of type raptor_sequence is NULL.
| raptor_sequence.c:385: (raptor_sequence_get_at) assertion failed: object
pointer of type raptor_sequence is NULL.
To avoid confusion, I should mention that this update has a missing
changelog item for a minor change, unfortunately:
* Stop passing --with-xml-parser=libxml to configure, since it is
redundant and unrecognized these days.
I provided a debdiff adding the missing changelog entry[1], but the
maintainer didn't seem interested, and I don't think that rises to the
level of NMU-worthy.
Thoughts welcome, as always.
Regards,
Jonathan
[1] http://bugs.debian.org/656928#40
diff -Nru raptor2-2.0.8/debian/changelog raptor2-2.0.8/debian/changelog
--- raptor2-2.0.8/debian/changelog 2012-06-24 23:30:38.0 -0700
+++ raptor2-2.0.8/debian/changelog 2012-09-07 21:39:50.0 -0700
@@ -1,3 +1,13 @@
+raptor2 (2.0.8-2) unstable; urgency=low
+
+ * debian/control: add a breaks relation by libraptor2-0 against squeeze
+libraptor1 to force upgrades to a version with symbol versioning
+(Closes: #656928)
+ * Added debian/patches/001-remove-m-strict-help.patch to remove -m strict
+from rapper help (Closes: #685682)
+
+ -- Dave Beckett daj...@debian.org Fri, 07 Sep 2012 21:32:35 -0700
+
raptor2 (2.0.8-1) unstable; urgency=low
* New upstream release
diff -Nru raptor2-2.0.8/debian/control raptor2-2.0.8/debian/control
--- raptor2-2.0.8/debian/control2012-03-15 20:50:11.0 -0700
+++ raptor2-2.0.8/debian/control2012-09-07 21:30:30.0 -0700
@@ -21,6 +21,7 @@
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: libraptor1 ( 1.4.21-3)
Suggests: raptor2-utils
Description: Raptor 2 RDF syntax library
Raptor is a C library providing a set of parsers and serializers for
diff -Nru raptor2-2.0.8/debian/patches/001-remove-m-strict-help.patch
raptor2-2.0.8/debian/patches/001-remove-m-strict-help.patch
--- raptor2-2.0.8/debian/patches/001-remove-m-strict-help.patch 1969-12-31
16:00:00.0 -0800
+++ raptor2-2.0.8/debian/patches/001-remove-m-strict-help.patch 2012-09-07
21:45:17.0 -0700
@@ -0,0 +1,22 @@
+Description: Remove -m MODE from rapepr help
+Origin: commit:430a21084665da35a715e9055d72a13487972969
+Author: Dave Beckett d...@dajobe.org
+Last-Update: 2012-09-07
+
+Remove -m MODE from help
+
+This option was removed in commit f94fa561db05b21132b14a2b72f05b77e666c252
+on Wed Apr 28 21:31:54 2010 -0700 as part of the Raptor V2 work.
+
+diff --git a/utils/rapper.c b/utils/rapper.c
+index c130177..31affb8 100644
+--- a/utils/rapper.c
b/utils/rapper.c
+@@ -707,7 +707,6 @@ main(int argc, char *argv[])
+ puts(HELP_TEXT(f OPTION(=VALUE), feature OPTION(=VALUE), HELP_PAD
Set parser or serializer options HELP_PAD Use `-f help' for a list of valid
options));
+ puts(HELP_TEXT(g, guess , Guess the input syntax (same as
-i guess)));
+ puts(HELP_TEXT(h, help, Print this help, then exit));
+-puts(HELP_TEXT(m MODE, mode MODE , Set parser mode - 'lax'
(default) or 'strict'));
+ puts(HELP_TEXT(q, quiet , No extra information messages));
+ puts(HELP_TEXT(r, replace-newlines, Replace newlines with spaces in
literals));
+ #ifdef SHOW_GRAPHS_FLAG
diff -Nru raptor2-2.0.8/debian/patches/series
raptor2-2.0.8/debian/patches/series
--- raptor2-2.0.8/debian/patches/series 1969-12-31 16:00:00.0 -0800
+++ raptor2-2.0.8/debian/patches/series 2012-09-07 21:45:55.0 -0700
@@ -0,0 +1 @@
+001-remove-m-strict-help.patch
diff -Nru raptor2-2.0.8/debian/rules raptor2-2.0.8/debian/rules
--- raptor2-2.0.8/debian/rules 2012-06-24 23:31:55.0 -0700
+++ raptor2-2.0.8/debian/rules 2012-09-07 21:54:14.0 -0700
@@ -13,7 +13,6 @@
DEB_DBG_PACKAGE_libraptor2-0 = libraptor2-0-dbg
DEB_CONFIGURE_USER_FLAGS= \
- --with-xml-parser=libxml \
--enable-release
LDFLAGS += -Wl,--default-symver
Bug#692074: unblock: procps/1:3.3.5-1
Craig Small wrote: Please unblock package procps If I understand correctly this involves a small transition: $ cupt rdepends libprocps0 Reverse-Depends: libprocps0-dev 1:3.3.4-1: libprocps0 (= 1:3.3.4-1) Reverse-Depends: open-vm-tools 2:8.8.0+2012.05.21-724730-1+nmu1: libprocps0 (= 1:3.3.2-1) Reverse-Depends: open-vm-tools 2:8.8.0+2012.05.21-724730-4: libprocps0 (= 1:3.3.2-1) Reverse-Depends: procps 1:3.3.4-1: libprocps0 (= 1:3.3.2-1) Reverse-Depends: procps 1:3.3.3-2: libprocps0 (= 1:3.3.2-1) Reverse-Depends: xmem 1.20-27.2: libprocps0 (= 1:3.3.2-1) That is, source packages open-vm-tools and xmem would need to be rebuilt. [...] procps 3.3.5-1 is blocked because libproc1 is new. The problem is that the oldest libproc0 will not work with 3.3.5-1 because the API changed. I think including libprocps1 in wheezy would be good, but would it be possible to back out the ABI break in sid in the meantime? Thanks, Jonathan -- 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/20121102003737.GA2609@elie.Belkin
Bug#692074: unblock: procps/1:3.3.5-1
Craig Small wrote: Tell me how to do it (not the API change, but more around the what version etc) and I will. I assume its making a 3.3.4-2 with a debian patch to reverse the API and then do.. something. I think the steps are: 1. prepare 3.3.4-2 backing out the ABI change, ask ftpmasters to reject 3.3.5-1 from NEW 2. upload 3.3.4-2 3. coordinate with the release team on the next step (probably that means scheduling a transition to libprocps1) Jonathan -- 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/20121102031055.GC5371@elie.Belkin
Re: [squeeze] Re: ecm: file conflict with gmp-ecm
Philipp Kern wrote: Interestingly gmp-ecm does conflict with ecm in wheezy, even though the file conflict is solved. Oh, excellent. The Conflicts is even present in squeeze. Would you mind tagging 580548 squeeze-ignore to get it off the radar? Then I'll file a bug for gmp-ecm to make the conflicts in wheezy versioned. Thanks for noticing. Jonathan -- 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/20121011220639.GC28947@elie.Belkin
Bug#687220: proposed upload: xz-utils/5.1.1alpha+20120614-2
Hi Mohammed, Thorsten, et al, I am looking to upload version 5.1.1alpha+20120614-2 of xz-utils to unstable. The package can be found on alioth.debian.org: - http://alioth.debian.org/~jrnieder-guest/temp/xz-utils/xz-utils_5.1.1alpha+20120614-2.dsc - git://git.debian.org/collab-maint/xz.git master It is a pretty quiet update. All the changes should look familiar by now. Patches cherry-picked from upstream: * Check that the first byte of range encoded data is zero to catch broken files sooner. * xz.1: Document the new minimum xz version to decompress field in xz --robot -lvv output. * xz -lvv: The minimum xz version needed to decompress blocks with zero-length uncompressed data is 5.0.2, not 5.0.3. The only other change is a list of patch descriptions in xz-utils/README.Debian. The hope is that this can help satisfy the curiosity of people wondering about differences between the upstream and packaged tools and library. Julien Cristau wrote: Looks fine. so this is release team approved™. I'd be happy if you have a chance to look it over. Thanks, Jonathan -- 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/20121012010036.GD28947@elie.Belkin
Bug#668008: unblock: uw-imap
Hi Magnus, Magnus Holmgren wrote: The SONAME *shouldn't* have had to be changed as 2007f is merely a bugfix release, except for an attempt to also support AIX 5.2, but that's nothing that affects us. There are no ABI or API changes. See attached diff. At this point we have to either [...] set the internal version string back to 2007e, That seems like the natural thing to do to me. Thanks, Jonathan (just an innocent bystander, not on the release team or a user of this package) -- 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/20121009105711.GA5098@elie.Belkin
Bug#678624: pu: package xz-utils/5.0.0-3
Hi, In June, Jonathan Nieder wrote: +xz-utils (5.0.0-3) stable; urgency=low + + * Fixes from upstream: Ping. A number of these are important to me: +* liblzma: + - lzma_easy_buffer_encode() and lzma_stream_buffer_encode() +avoid writing Blocks with empty compressed data that xz and +liblzma versions before 5.0.2 cannot read. Without this patch, using python-lzma in a naive way to compress an empty file produces an XZ file that many implementations (including the one currently in squeeze) cannot decompress. + - The LZMA2 decoder skips Blocks with empty compressed data +instead of rejecting them. This patch improves compatibility by decompressing those files. (*) + - Validates encoder arguments better. It is harder to segfault +or create a corrupt XZ file [...] This patch improves compatibility by catching some misuses of the API that have no valid meaning. (**) + - bcj: Fix possibility of incorrect LZMA_BUF_ERROR (reported in +XZ Embedded as Fedora bug 735408). An important one --- avoids spurious errors when one is unlucky about how buffer sizes line up. Improves compatibility. + - Plugs a memory leak in lzma_stream_encoder(). Small memory leak, but the patch is obviously correct. + - lzma_index_init() returns NULL instead of segfaulting on +allocation failure. Not very important unless liblzma is used in a process mapping interesting things at low addresses, but the patch is obviously correct. +* docs/examples/xz_pipe_decompress.c checks that the last + lzma_code() call returned LZMA_STREAM_END to avoid mistaking a + file without a proper footer for a valid XZ file. Documentation fix. Programs copying the example would not notice files that are truncated, for example due to a failed download. See http://thread.gmane.org/gmane.comp.compression.xz.devel/85/focus=94 +* xz -v -v --list does not free() filter options unless the + filter options array has been initialized. [...] Might be a security bug (invalid free()s overflowing on-stack array). Not obvious how to exploit it, though. +* xzegrep and xzfgrep perform extended regex and fixed-string + matches, respectively. (The previous behavior was to always + use basic regexes.) Usability fix. Not too important but obviously corret. +* The exit status from “xzdiff foo.xz bar.xz” reflects whether + files differ. Thanks to Peter Pallinger. Closes: #635501. Another simple usability fix. (***) +* xzgrep does not fail just because the decompressor has died + with SIGPIPE due to some unconsumed output. This makes the + exit status from commands such as xzgrep -q more predictable. This is needed for xzgrep -q and xzgrep of binary files to be actually usable for scripts. Especially in the latter case it is easy to write a script and test it without ever running into this, then run into it later. :/ +* The Czech “xz --help” output uses a more correct term for files + with holes. Thanks to Petr Hubený. Closes: #605762. +* The Italian diagnostic for an invalid --format argument lost an + extra 'N'. Minor (one-word) translation fixes. + * debian/rules: chmod +x tests/test_scripts.sh for new xzdiff +tests. Supporting (***) --- quilt doesn't track the +x bit. + * debian/symbols: Bump the minimal versions for LZMA2 encoder +functions that reject more bad arguments and skip empty blocks. Supporting (*) and (**). + * liblzma-dev: Install an appropriate library for static linking +instead of the decompression-only version used to build xzdec. +Thanks to Anton Tolchanov. Closes: #673001. This one's embarassing and what prompted me to look again at the state of the package in squeeze in the first place. Thoughts? Anything I can do to help get this reviewed? Jonathan -- 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/20121005174515.GD15867@elie.Belkin
Bug#687220: unblock: xz-utils/5.1.1alpha+20120614-2
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Tags: wheezy
Hi,
Unfortunately there has not been a stable release on the 5.1.y branch
of XZ Utils. This update is an attempt to make the best of what we
have, by:
- in existing features, matching behavior of the upstream master
branch as closely as possible
- not adding any new features
- documenting the relationship to upstream (patches applied
and patches not applied) in README.Debian
I've been using these changes for a couple of months now. Not
uploaded yet, so I can make small tweaks if you have good ideas for
some. Diffstat with patches applied, excluding debian/patches:
debian/changelog | 15 ++
debian/xz-utils.README.Debian | 49 ++--
src/liblzma/lzma/lzma_decoder.c|8 -
src/liblzma/rangecoder/range_decoder.h | 12 ++--
src/xz/list.c |6 ++--
src/xz/xz.1| 18 +++-
6 files changed, 96 insertions(+), 12 deletions(-)
debdiff attached. Thoughts?
Thanks for your hard work,
Jonathan
diff -Nru xz-utils-5.1.1alpha+20120614/debian/changelog
xz-utils-5.1.1alpha+20120614/debian/changelog
--- xz-utils-5.1.1alpha+20120614/debian/changelog 2012-06-16
13:03:18.0 -0700
+++ xz-utils-5.1.1alpha+20120614/debian/changelog 2012-09-10
14:35:33.0 -0700
@@ -1,3 +1,18 @@
+xz-utils (5.1.1alpha+20120614-2) unstable; urgency=low
+
+ * Apply fixes from 5.1.2alpha. Closes: #685220.
+- liblzma: report a LZMA_DATA_ERROR when range encoded data starts
+ with a nonzero byte. This is a sanity check to catch malformed
+ files that no known encoders produce.
+- xz -v -v --list: Support for decompressing blocks with
+ zero-length uncompressed data was added in xz 5.0.2, not 5.0.3.
+- xz.1: xz --robot -v -v --list gained a minimum xz version to
+ decompress field.
+ * xz-utils/README.Debian: Document differences from upstream.
+Closes: #685217.
+
+ -- Jonathan Nieder jrnie...@gmail.com Mon, 10 Sep 2012 14:35:33 -0700
+
xz-utils (5.1.1alpha+20120614-1) unstable; urgency=low
* New snapshot, taken from upstream commit f1675f76.
diff -Nru xz-utils-5.1.1alpha+20120614/debian/patches/decoder-check-first-0x00
xz-utils-5.1.1alpha+20120614/debian/patches/decoder-check-first-0x00
--- xz-utils-5.1.1alpha+20120614/debian/patches/decoder-check-first-0x00
1969-12-31 16:00:00.0 -0800
+++ xz-utils-5.1.1alpha+20120614/debian/patches/decoder-check-first-0x00
2012-09-10 14:10:45.0 -0700
@@ -0,0 +1,69 @@
+From: Lasse Collin lasse.col...@tukaani.org
+Date: Thu, 28 Jun 2012 10:47:49 +0300
+Subject: liblzma: Check that the first byte of range encoded data is 0x00.
+
+It is just to be more pedantic and thus perhaps catch broken
+files slightly earlier.
+
+Signed-off-by: Jonathan Nieder jrnie...@gmail.com
+---
+ src/liblzma/lzma/lzma_decoder.c|8 ++--
+ src/liblzma/rangecoder/range_decoder.h | 12 +---
+ 2 files changed, 15 insertions(+), 5 deletions(-)
+
+diff --git a/src/liblzma/lzma/lzma_decoder.c b/src/liblzma/lzma/lzma_decoder.c
+index 5abbc0d..b8f9317 100644
+--- a/src/liblzma/lzma/lzma_decoder.c
b/src/liblzma/lzma/lzma_decoder.c
+@@ -289,8 +289,12 @@ lzma_decode(lzma_coder *restrict coder, lzma_dict
*restrict dictptr,
+ // Initialization //
+
+
+- if (!rc_read_init(coder-rc, in, in_pos, in_size))
+- return LZMA_OK;
++ {
++ const lzma_ret ret = rc_read_init(
++ coder-rc, in, in_pos, in_size);
++ if (ret != LZMA_STREAM_END)
++ return ret;
++ }
+
+ ///
+ // Variables //
+diff --git a/src/liblzma/rangecoder/range_decoder.h
b/src/liblzma/rangecoder/range_decoder.h
+index fb96180..e0b051f 100644
+--- a/src/liblzma/rangecoder/range_decoder.h
b/src/liblzma/rangecoder/range_decoder.h
+@@ -25,20 +25,26 @@ typedef struct {
+
+
+ /// Reads the first five bytes to initialize the range decoder.
+-static inline bool
++static inline lzma_ret
+ rc_read_init(lzma_range_decoder *rc, const uint8_t *restrict in,
+ size_t *restrict in_pos, size_t in_size)
+ {
+ while (rc-init_bytes_left 0) {
+ if (*in_pos == in_size)
+- return false;
++ return LZMA_OK;
++
++ // The first byte is always 0x00. It could have been omitted
++ // in LZMA2 but it wasn't, so one byte is wasted in every
++ // LZMA2 chunk.
++ if (rc-init_bytes_left == 5 in[*in_pos] != 0x00)
++ return LZMA_DATA_ERROR;
+
+ rc-code = (rc-code 8) | in[*in_pos];
+ ++*in_pos;
+ --rc-init_bytes_left;
+ }
+
+- return true;
++ return
[squeeze] Re: ecm: file conflict with gmp-ecm
Bart Martens wrote: On Sun, Sep 09, 2012 at 11:56:16AM -0700, Jonathan Nieder wrote: In January, Jonathan Nieder wrote: Bart Martens wrote: * Renamed ecm to ecm-compress and unecm to ecm-uncompress. Closes: #580548. Is this worth fixing in squeeze? My feeling is no --- it's too risky to be renaming binaries in a stable release this late. Perhaps there could be a Conflicts relation to warn people about the bug, though. What do you think? I don't mind doing the renaming in squeeze as well. On the other hand I don't see hundreds of squeeze users complaining about this. What is the opinion of the Stable Release Managers ? Cc-ing them to find out. Thanks, Jonathan -- 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/20120909194411.GA694@mannheim-rule.local
Bug#686369: unblock: grub/0.97-66.1 (pre-approval)
Hi David, David Prévot wrote: grub 0.97-64 (in Squeeze) is already a dummy package that depends on grub-pc, That's comforting. [...] Since grub-legacy (even 0.97-64) already provides grub, the few remaining rdepends*, if any remains, shouldn't be affected That's not comforting at all, since grub-legacy is effectively unmaintained. What are the remaining rdepends, and can they be fixed? Hope that helps, Jonathan -- 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/20120831170259.GC166@mannheim-rule.local
Bug#686369: unblock: grub/0.97-66.1 (pre-approval)
Julien Cristau wrote: On Fri, Aug 31, 2012 at 10:02:59 -0700, Jonathan Nieder wrote: David Prévot wrote: Since grub-legacy (even 0.97-64) already provides grub, the few remaining rdepends*, if any remains, shouldn't be affected That's not comforting at all, since grub-legacy is effectively unmaintained. What are the remaining rdepends, and can they be fixed? AFAICT grub-installer still installs grub-legacy in some cases. That's unlikely to change before the wheezy release. Yes, and that's fine. I meant rdepends of the grub virtual package, since such a dependency should be satisfied by grub2 as well. Thanks, Jonathan -- 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/20120831183031.ga...@mannheim-rule.att.net
Bug#685346: pu: package checkgmail/1.13+svn43-2+squeeze0.1
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: pu
Tags: squeeze
Hi,
Since late last year, checkgmail has not been working because gmail
changed its authentication protocol (bug#650454). The symptom is that
checkgmail just repeatedly asks for login and password information.
Luckily a fix was made quickly and has been in use in sid and wheezy
since January this year.
I would like to apply the same fix in squeeze. Last time I checked,
it worked (though I'd of course check again before uploading). Sandro
(the maintainer) has said an NMU with that fix (debdiff attached)
would be fine. Sensible?
Thanks for your work,
Jonathan
checkgmail-1.13+svn43/debian/changelog |9
checkgmail-1.13+svn43/debian/patches/00list|1
debian/patches/60_bts650454_send_galx_as_cookie.dpatch | 31 +
3 files changed, 41 insertions(+)
diff -u checkgmail-1.13+svn43/debian/changelog
checkgmail-1.13+svn43/debian/changelog
--- checkgmail-1.13+svn43/debian/changelog
+++ checkgmail-1.13+svn43/debian/changelog
@@ -1,3 +1,12 @@
+checkgmail (1.13+svn43-2+squeeze0.1) stable; urgency=low
+
+ * Non-maintainer upload
+ * debian/patches/60_bts650454_send_galx_as_cookie.dpatch
+- fix auth problem with GMail by passing GALX in the cookie; thanks to
+ Johan Sandblom for the report; Closes: #650454
+
+ -- Jonathan Nieder jrnie...@gmail.com Sun, 19 Aug 2012 17:28:49 -0700
+
checkgmail (1.13+svn43-2) unstable; urgency=low
* 40_bts568882_use_GTK_new_widget_insteadof_libsexy.dpatch
diff -u checkgmail-1.13+svn43/debian/patches/00list
checkgmail-1.13+svn43/debian/patches/00list
--- checkgmail-1.13+svn43/debian/patches/00list
+++ checkgmail-1.13+svn43/debian/patches/00list
@@ -5,0 +6 @@
+60_bts650454_send_galx_as_cookie
only in patch2:
unchanged:
---
checkgmail-1.13+svn43.orig/debian/patches/60_bts650454_send_galx_as_cookie.dpatch
+++ checkgmail-1.13+svn43/debian/patches/60_bts650454_send_galx_as_cookie.dpatch
@@ -0,0 +1,31 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 60_bts650454_send_galx_as_cookie.patch by Jan Jergus
+##
+## DP: Description: pass GALX as cookie, to avoid continuos pop-up for auth
+## DP: Bug:
http://sourceforge.net/tracker/?func=detailaid=3406322group_id=137480atid=738663
+## DP: Bug-Debian: http://bugs.debian.org/650454
+## DP: Forwarded: not-needed
+
+@DPATCH@
+Index: checkgmail/checkgmail
+===
+--- checkgmail.orig/checkgmail 2012-01-08 18:14:20.369935655 +0100
checkgmail/checkgmail 2012-01-08 18:16:16.170116161 +0100
+@@ -891,7 +891,8 @@
+ print Error: No GALX input field found\n;
+ return Error: No GALX input field found;
+ }
+- $post_galx = URI_escape(URI_unescape($1));
++ my $galx = URI_unescape($1);
++ $post_galx = URI_escape($galx);
+
+ # Find the data to post
+ my $post_data;
+@@ -907,6 +908,7 @@
+ my $post_req = HTTP::Request-new('POST' =
https://www.google.com/accounts/ServiceLoginAuth?service=mail;);
+ $post_req-content_type('application/x-www-form-urlencoded');
+ $post_req-content($post_data);
++ $post_req-header('Cookie' = GALX=$galx);
+ my $post_response = $ua-request($post_req);
+ if ($post_response-is_error) {
+ my $code = $response-code;
Priority field of xz-utils package
(please direct replies to debian-devel only) Ever since dpkg started using liblzma directly (dpkg 1.16.4), the xz command is no longer needed in a minimal Debian system. Based on its list of reverse-dependencies, it would presumably even be safe to lower its priority to optional. I think standard or optional is the correct priority. To be conservative I'd also be open to making the priority important. Dear Debianites, what do you prefer? I'm cc-ing the release team because either change this late in the release cycle would require a freeze exception (and I'd be interested in their advice) and the installer team because of the effect on the installer size and the installed package set. Looking forward to your thoughts, Jonathan -- 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/20120818022337.GA1305@mannheim-rule.local
Bug#683988: unblock: leptonlib/1.69-3.1, tesseract/3.02.01-6
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
As described in bug#680674, leptonlib in wheezy provides liblept.so.3
in a package with the same name (libleptonica) as provides
liblept.so.1 in squeeze.
In sid the binary package has been renamed to liblept3, following the
shared library policy. This solves release-critical bugs #664176,
#681570, and #681574. Please unblock leptonlib and tesseract to get
the fix.
If you have any questions, please don't hesitate to ask. Debdiffs
attached.
Thanks for your work,
Jonathan
diff -Nru leptonlib-1.69/debian/changelog leptonlib-1.69/debian/changelog
--- leptonlib-1.69/debian/changelog 2012-03-15 15:45:46.0 -0700
+++ leptonlib-1.69/debian/changelog 2012-07-19 14:39:52.0 -0700
@@ -1,3 +1,13 @@
+leptonlib (1.69-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload
+ * Rename libleptonica package to liblept3 (closes: #664176, #681570,
+#681574)
+* liblept3 Breaks and Replaces libleptonica (= 1.69~) to reflect
+ transfer of ownership of /usr/lib/liblept.so.3
+
+ -- Jonathan Nieder jrnie...@gmail.com Thu, 19 Jul 2012 16:39:48 -0500
+
leptonlib (1.69-3) unstable; urgency=low
* Get ready for libpng transition (closes: #662392)
diff -Nru leptonlib-1.69/debian/control leptonlib-1.69/debian/control
--- leptonlib-1.69/debian/control 2012-03-15 15:25:33.0 -0700
+++ leptonlib-1.69/debian/control 2012-07-19 14:38:28.0 -0700
@@ -8,7 +8,7 @@
Package: libleptonica-dev
Section: libdevel
Architecture: any
-Depends: libleptonica (= ${binary:Version}), ${misc:Depends}
+Depends: liblept3 (= ${binary:Version}), ${misc:Depends}
Description: image processing library
Well-tested C library for some basic image processing operations,
along with a description of the functions and some design methods. A
@@ -23,10 +23,12 @@
queues, generic stacks, generic lists, and endian-independent
indexing into 32-bit arrays.
-Package: libleptonica
+Package: liblept3
Section: libs
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
+Breaks: libleptonica (= 1.69~)
+Replaces: libleptonica (= 1.69~)
Description: image processing library
Well-tested C library for some basic image processing operations,
along with a description of the functions and some design methods. A
diff -Nru leptonlib-1.69/debian/liblept3.dirs
leptonlib-1.69/debian/liblept3.dirs
--- leptonlib-1.69/debian/liblept3.dirs 1969-12-31 16:00:00.0 -0800
+++ leptonlib-1.69/debian/liblept3.dirs 2012-01-09 14:24:02.0 -0800
@@ -0,0 +1 @@
+usr/lib
diff -Nru leptonlib-1.69/debian/liblept3.install
leptonlib-1.69/debian/liblept3.install
--- leptonlib-1.69/debian/liblept3.install 1969-12-31 16:00:00.0
-0800
+++ leptonlib-1.69/debian/liblept3.install 2012-01-09 14:24:02.0
-0800
@@ -0,0 +1 @@
+usr/lib/lib*.so.*
diff -Nru leptonlib-1.69/debian/libleptonica.dirs
leptonlib-1.69/debian/libleptonica.dirs
--- leptonlib-1.69/debian/libleptonica.dirs 2012-01-09 14:24:02.0
-0800
+++ leptonlib-1.69/debian/libleptonica.dirs 1969-12-31 16:00:00.0
-0800
@@ -1 +0,0 @@
-usr/lib
diff -Nru leptonlib-1.69/debian/libleptonica.install
leptonlib-1.69/debian/libleptonica.install
--- leptonlib-1.69/debian/libleptonica.install 2012-01-09 14:24:02.0
-0800
+++ leptonlib-1.69/debian/libleptonica.install 1969-12-31 16:00:00.0
-0800
@@ -1 +0,0 @@
-usr/lib/lib*.so.*
diff -u tesseract-3.02.01/debian/control tesseract-3.02.01/debian/control
--- tesseract-3.02.01/debian/control
+++ tesseract-3.02.01/debian/control
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Jeffrey Ratcliffe jeffrey.ratcli...@gmail.com
Uploaders: Jeff Breidenbach j...@debian.org
-Build-Depends: debhelper (= 7.0.50~), libleptonica-dev (= 1.69~), automake,
libtool
+Build-Depends: debhelper (= 7.0.50~), libleptonica-dev ( 1.69-3.),
automake, libtool
Standards-Version: 3.9.2
Homepage: http://code.google.com/p/tesseract-ocr/
@@ -32,7 +32,7 @@
Breaks: tesseract-ocr ( 3.01~), ocropus ( 0.4.0~)
Replaces: tesseract-ocr ( 3.01~)
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libleptonica (= 1.69~)
+Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Command line OCR tool
The Tesseract OCR engine was one of the top 3 engines in the 1995
UNLV Accuracy test. Between 1995 and 2006 it had little work done on
diff -u tesseract-3.02.01/debian/changelog tesseract-3.02.01/debian/changelog
--- tesseract-3.02.01/debian/changelog
+++ tesseract-3.02.01/debian/changelog
@@ -1,3 +1,31 @@
+tesseract (3.02.01-6) unstable; urgency=low
+
+ * No changes. Bumping package version to poosibly help with upload.
+
+ -- Jeff Breidenbach j...@debian.org Mon, 30 Jul 2012 16:01:21 -0700
+
+tesseract (3.02.01-5) unstable; urgency=low
+
+ * Working with Jonathan to fix mistaken extra files.
+
+ -- Jeff Breidenbach j...@debian.org Mon, 30 Jul 2012 11:38:04 -0700
Request for wheezy-ignore tag: bug#555168 (glibc locale files with license not permitting modification)
Hi release team, I've been asked to ask you whether you consider bug#555168 (many glibc locale files having a license that does not permit modification) to be something deserving a wheezy-ignore tag. I'm asking you half-heartedly, since I don't think the answer is useful. That bug sure *looks* release-critical, and it sure *looks* like something that could be delayed another release if people manage to stall long enough. Which would make it wheezy-ignore. Jonathan Context: - bug was release-critical in squeeze cycle - tagged squeeze-ignore. I can't find a note explaining the context - in the squeeze cycle there was some controversy about whether this is worth spending time on --- are these files copyrightable at all or mere collections of facts, and is the license forbidding modification intentional? - Helge has done a lot of work recently to get the files relicensed more clearly - there was an upstream discussion revealing that the upstream maintainers are not sure if these files are copyrightable at all. And on the other hand, apparently the license forbidding modification really was intentional. http://sourceware.org/PR11213#c14 - upstream folks want clarification from someone legally qualified - the SFLC which could provide legal advice would prefer to work with the Debian leadership instead of unrelated individuals - the Debian leadership (aka Stefano :)) requested that I ask you about timing - I personally would be happy if someone with a clue could give us the five-minute answer, which shouldn't require so much meta-discussion about who asks and when. Anyone have a lawyer friend? -- 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/20120801222510.GA30137@copier
Re: Next upload 2012-06-26 (dpkg 1.16.5)
Hi, Neil McGovern wrote: dpkg-1.16.8/dpkg-deb/main.c - -h|--helpShow this help message.\n - --versionShow the version.\n + -?, --help Show this help message.\n + --versionShow the version.\n Why are you removing -h? I'll leave this one for Guillem. dpkg-1.16.8/lib/dpkg/ar.c + if (strlen(name) 15) + ohshit(_(ar member name '%s' length too long), name); + if (size 99L) + ohshit(_(ar member size %jd too large), size); + Why 99? In the common ar format, the member size is stored as a 10-byte character array as a decimal integer (padded on the right with spaces). The maximum value that can be represented is 10^10 - 1 = 9 999 999 999. Now a person might worry for a moment: since log2(10) is a little more than 3.3, isn't 10^10 around 2^33, which is larger than can be represented in a long on 32-bit architectures? Luckily dpkg uses C99, where this is automatically treated as a long long literal when appropriate. dpkg-1.16.8/scripts/Dpkg/Deps.pm -(any) # architecture name +([a-zA-Z0-9][a-zA-Z0-9-]*) # architecture name Why the additional restriction? It's a loosening. Previously the only permitted architecture-qualified dependency was :any. *.gmo - are you sure you're meant to be shipping these in the tarball? I also dislike that convention, but it's what gettextized projects do by default. See http://lists.gnu.org/archive/html/autoconf/2007-08/msg00024.html Thanks, Jonathan -- 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/20120728132123.GA9715@burratino
Re: freeze exception qpdf versioned symbols?
Hi,
Jay Berkenbilt wrote:
Okay, I've attached two files here. The first is a copy of
version-symbols.patch with the real changes, so this excludes the
changes to the regenerated configure file. The second file is a source
debdiff.
I am not on the release team, so please take anything I say with a
grain of salt.
[...]
--- qpdf-2.3.1/debian/changelog 2012-05-19 09:21:52.0 -0400
+++ qpdf-2.3.1/debian/changelog 2012-07-18 10:20:10.0 -0400
@@ -1,3 +1,9 @@
+qpdf (2.3.1-5) unstable; urgency=low
+
+ * Enable versioned symbols.
Are the symbol versions used shared with upstream, or is this a
Debian-specific thing?
*checks*
Looks like these are Debian-private but the patch is based on 92c94e7d
(Add symbol versioning, 2012-06-20). Ok.
[...]
--- qpdf-2.3.1/debian/libqpdf3.shlibs 2012-04-22 10:25:08.0 -0400
+++ qpdf-2.3.1/debian/libqpdf3.shlibs 2012-07-18 10:20:43.0 -0400
@@ -1 +1 @@
-libqpdf 3 libqpdf3 (= 2.3.0)
+libqpdf 3 libqpdf3 ( 2.3.1-5~)
Makes sense, and this doesn't change the squeeze-wheezy upgrade path
because libqdf3/squeeze is already 2.3.0..
[...]
--- qpdf-2.3.1/debian/patches/versioned-symbols.patch 1969-12-31
19:00:00.0 -0500
+++ qpdf-2.3.1/debian/patches/versioned-symbols.patch 2012-07-18
10:08:30.0 -0400
@@ -0,0 +1,1044 @@
[...]
++# Check if LD supports linker scripts, and define conditional
++# HAVE_LD_VERSION_SCRIPT if so. This functionality is currently
++# constrained to compilers using GNU ld on ELF systems or systems
++# which provide an adequate emulation thereof.
++AC_ARG_ENABLE([ld-version-script],
++ AS_HELP_STRING([--enable-ld-version-script],
++[enable linker version script (default is disabled)]),
Is the default really --disable?
++[have_ld_version_script=$enableval], [have_ld_version_script=yes])
++if test $have_ld_version_script != no; then
++ AC_MSG_CHECKING([if LD -Wl,--version-script works])
++ save_LDFLAGS=$LDFLAGS
++ LDFLAGS=$LDFLAGS -Wl,--version-script=conftest.map
++ cat conftest.map EOF
++VERS_1 {
++global: sym;
[...]
+--- /dev/null1970-01-01 00:00:00.0 +
qpdf-2.3.1/libqpdf.map 2012-07-18 10:08:07.677346374 -0400
+@@ -0,0 +1,4 @@
++LIBQPDF_3 {
++ global:
++*;
++};
It would be more comforting to have a list of symbols intended for
export here, so unintentional ABI changes could be caught more easily.
Do I understand that that would be hard to make because this is a C++
library?
[...]
+--- qpdf-2.3.1.orig/configure2011-12-28 17:20:43.0 -0500
qpdf-2.3.1/configure 2012-07-18 10:08:25.257346605 -0400
+@@ -1,11 +1,9 @@
+ #! /bin/sh
+ # Guess values for system-dependent variables and create Makefiles.
+-# Generated by GNU Autoconf 2.68 for qpdf 2.3.1.
++# Generated by GNU Autoconf 2.69 for qpdf 2.3.1.
Annoying, but I guess switching to running autotools on autobuilders
can wait for wheezy+1.
To sum up: except for the help string for ./configure
--enable-ld-version-script, the patch looks correct and unrisky. It
would be nice if the changelog were more explicit about the shlibs
bump and the relationship between this and the ABI used elsewhere
(upstream and other distros).
Thanks and hope that helps,
Jonathan
--
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/20120722071518.GA4749@burratino
Re: libraptor2-0: please add a Breaks against libraptor1 versions without symbol versioning
In January, Jonathan Nieder wrote:
Adrian Knoth wrote:
The situation is as follows:
- ardour depends on liblrdf (mind the l after lib)
- liblrdf depends on libraptor1
- ardour depends on libslv2
- libslv2 depends on librdf0 (no l this time)
- librdf0 (= 1.0.13-1) depends on libraptor2
And there you have it, clashing symbols.
The solution is to add symbol versioning to both raptor libraries, then
recompile librdf, liblrdf and afterwards libslv2 (the whole dependency
chain backwards). In the end, recompile ardour.
Is that last step (in the end, recompile ardour) needed?
I'm asking because if it is, this will break partial upgrades from
squeeze. If it isn't, it should be enough for the updated librdf0 to
gain a (direct or indirect) Breaks against versions of libraptor1 that
lack versioned symbols, to ensure the correct upgrade order.
That is, probably libraptor2-0 should Breaks: libraptor1 ( 1.4.21-3).
How about this patch?
Ping. The patch below should be risk-free and should ensure upgrades
actually work. Any fixes needed before it is ready to be applied?
Thanks,
Jonathan
---
debian/changelog |7 +++
debian/control |1 +
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index c48a8a87..37a940cc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+raptor2 (2.0.6-1.1) local; urgency=low
+
+ * debian/control: add a breaks relation by libraptor2-0 against squeeze
+libraptor1 to force upgrades to a version with symbol versioning
+
+ -- Jonathan Nieder jrnie...@gmail.com Sun, 22 Jan 2012 16:39:45 -0600
+
raptor2 (2.0.6-1) unstable; urgency=low
* New upstream release
diff --git a/debian/control b/debian/control
index 8d758eeb..abe13400 100644
--- a/debian/control
+++ b/debian/control
@@ -21,6 +21,7 @@ Package: libraptor2-0
Section: libs
Architecture: any
Depends: ${misc:Depends}, ${shlibs:Depends}
+Breaks: libraptor1 ( 1.4.21-3)
Suggests: raptor2-utils
Description: Raptor 2 RDF syntax library
Raptor is a C library providing a set of parsers and serializers for
--
1.7.9.rc2
--
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/20120720223434.GA7056@burratino
Re: coreutils: please update translations
Hi, In May, Jonathan Nieder wrote: As a test that I have locales set up correctly, I tried ls --help: | $ LANG=de_DE.UTF-8 ls --help | Aufruf: ls [OPTION]... [DATEI]... | List information about the FILEs (the current directory by default). | Sort entries alphabetically if none of -cftuvSUX nor --sort is specified. | | Erforderliche Argumente für lange Optionen sind auch für kurze erforderlich. | -a, --all Einträge, die mit . beginnen, nicht verstecken Notice the English-language text at the beginning. But this is translated in [1] (last updated 2011-10-14). [...] So let's fetch them with [...] The result: the languages da de es fr vi seem to have updates not included in the package. Patch attached. [...] debian/changelog |8 + debian/patches/00list|1 + debian/patches/50_update_translations.dpatch |25169 ++ debian/rules |2 + 4 files changed, 25180 insertions(+) create mode 100755 debian/patches/50_update_translations.dpatch Ping. Is this this patch[1] suitable for wheezy? Independently of that, is there anything I can do to help get this at least fixed in unstable? In suspense, Jonathan [1] http://bugs.debian.org/671807#5 -- 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/20120720224126.GA7397@burratino
Bug#680674: transition: leptonlib
tags 680674 + pending quit Julien Cristau wrote: On Wed, Jul 18, 2012 at 18:13:12 -0500, Jonathan Nieder wrote: Julien Cristau wrote: Agreed. Either this happens or leptonlib and friends get removed from wheezy, IMO. Thanks for looking it over. Is that a please go ahead or a yes, this is the right thing to do when the moment is right? The former. (No guarantees that it'll get into wheezy, but the chances of leptonlib releasing with wheezy are much higher if it's not rc buggy, so...) Uploaded. FTP team: you might have noticed leptonlib entering NEW. I would be happy if it can enter unstable (as quoted above, the release team has given the ok). See http://bugs.debian.org/680674 for details. Thanks, Jonathan -- 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/20120721002845.GA20970@burratino
Bug#681332: debian-cd BoF at DebConf
Hi, Cyril Brulebois wrote: dpkg's current diff between testing and unstable, once *.po and *.gmo stripped is: 323 files changed, 7307 insertions(+), 4626 deletions(-) There's #681332 about that, which was left unanswered. Dpkg development has been happening pretty quickly lately, so there are a lot of changes between the versions in wheezy and sid. * Version number bumped * Translation updates: sv de fr ja ca it sk es zh_TW ru pl da eo * Documentation improvements: deb(5) deb-src-control(5) * Bugfixes: #652970 3.0 (quilt): More graceful reporting of and recovery from patch application errors dpkg-source --commit: Clean up on failure. dpkg-parsechangelog: Correct capitalization of fields when reporting errors. #677631 dpkg-source: Avoid warning noise when HOME is unset. (non-Debian) Add a dummy symbol to libcompat so unpleasant toolchains can still cope with it. #678933 Error out instead of writing an invalid ar file when member name or size is too large #640676 dpkg-shlibdeps: Report bogus Build-Depends using a sane message instead of a use of undefined value warning. #679641 dpkg: Use SELinux raw context API to avoid relying on the mcstransd daemon during unpack. * Features: 3.0 (quilt): When regenerating the automatic patch, keep comments leading up to the patch from the old version, since they might contain useful information. dpkg-source --commit: Automatically add modified binary files to debian/source/include-binaries. #643043 dpkg-source learns --no-unapply-patches. #664058 dpkg-buildflags learns --status. #440094 Add support for binary-only changelog field and use it to detect source version (though the old heuristic of detecting +bnum is still supported, too). #675333 dpkg-source -b: Take architecture wildcards into account when removing repeated arches in the resulting source control and changes files. #627333 start-stop-daemon learns --no-close. dpkg-query learns --control-list and --control-show. #679010 update-alternatives --query, --config have more useful output. #621763 Buffer I/O errors and errors in the dpkg-query --show format argument are reported more cleanly. #624000 Avoid full stop and double newline at the end of errors and warnings Change short name for --help to -? instead of -h. dpkg-mergechangelogs --help output is more consistent with other commands. #676232 Add support for Architecture-qualified dependencies like Depends: libc6:amd64 (= 2.14) #558095 Add support for :native syntax for Build-Depends. #673190 dpkg-query -l adds an Architecture column. More consistently uses US English spelling in documentation and error messages. * Cleanup: Dpkg::Source::Functions::is_binary(): Don't clobber $_. Dpkg::Source::Package::V2: Make binary file handling into a dedicated BinaryFiles class. New Dpkg::Source::Quilt module, split off from Dpkg::Source::Package::V3::quilt. Dpkg::Control::Fields: Remove obsolete changelog fields Timestamp, Header, Items, Trailer, Urgency_comment, Urgency_lc from field order. Use new notice() function (which takes care of the program name and trailing newline, making the list of translated strings saner) for notices to stderr instead of using fprintf directly. * Packaging: Source package compression switched to xz. -- 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/20120721011232.GB20970@burratino
Bug#680674: transition: leptonlib
Julien Cristau wrote: Agreed. Either this happens or leptonlib and friends get removed from wheezy, IMO. Thanks for looking it over. Is that a please go ahead or a yes, this is the right thing to do when the moment is right? I can see at least two options: a. Upload [1] right away to fix leptonlib bugs #681570 and #681574 without starting a transition. This makes fixing tesseract bug #680598 (hardcoded library dependency) possible using the patch in that bug log, which would make any future transitions easier. Finally, when the release team gives the signal, upload leptonlib with the corrected package name (fixing bug#664176). The transition should be smooth --- all it would take is a tesseract binnmu. b. Wait for release team signal, and then upload leptonlib with the corrected package name, which automatically fixes all three of its RC bugs. Upload the fix to tesseract bug #680598 from the bug log at the same time (the Build-Depends ensures appropriate build ordering) to bring about the transition. c. Something that does not involve fixing bug#664176 (package name not varying with soname) My preference is (b), but (a) or (c) is fine, too. Jonathan [1] http://alioth.debian.org/~jrnieder-guest/temp/leptonlib_1.69-3.1.dsc -- 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/20120718231312.GC13423@burratino
Bug#680674: transition: leptonlib
Cyril Brulebois wrote: Jonathan Nieder jrnie...@gmail.com (07/07/2012): 1. Upgrading libleptonica causes liblept.so.1 to be removed, breaking leptonica-progs and tesseract-ocr from squeeze, but this dependency is not declared. Add Breaks: accordingly. Can't hurt, so I'll file a bug with patch for this and ask for an upload. Then it's up to you and time whether #664176 should be wheezy-ignore. [...] Optionally fix shlibs accordingly. If I read it right, we have the following Depends: tesseract-ocr → libtesseract3 → libleptonica (= 1.69~) So the versioning against libleptonica is already there, and we wouldn't gain anything in rebuilding src:tesseract after that. Correct? Correct. Thanks for your attention to detail. Ciao, Jonathan -- 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/20120714100712.GG3693@burratino
Re: need the latest version for 2012 tax declaration
Version: 0.18-1 Toni Mueller wrote: On Fri, Jul 13, 2012 at 10:16:38AM -0500, Jonathan Nieder wrote: Toni Mueller wrote: I only discovered today that closing the bug was premature, and the wrong way to go. I don't follow. Does 0.18-1 not fix the bug? it does. I have probably made a mistake, though, but I wanted to have this package flow into Wheezy, when it appeared to be stuck in unstable. That's why I thought that the bug should be open, instead of closed. Can you please make it go into Wheezy? Ok, thanks. As long as the bug is not fixed in the version in wheezy, it will block the release. Closing it actually helps because it lets the release team know that there is a fixed version. At [1] I see that the updated package is missing binaries on some architectures: out of date on i386: taxbird (from 0.16-0.2) out of date on armel: taxbird (from 0.16-0.2) out of date on armhf: taxbird (from 0.16-0.2) out of date on powerpc: taxbird (from 0.16-0.2) out of date on sparc: taxbird (from 0.16-0.2) At [2] we see the underlying problem --- the package fails to build from source: http://bugs.debian.org/656505 Once an upload fixes that bug and the autobuilders have had time to build it, the package would presumably migrate to wheezy. Perhaps you know someone who could upload the fix from http://stuff.der-marv.de/debian/taxbird/0.18-2/ ? Thanks and hope that helps, Jonathan [1] http://packages.qa.debian.org/t/taxbird.html [2] https://buildd.debian.org/status/package.php?p=taxbird -- 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/20120713162236.GB28895@burratino
Re: need the latest version for 2012 tax declaration
Toni Mueller wrote: On Fri, Jul 13, 2012 at 11:22:37AM -0500, Jonathan Nieder wrote: Ok, thanks. As long as the bug is not fixed in the version in wheezy, it will block the release. ok. I thought it would simply be chucked out, or Yep, that's another possible outcome. I should have said, As long as the bug is not fixed in the version in wheezy, it will block the release or the package will be removed from the release. Thanks for a useful clarification. Jonathan -- 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/20120713165922.GD28895@burratino
Re: BinNMU changelog handling for Multi-Arch: same packages
Hi Raphael, Raphael Hertzog wrote: I know that in the long term you're in favor of moving the changelog in the package metadata and I agree with this plan. But IMO we must find an interim solution in the mean time. Here's a suggestion. Please share your thoughts: 1/ we modify dh_installchangelog to strip the binary-only changelog entry for Multi-Arch: same packages [...] 2/ we modify dpkg to allow co-installation of M-A: same packages which share the same source version regardless of the binary version 3/ we modify sbuild to add the required binary-only=yes in the binNMU changelog entries. Here's a sample header line: ftplib (3.1-1-9+b1) unstable; urgency=low, binary-only=yes (2) and (3) sound like very good things. Wouldn't (1) be throwing away information, unless the stripped information goes into another file? Making the stripped info go into another file sounds fine to me. A crazier possibility is teaching the unpack procedure to treat /usr/share/doc/package/changelog.Debian.gz specially, collecting the binary-only changelog entries and merging them in a single file, but that's a pretty severe layering violation and it would not be easy to find which entries are no longer relevant when shrinking the set of installed arches for a package. Thanks, Jonathan -- 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/20120711073537.GA2006@burratino
Bug#680674: transition: leptonlib
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Tags: wheezy X-Debbugs-Cc: lepton...@packages.debian.org, tesser...@packages.debian.org Hi release team, This is a request to start a small transition for wheezy. Please don't shoot me. The current leptonlib packaging ships liblept.so.3 in a package with the same name (libleptonica) as the package shipping liblept.so.1 in squeeze. That is problematic for a few reasons: 1. Upgrading libleptonica causes liblept.so.1 to be removed, breaking leptonica-progs and tesseract-ocr from squeeze, but this dependency is not declared. 2. tesseract-ocr from wheezy requires liblept.so.3, but libleptonica's shlibs file doesn't create an appropriate dependency for that. So a versioned dependency on libleptonica was hardcoded in 3.02.01-4, which will only make for trouble in future library transitions. 3. There is no reason not to allow liblept.so.1 and liblept.so.3 to be installed at the same time for a smoother upgrade, but using the same package name prevents that (policy §8.1). Therefore I would like to see libleptonica renamed to liblept3 in wheezy, so the usual shlibs and upgrade mechanisms can Just Work™. leptonlib has one reverse dependency: tesseract. That means a tiny transition: 1. fix the package name in leptonlib (bug#664176) 2. fix the hardcoded dependency in tesseract and rebuild against new leptonlib (bug#680598) 3. let both migrate to wheezy Ben file: title = leptonlib; is_affected = .depends ~ libleptonica | .depends ~ liblept3; is_good = .depends ~ liblept3; is_bad = .depends ~ libleptonica; I realize this is very late, but I think it's important, hence the request. If there's some better way to go about this, I'd be happy to hear about it. Other thoughts welcome, too. Thanks for your work, Jonathan -- 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/20120707223645.GA3391@burratino
Re: Seasonal dilemna with EMBOSS.
Hi Charles, Charles Plessy wrote: For Wheezy, we have the following choice: - Release with 6.4.0, which will be unsupported upstream on July 15th, 2012. - Give an exception to 6.5.0, which will be unsupported on July 15th, 2013. I encourage you to package a pre-release or snapshot of what will become 6.5.0 for unstable if you think that will be easier to maintain in the period wheezy is supported. Then the update to move to the official release after the freeze would be much smaller. Of course, please coordinate with the release team if this involves a transition. Thanks and hope that helps, Jonathan -- 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/20120624074301.GA4003@burratino
Bug#678624: pu: package xz-utils/5.0.0-3
| 36 ++
debian/patches/xzgrep-ignore-SIGPIPE | 36 ++
15 files changed, 867 insertions(+)
Debdiff attached. What do you think?
Thanks,
Jonathan
diff -Nru xz-utils-5.0.0/debian/changelog xz-utils-5.0.0/debian/changelog
--- xz-utils-5.0.0/debian/changelog 2010-11-11 13:45:21.0 -0600
+++ xz-utils-5.0.0/debian/changelog 2012-06-23 04:47:22.0 -0500
@@ -1,3 +1,53 @@
+xz-utils (5.0.0-3) stable; urgency=low
+
+ * Fixes from upstream:
+* liblzma:
+ - lzma_easy_buffer_encode() and lzma_stream_buffer_encode()
+avoid writing Blocks with empty compressed data that xz and
+liblzma versions before 5.0.2 cannot read.
+ - The LZMA2 decoder skips Blocks with empty compressed data
+instead of rejecting them.
+ - Validates encoder arguments better. It is harder to segfault
+or create a corrupt XZ file instead of receiving an error
+when calling these functions:
+- lzma_stream_buffer_encode() and lzma_block_buffer_encode()
+ reject unsupported integrity checks;
+- lzma_block_encoder() checks for block == NULL.
+ - bcj: Fix possibility of incorrect LZMA_BUF_ERROR (reported in
+XZ Embedded as Fedora bug 735408).
+ - Plugs a memory leak in lzma_stream_encoder().
+ - lzma_index_init() returns NULL instead of segfaulting on
+allocation failure.
+* docs/examples/xz_pipe_decompress.c checks that the last
+ lzma_code() call returned LZMA_STREAM_END to avoid mistaking a
+ file without a proper footer for a valid XZ file.
+* xz -v -v --list does not free() filter options unless the
+ filter options array has been initialized. This prevents
+ reading and free()ing pointers from past the end of an on-stack
+ array when one of the listed files has an unmeaningful Block
+ header size.
+* xzegrep and xzfgrep perform extended regex and fixed-string
+ matches, respectively. (The previous behavior was to always
+ use basic regexes.)
+* The exit status from “xzdiff foo.xz bar.xz” reflects whether
+ files differ. Thanks to Peter Pallinger. Closes: #635501.
+* xzgrep does not fail just because the decompressor has died
+ with SIGPIPE due to some unconsumed output. This makes the
+ exit status from commands such as xzgrep -q more predictable.
+* The Czech “xz --help” output uses a more correct term for files
+ with holes. Thanks to Petr Hubený. Closes: #605762.
+* The Italian diagnostic for an invalid --format argument lost an
+ extra 'N'.
+ * debian/rules: chmod +x tests/test_scripts.sh for new xzdiff
+tests.
+ * debian/symbols: Bump the minimal versions for LZMA2 encoder
+functions that reject more bad arguments and skip empty blocks.
+ * liblzma-dev: Install an appropriate library for static linking
+instead of the decompression-only version used to build xzdec.
+Thanks to Anton Tolchanov. Closes: #673001.
+
+ -- Jonathan Nieder jrnie...@gmail.com Sat, 23 Jun 2012 04:47:21 -0500
+
xz-utils (5.0.0-2) unstable; urgency=low
* Upload to unstable.
diff -Nru xz-utils-5.0.0/debian/examples/xz_pipe_decomp.c
xz-utils-5.0.0/debian/examples/xz_pipe_decomp.c
--- xz-utils-5.0.0/debian/examples/xz_pipe_decomp.c 2010-11-11
13:48:59.0 -0600
+++ xz-utils-5.0.0/debian/examples/xz_pipe_decomp.c 2012-06-23
03:24:34.0 -0500
@@ -1,7 +1,7 @@
/*
* xz_pipe_decomp.c
* A simple example of pipe-only xz decompressor implementation.
- * version: 2010-07-12 - by Daniel Mealha Cabrita
+ * version: 2012-06-14 - by Daniel Mealha Cabrita
* Not copyrighted -- provided to the public domain.
*
* Compiling:
@@ -101,6 +101,14 @@
} while (strm.avail_out == 0);
}
+ /* Bug fix (2012-06-14): If no errors were detected, check
+ that the last lzma_code() call returned LZMA_STREAM_END.
+ If not, the file is probably truncated. */
+ if ((ret == RET_OK) (ret_xz != LZMA_STREAM_END)) {
+ fprintf (stderr, Input truncated or corrupt\n);
+ ret = RET_ERROR_DECOMPRESSION;
+ }
+
lzma_end (strm);
return ret;
}
diff -Nru xz-utils-5.0.0/debian/patches/bcj-flush-to-empty-buffer
xz-utils-5.0.0/debian/patches/bcj-flush-to-empty-buffer
--- xz-utils-5.0.0/debian/patches/bcj-flush-to-empty-buffer 1969-12-31
18:00:00.0 -0600
+++ xz-utils-5.0.0/debian/patches/bcj-flush-to-empty-buffer 2012-06-23
02:48:47.0 -0500
@@ -0,0 +1,190 @@
+From: Lasse Collin lasse.col...@tukaani.org
+Date: Mon, 28 May 2012 20:42:11 +0300
+Subject: liblzma: Fix possibility of incorrect LZMA_BUF_ERROR.
+
+lzma_code() could incorrectly return LZMA_BUF_ERROR if
+all of the following was true:
+
+ - The caller knows how many bytes of output to expect
+and only provides that much output space.
+
+ - When the last output bytes are decoded, the
+caller-provided input buffer ends right
Re: zlib1g: binNMU broke multi-arch installability
Hi, Mark Brown wrote: On Tue, Jun 19, 2012 at 08:13:06PM +0200, Nicolas Le Cam wrote: Recent binNMU of zlib1g on amd64 made it impossible to co-install it in a multi-arch environment. What makes you say this, and why are you filing a bug on the package? Please provide a description of whatever problem you think you are seeing and contact the release team (who are responsible for binnmus). He's probably asking you to work around [1] by making a sourceful upload at some time before the next release. Doing that every time there is a binnmu sounds like a lot of work and I think that it would be better to either solve the problem systematically (by finding a way to make the changelogs the same on all arches, for example by putting notes on the build somewhere else) or to leave it unsolved with some text in the release notes to help users take care of it. Hope that helps, Jonathan [1] After a binnmu, the version numbers and changelogs don't match so dpkg refuses to install a package for both architectures at the same time. https://lists.debian.org/debian-release/2012/06/msg00253.html -- 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/20120619183608.GA19684@burratino
Re: Handling of changelogs and bin-nmus
Raphael Hertzog wrote:
As such, I suggest that we handle binary rebuild differently:
- debian/changelog is left unmodified since it's the source changelog
= it defines the ${source:Version} substvar
- debian/changelog.binary-rebuild (or any other better name) is created
when we want to do a bin-nmu
= it defines the ${binary:Version} and it's not included in
the generated source package
Sounds good to me. Where would the binary changelog entry and binary
version be stored in the resulting binary package?
--
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/20120610171456.GB32613@burratino
Re: Alpha version of xz-utils in wheezy?
Hi Andrew, Andrew Pollock wrote: I just noticed that the version of xz-utils in wheezy is 5.1.1alpha+20110809-3 The xz-utils package in sid has been tracking the 5.1.y series for a long time. Unfortunately there hasn't been an official stable release from that branch. From upstream's website: Development The new APIs, command line options etc. in development releases should be considered unstable. Incompatible changes to unstable features may be done before they get included in a stable release. Upstream's comment on this was: I sound like going between opinions, but it doesn't seem to make a huge *technical* difference if Wheezy's xz says 5.1.1alpha or 5.0.4. Showing alpha can scare some users though. The new things in 5.1 are: - --single-stream - --block-size=SIZE - .lzo support in scripts - Required xz version in --robot -lvv output I think I can keep those stable (enough;-) interface wise. So you don't need to worry about that. The other important difference between 5.0.y and 5.1.y is threading support, but there is a patch removing that in wheezy and sid. I am strongly against moving back to 5.0.4. Hope that helps, Jonathan -- 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/20120601222916.GB8409@burratino
Re: binutils-gold breaks ghc linking stage
Julien Cristau wrote: What's the rationale for this bug being 'serious' in the first place? That seems rather inflated to me. ghc is unusable when binutils-gold is installed. There is no conflict between them declared. -- 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/20120528170635.GA14606@burratino
Bug#650601: libpng12-0 in experimental breaks its rdeps
# warning users of apt-listbugs, to reduce noise # luckily this only affects the package experimental, so this # severity bump should have no effect on testing migration etc severity 673542 serious quit Hi, Aníbal Monsalve Salazar wrote: severity 673542 important [...] The libpng transition hasn't started yet. Please refer to the webpage above. It will involve hundreds of binary packages. $ vim vim: /usr/lib/i386-linux-gnu/libpng12.so.0: version `PNG12_0' not found (required by /usr/lib/i386-linux-gnu/libcairo.so.2) Regardless of whether the transition has started, doesn't this kind of thing (removal of symbol versions) require a soname bump? Thanks for your work, Jonathan -- 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/20120521121534.GA25635@burratino
Re: binutils-gold breaks ghc linking stage
Dear release team, Joachim Breitner wrote[1]: I’d rather like to be able to transition the current set of Haskell packages to testing first and then, if there is time before the freeze, tackle this bug. For that, the severity needs to be lowered, though, as otherwise nothing will migrate. I believe this is a reasonable request, but that playing with severities is not the right way to bring it about. Could you please make the appropriate hints (and consider whether this should be wheezy-ignore while at it)? Thanks, Jonathan [1] http://bugs.debian.org/673081 -- 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/20120517214721.GA2967@burratino
Bug#670858: RM: node/0.3.2-7.1
Package: release.debian.org User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: n...@packages.debian.org Hi, Please remove the ham radio server node from testing. The release-critical bug #614907 has had no action for several months despite a starting patch and various compromises offered, and I am not confident that the bug will be fixed in time for wheezy. The package hasn't been uploaded for the past two years. It would be dishonest to commit to maintaining this package for the course of another stable release if it remains in this state. I hope that this removal would be temporary and it would not remain in this state, though. If you have any questions, feel free to ask. Thanks, Jonathan -- 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/20120429182732.GA27437@burratino
Bug#670461: release.debian.org: Including eclipse/3.8 in Wheezy
Hi Niels, Niels Thykier wrote: Jakub Adam (CC'ed) and I have been looking at including Eclipse 3.8 (Juno) in Wheezy. The release date for Eclipse 3.8 is the 27th of June, which is probably after we freeze in June. We believe that this should be doable from our PoV I'd suggest uploading a prerelease to sid at some appropriate moment to prepare for this, coordinating with the release team if a transition is involved. Thanks for the heads up, Jonathan -- 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/20120425225130.GA7544@burratino
Re: Bug#660034: transition: libvpx
(dropping cc to avoid cluttering the bug log) Cyril Brulebois wrote: libvpx being built and installed everywhere, I've just scheduled binNMUs for the following packages: chromium-browser gst-plugins-bad0.10 icedove sludge. Hopefully the libvpx+x264 transitions will be ready in a few days. It would be nice if the maintainers of the above-mentioned packages could avoid uploading new versions in the meanwhile. Thanks much. The heads up is nice. -- 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/20120216094938.GA31212@burratino
Re: taxbird: Version for 2011 available upstream
(cc-ing release team for a strange release management question) Hi, Marc Haber wrote: Taxbird is a program that is used to file Umsatzsteuervoranmeldungen, a tax issue which needs to be done with current software. Raising severity to release critical as taxbird 0.15 is useless. Would it be feasible to address this somehow in stable? Please forgive my ignorance. Thanks, Jonathan -- 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/20120201183809.GA27987@burratino
Re: taxbird: Version for 2011 available upstream
Philipp Kern wrote: On Wed, Feb 01, 2012 at 12:38:09PM -0600, Jonathan Nieder wrote: Would it be feasible to address this somehow in stable? Please forgive my ignorance. I presume that we're talking not only about taxbird but also libgeier? Yes, I believe so. -- 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/20120201194023.GC28375@burratino
Bug#652650: imagemagick transition: any news ?
Hi, Vincent Fourmond wrote: is there be anything specific that prevents us from uploading the current imagemagick in experimental to unstable ? Yes, the lack of release team ack usually indicates that they are busy working on other transitions. See http://bugs.debian.org/release.debian.org or http://release.debian.org/transitions/ for some details on those. If you would like to help them: - Have you checked that the rdeps build without trouble against the new version? - Do you know if there are any overlaps with other pending or scheduled transitions? Just my two cents as a naive developer/user, Jonathan -- 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/20120126123227.GA6579@burratino
Bug#654237: Processed: relevant bugs for libav transition
unblock 654237 by 654230 641508 651625 652763 652061 quit Hi Reinhard, Reinhard Tartler wrote: Are these bugs really blocking the upload of libav 0.8? I am not the release team, but probably no. Once there are only a few left, the release team might signal that it is a convenient enough time to upload and they can be fixed afterward. And some packages can be temporarily removed from testing to avoid slowing a transition down too much. Plus I was too lazy of a reader to notice that libav 0.8 is ABI-compatible with libav 0.7, making this way easier than a typical transition (so the random RC bugs are not actually relevant; only the ftbfs bugs might be). Actually I am not sure why this is called a transition at all. Thanks, Jonathan -- 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/20120103160534.ga21...@elie.hsd1.il.comcast.net
Bug#630201: [kfreebsd-*] please rebuild elfutils/sid, ignoring the 2 known testsuite failures (Re: transition: liblzma 5)
Julien Cristau wrote: On Wed, Oct 26, 2011 at 12:01:41 +0200, Julien Cristau wrote: libdw1 (DWARF parser for elfutils) FTBFS on kfreebsd, needs a bug filed. Apparently that's #570805 (thanks, Jakub). That's a pair of testsuite failures due to a kernel bug and not a regression in elfutils as far as I can tell. kfreebsd buildd admins, is it possible to schedule a rebuild with DEB_BUILD_OPTIONS=nocheck, or would it be better to request that directly in debian/rules as a temporary workaround? (Please forgive my ignorance.) Thanks, Jonathan -- 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/20111029071224.gc8...@elie.hsd1.il.comcast.net
Bug#630201: RFS: xz-utils (updated package)
Hi, I am looking to upload the new version 5.1.1alpha+20110809-3 of my package xz-utils to unstable. It builds these binary packages: xz-utils- high compression-ratio compressor xz-lzma - LZMA Utils compatibility commands xzdec - tiny decompressors liblzma-dev - development library liblzma-doc - doxygen-generated reference documentation liblzma5- runtime library The package can be found on alioth.debian.org: - http://alioth.debian.org/~jrnieder-guest/temp/xz-utils_5.1.1alpha+20110809-3.dsc - git://git.debian.org/collab-maint/xz.git master The purpose of this upload is to bump soname to 5 and match upstream's ABI for liblzma (no other changes). This includes introducing symbol versioning. These changes have been cooking in one form or another since a little before squeeze was released. I have tested the package and it works well. Of course I'm also happy to deal promptly with any fallout. Julien Cristau wrote[1]: I think this should be ok at this point, feel free to upload to sid. Mohammed Adnène Trojette wrote: Woops, totally forgot to do it this week-end. I won't be able to do it before the week-end. If you don't find any sponsor by saturday, please remind me of it :-( So I am relying on you, dear mentors. Thoughts? Jonathan [1] http://bugs.debian.org/630201 -- 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/20111018044907.ga12...@elie.hsd1.il.comcast.net
Bug#630201: [sponsoring] xz-utils update
Julien Cristau wrote: On Thu, Oct 6, 2011 at 22:15:09 +0200, Julien Cristau wrote: I think this should be ok at this point, feel free to upload to sid. Thanks for bearing with us for this long... Ping, Jonathan? Sorry for the slow response. Mohammed, I'd like to propose xz-utils 5.1.1alpha+20110809-3 for upload to unstable. Relative to the version currently in sid and testing, it bumps ABI (to liblzma5), nothing else. Hopefully it can have a speedy journey to testing, and the changes to manage /usr/bin/lzma through the alternatives system can visit sid after that. The package can be found at git://git.debian.org/collab-maint/xz.git master (commit 3e157d0) http://alioth.debian.org/~jrnieder-guest/temp/xz-utils_5.1.1alpha+20110809-3.dsc Thoughts of all kinds welcome, of course. -- 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/20111015043848.ga10...@elie.hsd1.il.comcast.net
Bug#637840: proposed upload: package git/1:1.7.2.5-3
Hi Gerrit et al, I'd therefore like to propose git://repo.or.cz/git/debian/jrn.git debian-stable aka git://git.debian.org/~jrnieder-guest/git.git debian-stable (commit 011ee3d5) for upload to stable. It fixes a few bugs: - off-by-one in commit message parsing (not filed in BTS) - Bug#609405: TCP quiet period preventing git-daemon from restarting with connections active or recently closed - Bug#627314: postrm purge not killing the logging process when there are connections active, resulting in deluser and hence the maintainer script failing - Bug#607346: server-side deadlock serving shallow clones - various documentation fixes The release team looked it over and found it ok[1]. Source package: http://alioth.debian.org/~jrnieder-guest/temp/git/git_1.7.2.5-3.dsc Thoughts welcome, as always. Thanks, Jonathan [1] http://bugs.debian.org/637840 -- 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/20110920153215.GC12316@elie
Bug#637840: pu: package git/1:1.7.2.5-3
Adam D. Barratt wrote: On Sun, 2011-08-14 at 19:33 -0500, Jonathan Nieder wrote: - fast-import: accept no-op feature notes command for frontends use to declare they require an importer able to write notes. [...] I did think hmmm at this change, yeah. Am I correct that the current behaviour is that the import simply fails, and leaves the tree in an indeterminate state? Nah, the current behavior is even more benign than that. The version of git in squeeze already knows how to write notes but thinks it doesn't know. So if a frontend writes feature notes at the beginning of a stream, then git fast-import from squeeze will simply error out, no damage done. I just looked over the other updates going into squeeze for the next point release, and this change definitely looks out of place. Let's drop it. 3. git-daemon-run.postrm purge: always terminate logging process more aggressively so the logging user can be removed and the package purged when a connection is active (also thanks to dkg, Bug#627314). What's the effect on the process using the connection when it's forcibly terminated? Lost log data? During an active connection the pipeline looks like this: helper (e.g., git upload-pack) -- git daemon -- svlogd git daemon is responsible for prepending the process ID to each line so concurrent connections can be distinguished in the log. When git-daemon-run.postrm calls sv force-shutdown .../git-daemon, the logging process immediately closes its standard input. The first message the helper writes afterwards causes the git daemon process to die with SIGPIPE and in particular to close its pipe to the helper. The second message the helper logs causes it to die with SIGPIPE. In the normal case, the helper has already written everything it wanted to, so it will just finish normally. So errors after the sv force-shutdown call are already not being logged. What this patch does is to kill the logging process, too (so deluser can delete the gitlog user later in postrm instead of erroring out). But svlogd is not doing anything useful at that point anyway. Thanks for a helpful review. Regards, Jonathan -- 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/20110917185359.GA2271@elie
Re: Processed: Re: pu: package tzdata/2011h-0lenny1
Adam D. Barratt wrote: tags 638891 - pending thanks On Fri, 2011-08-26 at 23:51 +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: # http://release.debian.org/proposed-updates/oldstable.html tags 638891 + lenny pending That page doesn't include the version you marked as pending... Yikes, I don't know why I thought it did. Thanks for catching it. -- 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/20110827071053.gb7...@elie.gateway.2wire.net
Bug#630251: patch for proposed updates / rdesktop sometimes fails to transfer files from win2k8
clone 630251 -1 retitle -1 rdesktop: value for CallerAvailableAllocationUnits from FileFsFullSizeInformation is too high reassign -1 rdesktop 1.7.0-1 tags -1 = upstream quit Hi Laszlo, Laszlo Boszormenyi wrote: On Mon, 2011-06-13 at 20:48 +0100, Adam D. Barratt wrote: This is nearly, but not quite, the same as the corresponding code in the current rdesktop package in unstable. Other than the printf(), the difference is that where the proposed fix has: [...] + out_uint32_le(out, stat_fs.f_bavail); /* CallerAvailableAllocationUnits */ [...] the package in unstable has: [...] out_uint32_le(out, stat_fs.f_blocks); /* Caller allocation units low */ [...] IMHO the former one is the correct, the changes in unstable seem to have a copypaste bug. stat_fs.f_blocks may has nothing to do with 'caller allocation units low'. Will ask upstream soon. FWIW I also suspect that Jean-Michel's patch was correct and the patch applied upstream contains a typo. disk.c in the upstream svn repo looks the same as sid. Cloning to track this. -- 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/2011082623.ga3...@elie.gateway.2wire.net
Bug#636630: pu: package clive/2.2.13-5+squeeze3
tags 636630 + pending quit Ansgar Burchardt wrote: Uploaded. Thanks :) And accepted, according to http://release.debian.org/proposed-updates/stable.html. -- 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/20110826231740.ga22...@elie.gateway.2wire.net
Bug#637114: pu: package grub2/1.98+20100804-15
reopen 610184 quit Hi, Robert Millan wrote: I had a look at those two bugs: #601974 is indeed fixed in unstable, it wasn't closed in changelog because the fix was applied directly to upstream (and included with 1.99-1 upload). I've closed that bug and put everyone involved on CC. #610184 might not be fixed in unstable according to this report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610184#64 . Given the situation I wouldn't include it in this proposed update. Thanks. Do you have an updated patch for review? Jonathan Adam, you didn't mention #609804 in your mail. Is that one ok? -- 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/20110826233045.ga26...@elie.gateway.2wire.net
Bug#637840: pu: package git/1:1.7.2.5-3
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: squeeze Hi, A few updates have collected on git's debian-stable branch. 1. Upstream's maint-1.7.2 branch gets very few changes, but there have been a few since 1.7.2.5 was released: - fix off-by-one bug that makes git read past the end of a buffer when extracting the first line from an empty commit message (and include an extra line when the first line is blank) - two typo fixes and one clarification in documentation - fast-import: accept no-op feature notes command for frontends use to declare they require an importer able to write notes. Of those, the fast-import change probably seems iffy (since it does not fix a critical bug) but I would prefer to include it to match upstream. 2. git-daemon/run: use SO_REUSEADDR to allow restarting the service with connections active or recently closed (thanks to Daniel Kahn Gillmor). Bug#609405 has details. 3. git-daemon-run.postrm purge: always terminate logging process more aggressively so the logging user can be removed and the package purged when a connection is active (also thanks to dkg, Bug#627314). 4. Fixes a server-side deadlock when performing a shallow clones that people had been running into on git.sv.gnu.org (see [1], [2]). The motivation is mainly that fourth change (preventing shallow clones from hanging). These changes have been in sid for at least two months, wheezy for a month and a half. debdiff attached, or see http://repo.or.cz/w/git/debian/jrn.git/commitdiff/debian-stable?hp=debian-1.7.2.5-2 Diffstat: debian/diff/0034-revert-fix-off-by-one-read-when-searching-the-end-of-.diff | 71 +++ debian/diff/0035-revert-refactor-code-to-find-commit-subject-in-find_c.diff | 95 + debian/diff/0036-revert-rename-variables-related-to-subject-in-get_mes.diff | 57 + debian/diff/0037-bisect-use-find_commit_subject-instead-of-custom-code.diff | 48 debian/diff/0038-merge-recursive-use-find_commit_subject-instead-of-cu.diff | 42 debian/diff/0039-blame-use-find_commit_subject-instead-of-custom-code.diff | 59 + debian/diff/0040-Documentation-git-archive-spell-worktree-attributes-c.diff | 38 +++ debian/diff/0041-Documentation-githooks-post-rewrite-copy-notes-never-.diff | 42 debian/diff/0042-fast-import-clarify-documentation-of-feature-command.diff | 79 +++ debian/diff/0043-fast-import-introduce-feature-notes-command.diff | 85 debian/diff/0044-upload-pack-start-pack-objects-before-async-rev-list.diff | 99 ++ debian/changelog| 21 ++ debian/git-daemon-run.postrm| 3 debian/git-daemon/run | 3 14 files changed, 741 insertions(+), 1 deletion(-) Effect of patches: Documentation/git-archive.txt |2 +- Documentation/git-fast-import.txt | 47 +++- Documentation/githooks.txt|4 --- bisect.c | 13 -- builtin/blame.c | 22 +--- builtin/revert.c | 20 --- commit.c | 19 +++ commit.h |3 ++ fast-import.c |2 + merge-recursive.c | 14 +++ t/t3505-cherry-pick-empty.sh | 20 +++- t/t9301-fast-import-notes.sh |1 + upload-pack.c | 23 - 13 files changed, 102 insertions(+), 88 deletions(-) What do you think? Would this be reasonable for upload to stable, or would it be better to leave out the less important upstream changes (fast-import.c and Documentation/)? Sorry to take so long to get to this. Jonathan [1] http://thread.gmane.org/gmane.comp.version-control.git/172042 [2] http://thread.gmane.org/gmane.comp.version-control.git/170789 -- 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/20110815003353.ga7...@elie.gateway.2wire.net
Bug#637840: pu: package git/1:1.7.2.5-3
Jonathan Nieder wrote:
debdiff attached, or see
Erm. (Here it is. Sorry for the noise.)
diff -u git-1.7.2.5/debian/changelog git-1.7.2.5/debian/changelog
--- git-1.7.2.5/debian/changelog
+++ git-1.7.2.5/debian/changelog
@@ -1,3 +1,24 @@
+git (1:1.7.2.5-3) stable; urgency=low
+
+ * debian/diff/0034..0043: new from the upstream maint-1.7.2 branch:
+* bisect, blame, cherry-pick, merge-recursive, revert: fix
+ off-by-one read when searching for the end of a commit subject.
+* fast-import: allow frontends to check for notes import feature.
+* some minor documentation updates.
+ * debian/diff/0044-upload-pack-start-pack-objects-before-...: new
+from upstream; upload-pack: start child that reads pack_pipe
+before writing to it. This prevents server-side deadlocks on
+shallow clone (closes: #607346).
+ * debian/git-daemon/run: use SO_REUSEADDR when binding the listening
+socket so the server can restart without waiting for old connections
+to time out (thx Daniel Kahn Gillmor; closes: #609405).
+ * debian/git-daemon-run.postrm purge: terminate the git-daemon/log
+service, even if there is an active connection using it, before
+deleting logs and the gitlog user (thx Daniel Kahn Gillmor; closes:
+#627314).
+
+ -- Jonathan Nieder jrnie...@gmail.com Sun, 14 Aug 2011 18:29:50 -0500
+
git (1:1.7.2.5-2) stable; urgency=low
* debian/git-daemon-run.postrm purge: terminate the git-daemon/log
diff -u git-1.7.2.5/debian/git-daemon-run.postrm
git-1.7.2.5/debian/git-daemon-run.postrm
--- git-1.7.2.5/debian/git-daemon-run.postrm
+++ git-1.7.2.5/debian/git-daemon-run.postrm
@@ -3,7 +3,10 @@
test $1 = 'purge' || exit 0
+sv down /etc/sv/git-daemon 2/dev/null || :
+sv down /etc/sv/git-daemon/log 2/dev/null || :
sv force-shutdown /etc/sv/git-daemon 2/dev/null || :
+sv force-stop /etc/sv/git-daemon/log 2/dev/null || :
rm -rf /etc/sv/git-daemon/supervise /etc/sv/git-daemon/log/supervise
rm -rf /var/lib/supervise/git-daemon /var/lib/supervise/git-daemon.log
diff -u git-1.7.2.5/debian/git-daemon/run git-1.7.2.5/debian/git-daemon/run
--- git-1.7.2.5/debian/git-daemon/run
+++ git-1.7.2.5/debian/git-daemon/run
@@ -5 +5,2 @@
- $(git --exec-path)/git-daemon --verbose --base-path=/var/cache
/var/cache/git
+ $(git --exec-path)/git-daemon --verbose --reuseaddr \
+--base-path=/var/cache /var/cache/git
only in patch2:
unchanged:
---
git-1.7.2.5.orig/debian/diff/0042-fast-import-clarify-documentation-of-feature-command.diff
+++
git-1.7.2.5/debian/diff/0042-fast-import-clarify-documentation-of-feature-command.diff
@@ -0,0 +1,79 @@
+From 6842190a886e546dd588339d8dcdf1baf2810e33 Mon Sep 17 00:00:00 2001
+From: Jonathan Nieder jrnie...@gmail.com
+Date: Sun, 28 Nov 2010 13:43:57 -0600
+Subject: fast-import: clarify documentation of feature command
+
+The feature command allows streams to specify options for the import
+that must not be ignored. Logically, they are part of the stream,
+even though technically most supported features are synonyms to
+command-line options.
+
+Make this more obvious by being more explicit about how the analogy
+between most feature commands and command-line options works. Treat
+the feature (import-marks) that does not fit this analogy separately.
+
+Signed-off-by: Jonathan Nieder jrnie...@gmail.com
+Acked-by: Sverre Rabbelier srabbel...@gmail.com
+Signed-off-by: Junio C Hamano gits...@pobox.com
+Signed-off-by: Jonathan Nieder jrnie...@gmail.com
+Signed-off-by: Junio C Hamano gits...@pobox.com
+(cherry picked from commit 68595cd442caabbd8b43ff0789d2829454efff1b)
+
+Signed-off-by: Jonathan Nieder jrnie...@gmail.com
+---
+ Documentation/git-fast-import.txt | 33 +++--
+ 1 files changed, 15 insertions(+), 18 deletions(-)
+
+diff --git a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
+index 77a0a24..00e086e 100644
+--- a/Documentation/git-fast-import.txt
b/Documentation/git-fast-import.txt
+@@ -878,28 +878,25 @@ Require that fast-import supports the specified feature,
or abort if
+ it does not.
+
+
+- 'feature' SP feature LF
++ 'feature' SP feature ('=' argument)? LF
+
+
+-The feature part of the command may be any string matching
+-^[a-zA-Z][a-zA-Z-]*$ and should be understood by fast-import.
+-
+-Feature work identical as their option counterparts with the
+-exception of the import-marks feature, see below.
+-
+-The following features are currently supported:
+-
+-* date-format
+-* import-marks
+-* export-marks
+-* relative-marks
+-* no-relative-marks
+-* force
+-
+-The import-marks behaves differently from when it is specified as
+-commandline option in that only one feature import-marks is allowed
+-per stream. Also, any --import-marks= specified on the commandline
+-will override those from the stream (if any).
++The feature part of the command may be any one of the following:
++
++date-format::
++export-marks::
++relative-marks::
++no-relative-marks
Bug#630201: transition: liblzma 5
Package: release.debian.org User: release.debian@packages.debian.org Usertags: transition Hi, I would like to upload liblzma5 to unstable, so liblzma in wheezy can match the upstream ABI. Relative to what's currently in sid, this involves a soname bump (2 → 5), introduction of versioned symbols, and some changes to the padding at the end of structs. liblzma never looks at this padding so even by simulating the worst case (liblzma2 and liblzma5 being indirect dependencies of a single binary through different paths, resulting in the two versions sharing a process image) I haven't been able to make it cause any trouble for partial upgrades. And I'm not aware of any packages that would trigger that worst case. You can find a liblzma5 package to test with at git://git.debian.org/collab-maint/xz.git experimental http://mentors.debian.org/debian/pool/main/x/xz-utils/xz-utils_5.1.1alpha+20110528-1~exp1.dsc The packaging takes the latest upstream version and reverts changes that introduced new ABI since the last stable upstream release. It is targetted at experimental and might be uploaded there soon. apt-cache points me to 14 binary reverse-dependencies counting each source package once[1], aside from xz-utils itself. From a transition coordination perspective, probably shogun, R, and KDE are the most notable ones. This is not urgent. I just would be happy to get it done so it doesn't have to happen later. Thoughts of all kinds welcome, of course. Regards, Jonathan [1] * shogun: shogun-r shogun-python-modular shogun-python shogun-octave-modular shogun-elwms shogun-cmdline libshogun9 libshogunui6 * python-lzma: python-lzma-dbg python-lzma * libarchive: libarchive1 bsdtar bsdcpio * miscellaneous: r-base-core libkdecore5 libyelp0 squashfs-tools mupen64plus gtkwave fusecompress fsarchiver libdw1 (DWARF parser for elfutils) apt-cacher-ng librpmio2 -- 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/20110612095655.GA22351@elie
Re: linux-2.6: Aufs apparently silently dropped, breaking debian-live
severity 627837 serious quit Daniel Baumann wrote: oh.. and before you ask.. 'way before' means 'at least 2011-04-18, but possibly even earlier' (yes, that really is a month before .39 was released). I don't see the value of this discussion --- it's water under the bridge, anyway. I'm setting the severity to serious, even though I am neither part of the release team nor a maintainer for the package. Either should of course feel free to set it back. Hopefully once a testing-plus-packages-from-sid distribution is available for d-i and debian-live use, these decisions can be less painful. -- 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/20110529202818.GA14683@elie
Bug#623529: pu: package git/1:1.7.2.5-2
Adam D. Barratt wrote: On Mon, 2011-04-25 at 12:38 -0500, Jonathan Nieder wrote: Yes, sv will not control a removed service unless passed the full path /etc/sv/git-daemon. Okay; thanks for the explanation. Please feel free to go ahead with the upload. Thanks for looking it over. Uploaded. -- 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/20110428215937.GC6030@elie
Bug#623529: pu: package git/1:1.7.2.5-2
Adam D. Barratt wrote: On Wed, 2011-04-20 at 17:58 -0500, Jonathan Nieder wrote: -sv force-stop git-daemon 2/dev/null || : +sv force-shutdown /etc/sv/git-daemon 2/dev/null || : Is the switch from git-daemon to /etc/sv/git-daemon here intentional? Yes, sv will not control a removed service unless passed the full path /etc/sv/git-daemon. (Thiatis because update-service removes the /etc/service/git-daemon symlink that sv would normally use. The update-service(8) manual hints at this under --remove: You can use the sv(8) program to control the removed service, or query its status, e.g.: # sv status service-directory ). -- 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/20110425173820.GB25104@elie
Bug#623529: pu: package git/1:1.7.2.5-2
Package: release.debian.org User: release.debian@packages.debian.org Usertags: pu Tags: squeeze Hi, Jonathan Nieder wrote: git-daemon-run wants to be removed and purged in steps separated by a sleep of a second or so. Otherwise userdel fails with user gitlog is currently logged in. I would be interested in fixing this in squeeze. The fix has only been in sid for four days but I've been using it locally for a month or so (and purging git-daemon-run now and then) without problems. A more complete discussion can be found in the commit log at git://repo.or.cz/git/debian/jrn.git debian-stable and the bug log for Bug#607243 (git-daemon-run: cannot purge and remove in one step). What do you think? --- debian/changelog |7 +++ debian/git-daemon-run.postrm |2 +- 2 files changed, 8 insertions(+), 1 deletions(-) diff --git a/debian/changelog b/debian/changelog index 2e55b70..389bf58 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +git (1:1.7.2.5-2) stable; urgency=low + + * debian/git-daemon-run.postrm purge: terminate the git-daemon/log +service before removing the gitlog user (closes: #610099). + + -- Jonathan Nieder jrnie...@gmail.com Wed, 20 Apr 2011 17:17:27 -0500 + git (1:1.7.2.5-1) stable; urgency=low * new upstream point release. diff --git a/debian/git-daemon-run.postrm b/debian/git-daemon-run.postrm index 6151b52..5e77e4d 100644 --- a/debian/git-daemon-run.postrm +++ b/debian/git-daemon-run.postrm @@ -3,7 +3,7 @@ set -e test $1 = 'purge' || exit 0 -sv force-stop git-daemon 2/dev/null || : +sv force-shutdown /etc/sv/git-daemon 2/dev/null || : rm -rf /etc/sv/git-daemon/supervise /etc/sv/git-daemon/log/supervise rm -rf /var/lib/supervise/git-daemon /var/lib/supervise/git-daemon.log -- 1.7.5.rc2 -- 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/20110420225818.GA10088@elie
Re: pu: package apt/0.8.10.3+squeeze1
Hi, Julian Andres Klode wrote: David submitted another bundle. It adds xz support to the rest of APT, so that we do not have half-baked support. The diff is very small and it may be a good idea to include it as well. What do you think? Just a quick nitpick: be sure to add the appropriate dependency when doing this. Despite dpkg's pre-dependency, xz-utils is not essential and it would be nice if it's easy to change dpkg to use liblzma when a spare moment comes. Thanks for your work. Jonathan -- 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/20110413094850.GA15754@elie
