Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2
Ian Jackson writes ("Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2"):
> Two users separately disscovered a misssing safety catch in dgit:
In the absence of a negative response, and conscious of the upcoming
stable release, I've uploaded this.
dgit push-source spotted that I had botched the suite name in the
d/changelog. Therefore I made an additional commit to fix that.
Please find attached the incremental diff, and a complete revised diff
of the actual upload.
Thanks,
Ian.
>From f31976ecdc0c4ce1d451bc2f138f0b9d5a3689c1 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Fri, 29 Sep 2023 11:28:51 +0100
Subject: [PATCH] changelog: fix wrong suite
Signed-off-by: Ian Jackson
---
debian/changelog | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 55aca1076..14b122146 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,4 @@
-dgit (10.7+deb12u2) unstable; urgency=medium
+dgit (10.7+deb12u2) bookworm; urgency=medium
* Prevent pushing older versions than is in the archive.
Closes: #1050711. [Reports from Helmut Grohne and Phil Hands]
--
2.20.1
diff --git a/debian/changelog b/debian/changelog
index bf03d2744..14b122146 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+dgit (10.7+deb12u2) bookworm; urgency=medium
+
+ * Prevent pushing older versions than is in the archive.
+Closes: #1050711. [Reports from Helmut Grohne and Phil Hands]
+Backported from dgit 11.3.
+
+ -- Ian Jackson Sun, 03 Sep 2023 00:49:57
+0100
+
dgit (10.7+deb12u1) bookworm; urgency=medium
* Use the old /updates security map only for buster. Fixes fetching from
diff --git a/debian/tests/control b/debian/tests/control
index a22400b17..99ef53414 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -100,7 +100,7 @@ Tests: trustingpolicy-replay
Tests-Directory: tests/tests
Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot,
build-essential, chiark-utils-bin, bc, faketime, liburi-perl, dput-ng
-Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-long
build-modes-source checkout clone-clogsigpipe debpolicy-dbretry
debpolicy-newreject debpolicy-quilt-gbp debpolicy-taintrm defdistro-rpush
defdistro-setup distropatches-reject dpkgsourceignores-correct
drs-push-masterupdate drs-push-rejects dsd-divert fetch-localgitonly
fetch-somegit-notlast forcesplit-linear forcesplit-overwrite gbp-orig gitconfig
gitworktree import-dsc import-maintmangle import-native import-nonnative
import-tarbomb inarchivecopy mismatches-contents mismatches-dscchanges
multisuite orig-include-exclude orig-include-exclude-chkquery overwrite-chkclog
overwrite-junk overwrite-splitbrains overwrite-version pbuilder protocol-compat
push-buildproductsdir push-newpackage push-newrepeat push-nextdgit push-source
push-source-with-changes quilt quilt-gbp quilt-gbp-build-modes
quilt-include-binaries quilt-singlepatch quilt-splitbrains quilt-useremail
rpush rpush-quilt rpush-source sourceonlypolicy tag-updates unrepresentable
unrepresentable-single-dpkg unrepresentable-single-git version-opt
+Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-long
build-modes-source checkout clone-clogsigpipe debpolicy-dbretry
debpolicy-newreject debpolicy-quilt-gbp debpolicy-taintrm defdistro-rpush
defdistro-setup distropatches-reject dpkgsourceignores-correct
drs-push-masterupdate drs-push-rejects dsd-divert fetch-localgitonly
fetch-somegit-notlast forcesplit-linear forcesplit-overwrite gbp-orig gitconfig
gitworktree import-dsc import-maintmangle import-native import-nonnative
import-pushold import-tarbomb inarchivecopy mismatches-contents
mismatches-dscchanges multisuite orig-include-exclude
orig-include-exclude-chkquery overwrite-chkclog overwrite-junk
overwrite-splitbrains overwrite-version pbuilder protocol-compat
push-buildproductsdir push-newpackage push-newrepeat push-nextdgit push-source
push-source-with-changes quilt quilt-gbp quilt-gbp-build-modes
quilt-include-binaries quilt-singlepatch quilt-splitbrains quilt-useremail
rpush rpush-quilt rpush-source sourceonlypolicy tag-updates unrepresentable
unrepresentable-single-dpkg unrepresentable-single-git version-opt
Tests-Directory: tests/tests
Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot,
build-essential, chiark-utils-bin, bc, faketime, liburi-perl
diff --git a/dgit b/dgit
index 541420921..dd2b301a6 100755
--- a/dgit
+++ b/dgit
@@ -103,7 +103,7 @@ our $chase_dsc_distro=1;
our %forceopts = map { $_=>0 }
qw(unrepresentable unsupported-source-format
dsc-changes-mismatch changes-origs-exactly
- uploading-binaries uploading-source-only
+ uploading-binaries uploading-old-version uploading-source-only
reusing-version
push-tainted
import-gitapply-absurd
@@ -4680,6 +4680,7 @@ END
git_fetch_us();
}
my $archive_
Bug#1051137: bookworm-pu: package dgit/10.7+deb12u2
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: d...@packages.debian.org Control: affects -1 + src:dgit [ Reason ] Two users separately disscovered a misssing safety catch in dgit: dgit push won't notice if the changelog for your upload states a version which is lower or the same as exists in the archive (unless the currently-being-pushed version wasn't itself previously uploaded with dgit). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050711 [ Impact ] Users using dgit from stable might make broken uploads. Typically, this happens when they're unintentionally uploading some modifications which were erroneously based on an out-of-date version of the package. Such an upload is then rejected by the ftpmaster archive. But misleading git tags have been made and published. Additionally, the broken upload remains in the dgit history, and mighht end up as noise in maintainer git histories. None of this is a violation of the constraints of the dgit data model, but: - It can be very confusing to humans. - Some maintainers really hate this kind of git noise, so this malfunction can generate social friction. - If the uploader doesn't notice, their intended changes will not actually end up in the target Debian suite. [ Tests ] I have added a test for this situation to the test suite. That test fails before the fix, and passes afterwards. The test is part of the autopkgtests. When backporting the relevant commits to the bookworm branch, I chose to include the new test. I have done a formal local run of the autopkgtests for 10.7+deb12u2. The test runs and passes as expected. Additionally, I built and installed 10.7+deb12u2 locally, and ran an ad-hoc manual test with dgit-test-dummy (which I deliberately put into this anomalous state for testing this bug). [ Risks ] The logic of the check might be wrong. There's a boolean condition, and a version number inequality comparison. However, I think the code is right because of the new test case. and also because adding this check only broke two of the existing tests, which, on inspection, did indeed play fast and loose with versions. Some downstreams might have workflows that trip the new check. There is a a --force option for it, but no configuration setting. This could affect downstreams who are running Debian stable to manage some other set of packages; but it would only affect downstreams who are working with source packages *and* routinely reuse (or rewind) source package versions. I doubt other tooling, besides dgit, would work well if you did that; for example, apt's handling of the resulting debs would be poor. The new test case is brand new and might be wrong. Also, I had to resolve a conflict in d/tests/control (which I did by regenerating it). So perhaps the autopkgtests might be broken. However, I have run them with bookworm's autopkgtest(1), and the overall impact of any such breakage seems like ti would be low. [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in (old)stable [x] the issue is verified as fixed in unstable [ Changes ] * Add the new check to dgit's "dopush" function * Provide a way to override the check * Add the override to two test cases that play fast and loose * Add a new test case for this specific situation Some more information is available in the commit messages, which can be found here: https://salsa.debian.org/dgit-team/dgit/-/commits/bookworm/ [ Other info ] Two users experienced lossage due this missing check in the same week: See #1050711 and #1050924. I don't know why this is, but perhaps we are seeing more parttial adoption of dgit within some teams. Both of these users found this dgit behaviour disturbing, and were significantly inconvenienced; in particular, both were doing authorised team uploads, and were concerned that the malfunction might upset the principal maintainers of the respective packages. diff --git a/debian/changelog b/debian/changelog index bf03d2744..55aca1076 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +dgit (10.7+deb12u2) unstable; urgency=medium + + * Prevent pushing older versions than is in the archive. +Closes: #1050711. [Reports from Helmut Grohne and Phil Hands] +Backported from dgit 11.3. + + -- Ian Jackson Sun, 03 Sep 2023 00:49:57 +0100 + dgit (10.7+deb12u1) bookworm; urgency=medium * Use the old /updates security map only for buster. Fixes fetching from diff --git a/debian/tests/control b/debian/tests/control index a22400b17..99ef53414 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -100,7 +100,7 @@ Tests: trustingpolicy-replay Tests-Directory: tests/tests Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, build-essential, chiark-utils-bin, bc, fak
Bug#1038616: bookworm-pu: package network-manager-strongswan/1.6.0-1+deb12u1
Harald Dunkel writes ("Bug#1038616: bookworm-pu: package
network-manager-strongswan/1.6.0-1+deb12u1"):
> I made a mistake on the pu for network-manager-strongswan: I missed to
> set you on CC. I am very sorry.
No problem, it just meant you had to ping me ...
> AFAICT the upload to Bookworm has been approved. Would you mind to check?
Indeed so. Now done.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
rust-base64 migration dependency adjustment
Control: tags -1 + trixie-ignore hippotat 1.1.7 FTBFS with rust-base64 0.21. hippotat 1.1.9 build-depends on rust-base64 0.21. So the plan is for these to migrate together, and ISTM from reading tracker that that is what will happen as soon as the remaining blockers for rust-bsee64 migration are disposed of. In principle hippotat's build-dependencies could have been adjusted to depend on rust-base64 0.13, and then we could have waited for that to enter testing, and then done the update. But thst seems otiose, given that the plan is that trixie should have base64 0.21. Therefore I am tagging this bug trixie-ignore to avoid getting autoremoval warnings etc. I hope I'm not overstepping the mark. PS, with my upstream hat on: It is a shame that the Rust base64 crate has such a cavalier approach to API stability. I am considering my options in this area for hippotat (eg data-encoding or base64ct), but without better tests and test vectors I am reluctant to switch right now. Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1033503: dgit autopkgtests broken by git 2.40
Package: dgit Version: 10.7 Control: affects -1 git Some of dgit's tests create strange git objects, to test error handling. For example, to avoid a repetition of #849041. git 2.40, just uploaded to unstable, has this change: | * "git hash-object" now checks that the resulting object is well | formed with the same code as "git fsck". | (merge 8e4309038f jk/hash-object-fsck later to maint). This was probably a good idea. So, dgit's tests need to be updated. Normally I would file this bug as RC and make the necessary changes. However, we are currently in the freeze for bookworm. Information on tracker.d.o suggests that git is not going to migrate to bookworm anyway, without an unblock from the release team. I don't see an unblock request in https://bugs.debian.org/release.debian.org . Release team: do you think we (dgit maintainers) should update the test suite now, for bookworm ? The changes would be limited to tests, but the new checks in git mean we'll need to take a different approach for some of them, which might be complex or messy. Unhelpfully, there is also #1032826, which prevents "dgit import-dsc" working for the current git.dsc in bookworm. I think this situation is RC. I haven't filed a bug against src:git because I think we can fix this just by changing the infrastructure - I'm talking to DSA about this - but if that turns out to be impossible, we may need to upload a no-source-changes src:git :-/. Thanks for everyone's attention and advice/opinions. Thanks, Ian. -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED [and 1 more messages]
Dear Debian Ocaml Team:
Hi. I'm with the Debian Xen Team. We recently uploaded
xen_4.17.0+24-g2f8851c37f-1 to unstable. It went through NEW because
of a cleanup of -dbg packages containing (C) debug symbols.
ftpmaster REJECTed it:
> there is an ocaml stack rebuild[1] at them moment, where xen is a part of.
> So please upload to experimental.
...
> [1] https://release.debian.org/transitions/html/ocaml.html
The Xen package builds some ocaml tools. Thanks to Thorsten and Paul
Gevers for trying to keep things running smoothly.
Paul Gevers writes ("Re: xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED"):
> On 05-02-2023 14:06, Ian Jackson wrote:
> > Sorry again for being an idiot, but where should we have checked, to
> > avoid such a mistake in the future ? I thought this kind of thing
> > would appear on tracker but
> > https://tracker.debian.org/pkg/xen
> > doesn't show it now.
>
> ocaml is a bit weird, it has a permanent tracker:
> https://release.debian.org/transitions/html/ocaml.html. Hence tracker
> doesn't show it, as often there is not actively a transition going on.
>
> This was very briefly discussed on IRC:
> [01:53:45] can the new xen package be uploaded to unstable?
> [07:44:50] ta: there's an ocaml stack rebuild going on
> apparently: https://release.debian.org/transitions/html/ocaml.html
> [07:46:11] I don't know who's doing that, but it might interfere
>
> To be fair, I'm not very aware of how exactly ocaml transitions work and
> I didn't realize ta was asking as ftp-master (and not as cautious xen
> uploader), otherwise I would have tried harder to figure that part out.
It seems we (non-ocaml folks) are a bit confused. Certainly, I am.
Could you please advise is what the proper way is for us to interact
with ocaml transitions ? When, if at all, should we wait with
uploading to unstable ?
In the past we have used tracker.d.o to tell us about ongoing
transitions involving our packages. Is that enough for ocaml too ?
I looked on the wiki and found this
https://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions
which I didn't find very illuminating.
In the meantime, xen_4.17.0+24-g2f8851c37f-2~exp1 has cleared NEW.
It's targeting bookworm and we would like to upload it to unstable.
Please let us know by this time tomorrow if there's any reason not to
do that.
In case it makes any difference, I can confirm that the Xen package
builds reproducibly according to tests.reproducible-builds.org and
indeed my personal experience.
Sorry for not CCing you earlier.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Re: xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED
Thorsten Alteholz writes ("xen_4.17.0+24-g2f8851c37f-1_multi.changes REJECTED"):
> there is an ocaml stack rebuild[1] at them moment, where xen is a part of.
> So please upload to experimental.
Thanks, we will do that shortly. I'm sorry to cause trouble.
Sorry again for being an idiot, but where should we have checked, to
avoid such a mistake in the future ? I thought this kind of thing
would appear on tracker but
https://tracker.debian.org/pkg/xen
doesn't show it now.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Re: Bug#1012496: Proposed inkscape reversion NMU
Sebastian Ramacher writes ("Re: Bug#1012496: Proposed inkscape reversion NMU"):
> On 2023-01-06 11:24:45 +, Ian Jackson wrote:
> > Hi.
> >
> > inkscape is currently uninstallable in sid on some release arches,
> > due to an FTBFS which seems to be an upstream problem [1].
> > This is blocking builds for packages that build-depend on inkscape. [5]
> > I'm assuming that the previous version in testing was OK. [0]
>
> This assumption does not hold. inkscape 1.1.2-3 FTBFS everywhere:
>
> https://buildd.debian.org/status/fetch.php?pkg=inkscape=amd64=1.1.2-3%2Bb2=1664419348=0
Oh. How sad. Thanks for pointing that out.
> That means that there are some transitions staged in experimental that
> require rebuilds of inkscape. Once those transitions start, tracker.d.o
> will have a note that inkscape is part of an ongoing transition and
> hence uploads should be avoided if unrelated to the transition. Given
> that inkscape currently does not build, any upload fixing this issue
> would be related and welcome.
Thanks. I'm not sure I have the tuits to dive into the code right
now, especially given how complex it looks from reading the upstream
ticket :-(.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
Proposed inkscape reversion NMU
Hi. inkscape is currently uninstallable in sid on some release arches, due to an FTBFS which seems to be an upstream problem [1]. This is blocking builds for packages that build-depend on inkscape. [5] I'm assuming that the previous version in testing was OK. [0] Mattia, you suggested[2] that you planned to roll back in Debian. Is there some reason why we shouldn't do that now ? Would it be a godo idea ? I'm happy to do it. Release Team, should I take 1.1.2-3 from testing, relabel it 1.2.2+really-1.1.2-3+nmu1, and test and upload it ? [3] I noticed that tracker mentions that this package will "soon be part of the auto-*" transition. I confess that I don't really know what that means and following the links left me more confused. If others are already on the case, or people think it would be better to leave this situation as-is until after the release, please let me know. I'm trying to help, not be an annoyance... Regards, Ian. [0] It is possible that in fact the FTBFS is due to test suite failures caused by updates to (build)-dependencies, but I would have expected a QA "FTBFS in testing" bug if that were the case. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012496 https://gitlab.com/inkscape/inkscape/-/issues/3554 [2] https://gitlab.com/inkscape/inkscape/-/issues/3554#note_1120324670 [3] I think this looks like: - prepare the package source code [4] - test the s390x build (say) on a porterbox - maybe run the autopkgtests locally and on a porterbox - upload to unstable - reopen bugs that were closed between 1.1.2-3 and 1.2.2-1 - keep an eye on the autobuilders/testing migration [4] Is there a standard way of representing this situation in d/changelog ? If no-one reading this knows, I will ask d-devel. [5] My interest in this is as sponsor/mentor for src:chroma, which build-depends on inkscape (using it as an SVG renderer). -- Ian JacksonThese opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#1021005: bullseye-pu: package dgit/9.16
branchinfo
parsecontrolfh parsecontrol parsechangelog
getfield parsechangelog_loop
- playtree_setup);
+ playtree_setup playtree_write_gbp_conf);
# implicitly uses $main::us
%EXPORT_TAGS = ( policyflags => [qw(NOFFCHECK FRESHREPO NOCOMMITCHECK)],
playground => [qw(record_maindir $maindir $local_git_cfg
@@ -1077,6 +1077,20 @@ sub playtree_setup () {
open GA, "> .git/info/attributes" or confess "$!";
print GA "* $negate_harmful_gitattrs\n" or confess "$!";
close GA or confess "$!";
+
+playtree_write_gbp_conf();
+}
+
+sub playtree_write_gbp_conf (;$) {
+my ($ignore_new) = @_;
+$ignore_new //= 'false';
+
+open GC, "> .git/gbp.conf" or confess "$!";
+print GC <<"END" or confess $!;
+[pq]
+ignore-new = $ignore_new
+END
+close GC or confess "$!";
}
1;
diff --git a/debian/changelog b/debian/changelog
index 18bee7f3a..eaf9e34df 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,56 @@
+dgit (9.16) unstable; urgency=medium
+
+ Compatibility with git-buildpackage gbp pq 0.9.26 (Closes:#1005873):
+ * dgit: Move .pc aside while running gbp pq import
+ * git-debrebase: convert-from-dgit-view: Disable ignore-new where needed
+
+ Other changes:
+ * Fix typo in changelog for 9.14, noting that we closed #987304.
+ * playtrees (for dgit and git-debrebase): Provide a gbp.conf.
+ * tests: gdr: Provide a way to pass --diagnose.
+
+ -- Ian Jackson Sat, 28 May 2022 22:49:53
+0100
+
+dgit (9.15) unstable; urgency=medium
+
+ * dgit: pseudomerge_version_check: Check for unfinalised changelog entry.
+ * tests: Set FILTER_BRANCH_SQUELCH_WARNING=1
+ * tests: Use t-debchange in some places instead of dch
+ * tests: Update all using tests/update-db-compat. Closes: #1002927.
+
+ -- Ian Jackson Sun, 02 Jan 2022 12:20:23
+
+
+dgit (9.14) unstable; urgency=medium
+
+ Bugfixes:
+ * Tolerate git config init.defaultBranch. Closes:#972098.
+Reports from Didier 'OdyX' Raboud, Osamu Aoki.
+Diagnosis by Stig Sandbeck Mathisen.
+ * dgit: Tolerate making quilt patches creating +x files.
+Closes:#949675. Report from peter green.
+ * dgit: Avoid use of GZIP environment variable.
+Closes: #975624. Report from Stéphane Glondu.
+ * Tolerate git config diff.noprefix.
+Closes:#973881; report from Didier 'OdyX' Raboud.
+
+ Documentation and diagnostics:
+ * Clarify git-debrabase --anchor, -fanchor-treated.
+Closes:#977426. Report from Wookey .
+ * dgit: Better message for dirty trees. Closes:#930930.
+Report and suggestions from Sean Whitton.
+
+ git-debpush, tag2upload:
+ * Add missing dependency. Closes:#940589; report from Andrej Shadura.
+ * Fix version unmangling. Closes:#987304; report from Wolfgang Silbermayr.
+
+ Tests:
+ * Introduce t-debchange and set DEBEMAIL.
+ * Add init.defaultBranch to two test cases and diff.noprefix to one.
+ * Test creation of new symlink is treated as unrepresentable.
+ * Increase the nproc -> make -j factor.
+
+ -- Ian Jackson Wed, 08 Sep 2021 01:30:53
+0100
+
dgit (9.13) unstable; urgency=medium
* gitattributes defuse: work even if .git/info/attributes missing
diff --git a/debian/control b/debian/control
index 210c5b73e..4a0f6118a 100644
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,8 @@ Description: rebasing git workflow tool for Debian packaging
gbp pq, and direct use of quilt patches.
Package: git-debpush
-Depends: devscripts, git, gnupg, ${misc:Depends}
+Depends: devscripts, git, gnupg, libgit-wrapper-perl,
+ ${misc:Depends}
Architecture: all
Description: client script for git pushing to Debian-style archives
git-debpush is a script to create and push a specially formatted
diff --git a/dgit b/dgit
index 145fa9bb0..d39dc4b6f 100755
--- a/dgit
+++ b/dgit
@@ -324,6 +324,16 @@ sub gbp_pq {
return opts_opt_multi_cmd [], @gbp_pq;
}
+sub gbp_pq_pc_aside (&) {
+ my ($f) = @_;
+ my $undo = rename ".pc", "../pc-aside";
+ confess "$!" unless $undo || $!==ENOENT;
+ $f->();
+ if ($undo) {
+rename "../pc-aside", ".pc", or confess $!;
+ }
+}
+
sub dgit_privdir () {
our $dgit_privdir_made //= ensure_a_playground 'dgit';
}
@@ -2679,12 +2689,14 @@ END
my @showcmd = (gbp_pq, qw(import));
my @realcmd = shell_cmd
'exec >/dev/null 2>>../../gbp-pq-output', @showcmd;
- debugcmd "+",@realcmd;
- if (system @realcmd) {
- die f_ "%s failed: %s\n",
- +(shellquote @showcmd),
- failedcmd_waitstatus();
- }
+ gbp_pq_pc_aside(sub {
+ debugcmd
Re: git-buildpackage to be autoremoved due to python2 transition
Andrey Rahmatullin writes ("Re: git-buildpackage to be autoremoved due to
python2 transition"):
> Yes, and as far as I can see after pydoctor migrates the only problem with
> gbp will be python-rpm in debian/tests/control, which is probably
> unneeded.
Oh.
> > the py2 rot seems wider including in gbp itself.
>
> Where exactly?
I looked again and I was looking at an old version. Sorry for the
noise. I still think we have problems with these
937132 nevow: Python2 removal in sid/bullseye
938622 tahoe-lafs: Python2 removal in sid/bullseye
which I think are brought in by pydoctor...
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
git-buildpackage to be autoremoved due to python2 transition
FYI. The widespread impact of this not so apparent because git-buildpackage is typically used ad-hoc by maintainers, rather than via (Build)-Depends. Relevant packages and bugs: 943107 git-buildpackage: Python2 removal in sid/bullseye 937132 nevow: Python2 removal in sid/bullseye 938622 tahoe-lafs: Python2 removal in sid/bullseye Bugs which you may notice which are now not so relevant any more because they have been fixed in sid (but not yet migrated): 950216 [git-buildpackage] missing xsltproc autopkg test dependency Fixed in sid; migration blocked by FTBFS due to pydoctor breakage (#949232). When pydoctor has migrated, reattempting build (eg by re-upload) should fix this. 949232/948831 [pydoctor] needs to depend on cachecontrol 952546 [pydoctor] d/copyright & DFSG issues 937421 [pydoctor] Python2 removal in sid/bullseye My personal interest in this is that dgit Depends on git-buildpackage so I am early in the firing line. However, unfortunately my python skills are very weak and I doubt my blundering efforts [1] to try to mitigate the situation would would be helpful. I can at least do the digging to see what is actually still wrong here. Thanks to Anthony Fok for fixing pydoctor but the py2 rot seems wider including in gbp itself. Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: vacation 3.3.2 MIGRATED to testing
Niels Thykier writes ("Re: vacation 3.3.2 MIGRATED to testing"):
> There was a binNMU of vacation/3.3.2 yesterday[1]. I have not looked
> into the precise timing but I assume that is the reason why 3.3.2 migrated.
...
> [1]
> https://buildd.debian.org/status/logs.php?pkg=vacation=3.3.2%2Bb1=amd64=sid
Ah. Thanks for the clarification.
Forgive my ignorance (and adding the WB team), but:
Do you happen to know what the most sensible way is for me to check
for a binNMU in future ? Starting from tracker and its links to
buildd logs, I can't seem to find any trace of 3.3.2+b1. It's not on
p.d.o either (https://packages.debian.org/unstable/vacation).
And I didn't get any email about this binNMU despite being listed in
Uploaders.
And, DYK if there is a way for me to know who scheduled this binNMU
and why ? From your link I found a log which contains this
information:
Binary-Only-Changes:
vacation (3.3.2+b1) sid; urgency=low, binary-only=yes
.
* Binary-only non-maintainer upload for amd64; no source changes.
* rebuild on buildd
.
-- amd64 Build Daemon (x86-grnet-01)
Sat, 24 Aug 2019 04:47:34 +
This suggests someone is binNMUing things in order to make them
migrate ? That seems like it might be plausible but from here
everything is mostly mysterious...
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: vacation 3.3.2 MIGRATED to testing
Debian testing watch writes ("vacation 3.3.2 MIGRATED to testing"):
> FYI: The status of the vacation source package
> in Debian's testing distribution has changed.
>
> Previous version: 3.3.1
> Current version: 3.3.2
Hi. I think something went wrong with testing migration here.
3.3.2, which is now in testing, was *not* built on the buildds.
Yesterday's excuses gave that as the reason for vacation not
migrating. So I did a source-only re-upload, 3.3.3.
But it seems that britney has migrated 3.3.2.
https://tracker.debian.org/pkg/vacation
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bits from the Release Team: ride like the wind, Bullseye!
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team:
ride like the wind, Bullseye!"):
> My personal point of view (and because of this it might be biased)
> is that the maintainers of the packages that ship autopkgtest should
> be the reponsibles for any breackage it might occur on them because:
>
> - They added autopkgtests, so they are showing an intent on
> reviewing them when they fail.
> - They will certainly know their packages better than the library
> maintainer, and thus they have more chances to get the root of the
> issue sooner. Of course that might mean finding a bug in the
> library, but that's just ok.
In the general case the proper investigation of a bug might need
involvement from both people, collaboratively. That involves a kind
of ping pong on a technical level.
> On 19/08/08 09:46, Paul Gevers wrote:
> > I think we should also try to improve the visibility towards reverse
> > dependencies that their autopkgtest is blocking other packages. I would
> > love tracker (and the old pts) to show this on their page. (Working on
> > such a patch is on my TODO list, except not at the top).
I already made grep-excuses print this information. It has been very
helpful to me. Maybe we should make --autopkgtests the default ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bits from the Release Team: ride like the wind, Bullseye!
Lisandro Damián Nicanor Pérez Meyer writes ("Re: Bits from the Release Team:
ride like the wind, Bullseye!"):
> No, what I have been perceiving (and pretty please note that this is my
> personal "feeling") is that maintainers, specially library maintainers, have
> even more and more "stuff to care for".
I can see why you feel that way.
I think maybe we need to make it easier for the maintainer of a
widely-used library to push some of this out to depending packages.
(And I speak as a maintainer of a leaf package with a thorough
autopkgtest suite which often blocks the migration of my
dependencies.)
Lisandro, would it meet your needs if you had free licence to file RC
bugs against all packages which were blocking your migration, before
you had done the investigation yourself ?
I think the effect would be that a maintainer of a dependent package
would have to engage with the situation and if they did nothing for
long enough, the autoremoval would kick in. Then your library would
be able to migrate.
This seems similar to the approach we take with (say) new compilers,
which trigger FTBFS bugs in depending packages. The compiler
maintainers do not investigate the issues - they file bugs, which
eventually become RC, and then the depending packages must either be
fixed our autoremoved.
(Of course some library maintainers would prefer to do some
investigation first.)
Ian.
Bug#929571: unblock: dgit/8.5
Control: tag -1 - moreinfo
Jonathan Wiltshire writes ("Re: Bug#929571: unblock: dgit/8.5"):
> On Sun, May 26, 2019 at 11:12:28AM +0100, Ian Jackson wrote:
> > I attach the git commit which explains the details. Assuming you give
> > the go-ahead, I will upload this with an appropriate changelog update.
>
> Please go ahead and remove the moreinfo tag from this bug when it is ready
> to unblock.
Thanks, done.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#929571: unblock: dgit/8.5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dgit
I have discovered an annoying bug in a common error handling pattern
in dgit, which results in it not printing errno when it is crashing
for an unexpected reason.
I would like to fix it in buster for two reasons:
* It makes some kinds of failure much harder to diagnose.
* The fix, while conceptually extremely simple, and extremely
formulaic, is textually very large. I would like to avoid such a
big textual divergence between buster and future development;
primarily to avoid textual conflicts when back-porting /
forward-porting any future bugfixes to the stable branch.
I attach the git commit which explains the details. Assuming you give
the go-ahead, I will upload this with an appropriate changelog update.
unblock dgit/8.5
-- System Information:
Debian Release: 9.9
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
>From d28467db161d0590469b5f8e1115f84858d66e06 Mon Sep 17 00:00:00 2001
From: Ian Jackson
Date: Sun, 26 May 2019 10:50:23 +0100
Subject: [PATCH] Replace `confess $!' with `confess "$!"', to actually print
errno
$ perl -e 'use Carp; open X, ">/dev/eacces" or die $!'
Permission denied at -e line 1.
$ perl -e 'use Carp; open X, ">/dev/eacces" or confess $!'
at -e line 1.
$ perl -e 'use Carp; open X, ">/dev/eacces" or confess "$!"'
Permission denied at -e line 1.
$
confess will get references to its arguments in @_. Its documentation
says it saves/restores $!. I conjecture that these interact as we see
here:
$ perl -e '$!=1; sub x { print ">@_<\n"; } x $!;'
>Operation not permitted<
$ perl -e '$!=1; sub x { local $!; print ">@_<\n"; } x $!;'
><
Quoting "$!" averts the reference (and it will also ensure that we
get the string value of $!, in case confess were to do anything in the
future which would mess that up).
This commit was made like this:
perl -i -pe 's/confess \$!/confess "\$!"/g' dgit
perl -i -pe 's/confess \$!/confess "\$!"/g' git-debrebase
perl -i -pe 's/confess \$!/confess "\$!"/g' Debian/Dgit.pm
I have manually reviewed each hunk and it all looks good to me.
Closes: #929549
Signed-off-by: Ian Jackson
---
Debian/Dgit.pm | 56 +++---
dgit | 240 -
git-debrebase | 42 +-
3 files changed, 169 insertions(+), 169 deletions(-)
diff --git a/Debian/Dgit.pm b/Debian/Dgit.pm
index 2ef32f32..61476d9f 100644
--- a/Debian/Dgit.pm
+++ b/Debian/Dgit.pm
@@ -148,11 +148,11 @@ sub setup_sigwarn () {
sub initdebug ($) {
($debugprefix) = @_;
-open DEBUG, ">/dev/null" or confess $!;
+open DEBUG, ">/dev/null" or confess "$!";
}
sub enabledebug () {
-open DEBUG, ">" or confess $!;
+open DEBUG, ">" or confess "$!";
DEBUG->autoflush(1);
$debuglevel ||= 1;
}
@@ -181,7 +181,7 @@ sub printdebug {
print DEBUG $debugprefix unless $printdebug_noprefix;
pop @_ while @_ and !length $_[-1];
return unless @_;
-print DEBUG @_ or confess $!;
+print DEBUG @_ or confess "$!";
$printdebug_noprefix = $_[-1] !~ m{\n$};
}
@@ -214,9 +214,9 @@ sub shellquote {
sub printcmd {
my $fh = shift @_;
my $intro = shift @_;
-print $fh $intro," " or confess $!;
-print $fh shellquote @_ or confess $!;
-print $fh "\n" or confess $!;
+print $fh $intro," " or confess "$!";
+print $fh shellquote @_ or confess "$!";
+print $fh "\n" or confess "$!";
}
sub debugcmd {
@@ -347,7 +347,7 @@ sub waitstatusmsg () {
sub failedcmd_report_cmd {
my $intro = shift @_;
$intro //= __ "failed command";
-{ local ($!); printcmd \*STDERR, _us().": $intro:", @_ or confess $!; };
+{ local ($!); printcmd \*STDERR, _us().": $intro:", @_ or confess "$!"; };
}
sub failedcmd_waitstatus {
@@ -395,7 +395,7 @@ sub cmdoutput_errok {
my $d;
$!=0; $?=0;
{ local $/ = undef; $d = ; }
-confess $! if P->error;
+confess "$!" if P->error;
if (!close P) { printdebug "=>!$?\n"; return undef; }
chomp $d;
if ($debuglevel > 0) {
@@ -528,10 +528,10 @@ sub git_cat_file ($;$) {
if (!$gcf_pid) {
my @cmd = qw(git cat-file --batch);
debugcmd "GCF|"
Re: That merged-usr is mandatory is RC
(sending this because I got the release team address wrong)
Ian Jackson writes ("That merged-usr is mandatory is RC"):
> Control: severity -1 serious
>
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.
>
> Guillem filed the bug as `wishlist' but given the controversy it seems
> to me that it should be RC if for no other reasons than social
> cohesion.
>
> CCing the TC FYI (they have already been involved in merged-usr
> debates via #914897) and the release team, in case they have an
> opinion. FAOD I am not a maintainer of base-files but AFAICT the
> base-files maintainer has not expressed an opinion about severity.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#926876: unblock: chiark-utils/6.0.4
Control: tags -1 - moreinfo
Niels Thykier writes ("Re: Bug#926876: unblock: chiark-utils/6.0.4"):
> Please go ahead with the upload and remove the moreinfo tag when it is
> ready to be unblocked.
Done, and the buildds have finished. Thanks.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#926876: unblock: chiark-utils/6.0.4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package chiark-utils
chiark-utils is a portmanteau of different utiliies. I am proposing
to fix two bugs. Each bug is RC for the corresponding utility in the
sense that the utility is dangerous or useless without the fix. (The
bugs are not IMO RC for the package as a whole, although I think the
dangerous one is "important".)
1. fishdescriptor has a bug which makes it not work on amd64 and could
cause malfunctions or even UB in the target process. #926858
2. sync-accounts uses an ancient deprecated perl syntax and is
entirely rejected by current versions of perl. #865985
Below is the source diff. Assuming the unblock is granted I will
finalise the changelog entry for 6.0.4 and do a dgit push-source
to do a source-only upload.
(For my records: diff was generated from current master on chiark, ie
0caba95b1c3f211fa3defcff017dde1374b3caa6)
unblock chiark-utils/6.0.4
diff --git a/debian/changelog b/debian/changelog
index 1d1758f..e0ecabd 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+chiark-utils (6.0.4~iwj1) unstable; urgency=medium
+
+ * sync-accounts: Fix perl syntax error. Closes:#865985.
+ * changelog: Document bug number for bugfix in 6.0.4~citrix1.
+
+ --
+
+chiark-utils (6.0.4~citrix1) unstable; urgency=medium
+
+ * fishdescriptor: cast __errno_location correctly. Closes:#926858.
+
+ -- Ian Jackson Mon, 08 Apr 2019 17:03:47 +0100
+
chiark-utils (6.0.3) unstable; urgency=medium
* Upload to Debian unstable.
diff --git a/fishdescriptor/py/fishdescriptor/indonor.py
b/fishdescriptor/py/fishdescriptor/indonor.py
index 20bc807..e227fb2 100644
--- a/fishdescriptor/py/fishdescriptor/indonor.py
+++ b/fishdescriptor/py/fishdescriptor/indonor.py
@@ -142,7 +142,7 @@ class DonorImplementation():
# in my browser). Also the error is very nonspecific :-/.
# This seems to happen on jessie, and is fixed in stretch.
# Anyway:
-return parse_eval(expr_pat % '(*((int (*)(void))__errno_location)())')
+return parse_eval(expr_pat % '(*((int*(*)(void))__errno_location)())')
# calling functions (need to cast the function name to the right
# type in case maybe gdb doesn't know the type)
diff --git a/sync-accounts/sync-accounts b/sync-accounts/sync-accounts
index cef131c..5348a14 100755
--- a/sync-accounts/sync-accounts
+++ b/sync-accounts/sync-accounts
@@ -64,7 +64,7 @@ sub fields_fmt ($$) {
my ($pfx,$fmt) = @_;
my ($vn);
$vn= "fields_pw_$fmt";
-die "unknown format $fmt\n" unless defined @$vn;
+die "unknown format $fmt\n" unless @$vn;
fields($pfx,@$vn);
$vn= "${pfx}_format";
$$vn= $fmt;
-- System Information:
Debian Release: 9.8
APT prefers stable-debug
APT policy: (500, 'stable-debug'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-0.bpo.2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Freeze exception enquiry (Xen 4.12)
tl;dr: should we update buster to Xen 4.12 (currently, 4.12-RC2) ? Hi. I hope you will be able to answer this question before we prepare a proposed updated package (and certainly without us uploading the package to unstable, since we want to keep unstable for updates to buster). Xen upstream is currently in the 2nd week of the freeze for Xen 4.12. sid/buster currently have 4.11. Upstream quality in 4.12 seems reasonable (and comparable to that of the Xen 4.11) we have. It is very likely that Xen 4.12 will be finally released well before Debian buster. For stretch, we put a Xen 4.8 RC in before the Debian freeze, and updated it to the 4.8 release later. IIRC there was no need for a formal exception. For buster the timings are less favourable. In particular, we would need an exception from the transition freeze. I don't anticipate any difficulties with that - the upstream API has not really changed significantly and there are not that many packages involved. The principal upside would be an additional 6 months of upstream security support. Other improvements in Xen 4.12 include better support for the new PVH guest mode; these and other improvements are incremental rather than revolutionary. Please could you advise whether this update is something you generally favour ? If so then we will prepare a suitable update and check that the library transition is fine for all the the rdepends, and then return with a formal freeze exception request. We do not expect to need any significant changes to the packaging. A whole package debdiff is not likely to be very illuminating because there will be a fair few upstream changes. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: autopkgtest regression in dgit (8.3) on amd64 due to dpkg (1.19.2 to 1.19.4)
Mattia Rizzolo writes ("Re: autopkgtest regression in dgit (8.3) on amd64 due
to dpkg (1.19.2 to 1.19.4)"):
> Yes, it changed because since January autopkgtest regressions are
> completely blocking, not just delaying migration. Therefore the
> migration is just "note considered" at all, regardless of the aging.
Ah, OK, good.
> Testing migration won't happen unless autopkgtest is fixed or somebody
> from the release team ignores it.
Right, that is as it should be.
> > FTR, I have discussed this with the dpkg maintainer. I think this is
> > a bug in dgit rather than in dpkg and I am treating it as an RC issue
> > which will be fixed soon.
>
> And you ought to treat it like that :)
Indeed; that is a consequence of the above.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: autopkgtest regression in dgit (8.3) on amd64 due to dpkg (1.19.2 to 1.19.4)
Hi. dgit's autopkgtests have a regression with dpkg 1.19.4. Tracker's view of the excuses says: Too young, only 2 of 5 days old Updating dpkg fixes old bugs: #911620 Piuparts tested OK - https://piuparts.debian.org/sid/source/d/dpkg.html autopkgtest for dgit/8.3: amd64: Regression ♻ Not considered Previously in this situation I have seen `migration age increased' etc. Is that still happening ? Has the excuses output changed ? FTR, I have discussed this with the dpkg maintainer. I think this is a bug in dgit rather than in dpkg and I am treating it as an RC issue which will be fixed soon. But, the new dpkg ought not to migrate to testing before the fix in dgit, because I think the bug makes dgit fairly broken with the new dpkg. Regards, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#907199: weboob, Gratuitous sexual references
Marc Dequènes (duck) writes ("Re: weboob, Gratuitous sexual references"):
> *Unilaterally* taking decisions in a project
I feel I need to set the record straight. This decision was not taken
unilaterally.
The process was:
* We had a conversation involving you as maintainer; you
decided that unless upstream were convinced to change[1],
the package should stay in Debian in its current form.
* I disagreed with your decision as maintainer and raised the
matter with various project officials to ask the correct
route to address my concerns.
* After discussion (including opinions from DPL, the release team,
and others), the antiharassment team concluded that this was
within their remit, discussed it amongst themselves, and
recommended that the package, in its current form, should not be
included in Debian.
* That recommendation from AH was forwarded (via this bug) to the
ftpmasters, who are actually finally responsible for such
decisions.
* Upstream were not convinced to change. ftpmaster decided to
follow AH's recommendation.
So ultimately, this decision was taken by the ftpmaster team, on
recommendation from the AH team, with advice on process from the DPL.
I think if you disagree, you may escalate to the TC or to a GR.
> Sometimes it really feels bad to be in Debian…
I'm sorry you feel that way. I don't think it was possible to resolve
this disagreement without making someone feel like that.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#914898: debootstrap, stretch-backports: Please disabled merged /usr by default
Package: debootstrap Version: debootstrap/1.0.110~bpo9+1 Severity: serious In #914208 Simon McVittie writes: > [merge-/usr] is now the default in stretch-backports' debootstrap As discussed on debian-devel, however, binary packages built on a merged-usr system are not installable on a non-merged-usr system. Obviously we would like ad hoc builds of packages from one stretch machine to be installable on other stretch machines. I do not see any way in which this could be resolved for stretch. Accordingly, please urgently revert this change for stretch-backports. Ian. (I have CC'd debian-release@lists because this seems like it wants the attention of the stable release team. I wasn't able to find a separate contact address for the stable release team here https://www.debian.org/intro/organization and I have a vague memory that this is somehow the same list. Please redirect me if I am wrong.) -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#907199: Should the weboob package stay in Debian?
Chris Lamb writes ("Re: Should the weboob package stay in Debian?"):
> I was led to believe — althought naturally feel very free to
> correct me — that the AH team were (quite correctly,) handling this
> issue and thus I have not been taking action on it myself as
> leader@.
>
> I therefore also eagerly their opinion and/or correction this
> matter.
Please see the AH team's response here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907199#47
ISTM that the AH team have done a very helpful job, providing a clear
opinion about both: (i) the suitability for Debian of the package in
its current state; and (ii) the proper way to implement that,
sociopolitically.
Personally even though I think this package is unacceptable in its
current state, our tradition in Debian would normally be to leave the
package in old releases and remove it only from new ones.
So, should the next thing be an RM bug requesting the package be
removed from unstable ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#907199: Should the weboob package stay in Debian?
Ian Jackson writes ("Re: Should the weboob package stay in Debian?"):
> I look forward to hearing from the Debian maintainer, who I think is
> the first point of contact for the management of the package in
> Debian.
I am concerned about the lack of progress. I would be grateful for
advice on what I should do next.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#907199: Should the weboob package stay in Debian?
Martín Ferrari writes ("Re: Should the weboob package stay in Debian?"):
> I am writing on behalf of the Anti-Harassment team, as our input has
> been requested on this issue.
Thanks for your considered and helpful response.
>our recommendation would be to either work with
> upstream on correcting these issues, forking and/or patching it, or just
> removing the package. There is still enough time to find a solution that
> respects our users and our community while keeping a useful piece of
> software in the archive.
That would be great.
Speaking personally I am definitely willing to talk to anyone about
this but ... experience suggests that, despite my best efforts, my
communication style does not lead to happiness in these kind of
situations. I think it would be best if someone else would take the
lead in negotiations.
OTOH if it is necessary to diverge from upstream: I have a lot of
experience with build systems and version control systems and could
probably help with the technical work. I would be tempted to write a
git-filter-branch script, because that would produce a
probably-useable git history and make it easier to handle future
upstream updates.
I am happy to do that technical work if we can agree, within Debian
(including, obviously, the Debian maintainer) on the basic shape.
I look forward to hearing from the Debian maintainer, who I think is
the first point of contact for the management of the package in
Debian.
Thanks,
Ian.
Re: Are we ready to block on autopkgtest regressions?
Niels Thykier writes ("Re: Are we ready to block on autopkgtest regressions?"):
> Ok, I have drafted a section about this in the gobby for a d-d-a mail
> covering this (among other). Please consider reviewing it:
>
> https://gobby.debian.org/export/Teams/Release/Bits
>
> I intend to submit this next week and make 29-30/9 the first weekend to
> have the increased delay assuming there is consensus.
LGTM.
> > Also thought should be given to what `urgency=high' should do
> > Particuarly, given the bugs that mean it is sometimes specified by
> > mistake.
...
> At the moment, I have no plans to change the urgency=high exemption as a
> part of this change. However, I am happy to review/accept patches for
> #831699 now or in the future (which I believe is the issue you are
> referring too). Though, the prerequisite(s) for solving that bug lies
> outside Britney.
Mmm. FTR, I'm afraid I won't have time to work on this in the near
future.
Regards,
Ian.
Re: Are we ready to block on autopkgtest regressions?
Paul Gevers writes ("Are we ready to block on autopkgtest regressions?"):
> Three days ago I opened a merge request against brintey2 [1] to
> enable britney2 to block migrations that cause regressions in
> autopkgtest results in testing. Niels copied it to the IRC channel,
> but we saw no reactions so far from other RT members. We were
> wondering what the opinions in the team are: should we go for it?
> And if not, what anre the issues that you consider to be in need of
> fixing first.
Thanks for pushing this. I do want to see the autopkgtest influence
on migration increase. But:
I think you may be underestimating the degree to which this will need
social as well as technical adjustments. In particular, I don't think
the current increased migration delay approach has fully tested what
will happen when autopkgtest-detected problems actually start to get
seriously in people's way.
Right now if your package migration trips an autopkgtest regression,
this is still not really your problem. You can sit on your hands and
wait for your rdependency's maintainer to swing into action - which
they have to do very promptly. The extra migration delay might be
mildly irritating but the problem will go away before you work up the
energy to argue with anyone about it.
And if you think the problem is a broken test in your rdependency,
there little no point doing more than pointing this out. For example,
a possible response would be to NMU the rdependency. But if one were
to do that according to the existing NMU guidelines, it wouldn't make
much difference to one's own package.
Gradually increasing the extra migration delay would allow us to
gradually increase the proportion of maintainers for whom the
autopkgtest blocking is soemthing they might be motivated to escalate.
Not only would this give us time to further improve the technical
arrangements, but it would allow us to mentor and assist maintainers
unfamilair with the processes, and develop some best practices and
social norms, on a somewhat smaller scale.
I think it is important to work on these aspects before the release
freeze combines with autopkgtest regressions to gore people's oxes
in a higher stakes scenario. So certainly we should be thinking about
this now.
At the risk of overcomplicating things, I suggest replacing the
existing fixed delay with a formula which adds one or two days of
additional migration delay per week of elapsed time, or some such.
Also thought should be given to what `urgency=high' should do
Particuarly, given the bugs that mean it is sometimes specified by
mistake.
Ian.
Re: autopkgtest gating migration, nearly there. But ...
Paul Gevers writes ("autopkgtest gating migration, nearly there. But ..."):
> Let me describe the problem and the current status.
Thanks. I am afraid I didn't quite follow your explanation.
> The migration software (britney2) is now taking versioned
> dependencies, breaks and conflicts of the binary packages from the
> source package that wants to migrate into account when requesting
> the tests. It will add versioned dependencies that are not in
> testing and it will add packages from unstable when their version in
> testing is broken by (or conflicts with) anything needed from
> unstable (recursively).
Do you mean that the format of the test request information from
britney2 to ci.d.n has changed ? IIRC previously it was simply
('please run this in testing', , )
for each proposed migration.
Now it is ... what ?
I don't think I can answer the rest of the email unless I know the
answer to this question, but:
> 2) @builddeps@ is not resolved by dpkg-source, so the migration software
> doesn't know if build-depends should be evaluated for the list
> (currently the migration software doesn't add them). (Possibly "fixable"
> by always evaluating them, or possibly fixable by enhancing dpkg-source).
AIUI what you mean here is this:
* T has tests which Depend on @builddeps@
* T Build-Depends B
* The test trigger machinery in Britney (and upstream of Britney
that calculates Testsuite-Triggers) does not understand that this
means that T Test-Depends B.
* Consequently proposed migration of B might not involve
a rerun of the tests for T with the new B
?
I am reminded of this:
If you declare tests with the needs-build restriction, you will block
the migration of your build-deps when they make your package FTBFS.
But declaring needs-build is said to be undesirable. There is an
obvious anomaly here.
The anomaly I describe above seems similar.
> 3) test dependencies generated by autodep8 are fully unknown to the
> migration software. It seems (but I haven't verified properly) that e.g.
> with r packages the test dependencies can be versioned as well.
I don't know much about autodep8. It sounds like maybe autodep8
should be a way to automatically maintain or help maintain
d/t/control, rather than some post-hoc thing. But I guess everyone
hates committing generated files (which this would imply) too much.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#907199: weboob, Gratuitous sexual references
Thanks for your mail and your attention.
Chris Lamb writes ("Re: Bug#907199: weboob, Gratuitous sexual references"):
> Just as one example from your previous message, you appear to reject
> working with upstream constructively on this, despite a solution
> involving them being beneficial to the entire free software ecosystem
> (not to mention avoiding rehashing a quite tedious and painfully
> predictable debate within Debian itself).
Well, others have definitely been trying that. There is an issue in
the upstream tracker (mentioned in the footnote of Niels's message);
https://git.weboob.org/weboob/devel/issues/154
This was reported in early August and has had no responses from the
upstream maintainers, despite several pings from other people. I
think it is clear that upstream are aware of the complaint but are not
dealing with it (perhaps because it's no fun, or perhaps as deliberate
strategy).
I believe there have also been contacts between the Debian maintainer
and upstream, recently but well before that issue, but again those
don't seem to have produced an outcome I am happy with.
In this context, there is of course this blog posting. But it's from
2013, and maybe views have changed. Certainly I myself have done or
said things 5 years ago which I would take a very different line on
today.
http://laurent.bachelier.name/2013/12/weboob-the-asshole-detector/
So it's true that we don't know for sure what upstream's current view
is on this situation, but that's not because no-one has tried to talk
to them about it.
There is also the issue that I think it would not be a particularly
good idea for me to try to make overtures to upstream. As you note,
my communication style tends to put people's backs up. Happily, other
people have been trying, and it seems better for me not to put my oar
in.
So ultimately I don't know what other efforts you think ought to be
made. If you advise that it would be better for me to try a direct
contact with upstream then I am happy to do so. In which case I would
appreciate a (private) review from someone of my proposed messages.
> You also do not appear to have looped AH in on this, despite them being
> almost-certainly having some kind of viewpoint and de facto weight,
> if not a de jure one.
Did you overlook this email ?
From: Ian Jackson
To: lea...@debian.org
CC: antiharassm...@debian.org
Subject: web-oob "gratuituous sexual references" issue now with d-release
Message-ID: <23422.37882.517223.718...@chiark.greenend.org.uk>
Date: Thu, 23 Aug 2018 12:01:14 +0100
Hi. I thought I should let you know that this is now with the Release
Team. I have asked the RT to rule on the RCness of my bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906119
ITYSBT, in case you want to make some kind of representations to the
Release Team.
Regards,
Ian.
I didn't receive any reply. I also note that you yourself didn't
forward my message to AH as far as I can see. I will do that with
this email, CCing you, right after I send it.
> As an important aside (and I'd like to underline that I don't really
> subscribe to this view myself) it is regrettable that your framing the
> idea of a GR at the moment can be interpreted as an ultimatum or - even
> more tragically - as a threat.
I can see why people might see things that way.
I would be interested to hear from you, how I should ask questions
like:
"does the DPL think there are other useful avenues that we should
try, before a GR"
or
"how would the release team view a GR with an advisory text"
?
But perhaps your comment is directed to my earlier messagess. I do
have a tendency to map out the future possible paths of a dispute
which is perhaps not very helpful. But I think in this case surely
most people could see where this is probably heading.
Anyway, right now I feel I am running out of options. I don't think
delaying resolving this issue is helping very much.
> Putting it another way, whilst drafting a GR is always technically an
> option for a Developer to persue, I highly suspect one gets far more
> traction, collaboration and "buy-in" with the rest of the Debian
> community if one is far less explicit about it.
Thanks for the feedback. I look forward to your advice on the
key question I ask above, namely: what do you think I should do next ?
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#907199: weboob, Gratuitous sexual references
Niels Thykier writes ("Re: Bug#907199: weboob, Gratuitous sexual references"):
> I think the Release Team is the wrong authority for this enquiry.
>
> As I understand it, you feel that weboob (in its current condition) is
> in conflict with Debian's values (e.g. the CoC or the diversity
> statement). The reason why I suspect the release team is the wrong
> authority is that other packages violating Debian's values (namely the
> DFSG) are not shipped in Debian *at all* (i.e. it is not in "main"
> regardless of suite).
Thanks for your consideration. I see where you are coming from.
In this case (and ones like it) I think it would do disproportionate
damage to remove the package from stable suites. So treating this bug
as RC would get quite close to the right practical effect. (As for
unstable, I think it should probably be removed unless it is useful to
keep it there while work is done on fixing this bug.)
> Secondly, even if we *could* make the decision for weboob (or the scope
> of our powers are sufficient for you in this case), I think the project
> is much better served having a separate authority on whether something
> is in line with the CoC/Diversity statement.
I see some force in this argument. (Although I disagree with your
characterisation of this as a "non-package related issue". The
problem is precisely with the content of the package. But it is a
social rather than a technical problem.)
I think I need to look elsewhere. I don't think the Technical
Committee is the right body.
Niels would the RT have a problem with a request (from an appropriate
body, or from the members via a 1:1 GR) to treat this as an RC bug for
release team purposes ? I mean, would you feel that such a request
would be stepping on your toes, or would you welcome it for its
clarity ?
Your suggestion that there might be a "separate authority" does
suggest to me the possibility that you think this is, consitutionally,
something that "no-one else has responsibility for", ie it is in the
DPL's bailiwick and as-yet-undelegated.
Or maybe you think it's ftpmaster's responsibility. Sadly I don't
think it would be a good idea to ask the ftpmaster team to be bear the
political weight of what is going to be a controversial decision
whatever way it goes.
Chris, what do you think ? I think I have nearly run out of things to
try that aren't a GR. I'm sure I can get sponsors for a GR, and help
drafting it. I also hope that it would be sufficient for the GRa to
state some non-binding opinions, which I guess the maintainer and/or
core teams would probably choose to follow. I would not want to try
to decide this on a supermajority.
> Note: Personally, I would very much prefer that upstream accepted
> https://git.weboob.org/weboob/devel/issues/154 and removed the remaining
> insults (if any), so we could put all of this behind us.
That would indeed be great. But it does not seem to be likely.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#907199: weboob, Gratuitous sexual references
Ian Jackson writes ("weboob, Gratuitous sexual references"):
> Dear Release Team, would you please decide whether
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906119
> is, in your opinion, RC ?
Hi. Are you still thinking about this, please ? How long should I
wait for a reply ?
Thanks,
Ian.
Bug#907199: weboob, Gratuitous sexual references
Package: release.debian.org
Control: block 906119 by -1
(I sent this as a plain email, after asking on #debian-release what
the best representation in the BTS would be, but I didn't get a useful
reply, so I am resending this as a bug report without any useful
tags. Sorry for any inconvenience.)
Hi.
Dear Release Team, would you please decide whether
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906119
is, in your opinion, RC ?
(Also, as I imagine this is not so easy, can you please let me know
when I should expect to hear back?)
Marc Dequènes (duck) writes ("Re: Gratuitous sexual references"):
> Control: tag -1 wontfix
> Control: severity -1 wishlist
As I wrote in my initial mail:
| If you as maintainer disagree with my assessment, then we should
| refer the dispute about the bug severity to the Release Team, in
| accordance with usual practice.
So I am doing that now.
I also wrote:
| For the avoidance of doubt: if the Release Team feel the project's
| consensus is not sufficiently clear; or that a removal decision by
| the Release Team would lack legitimacy, I would quite understand.
| In that case the right next step would be a General Resolution. If
| necessary I will propose and/or sponsor a GR to definitively
| establish Debian's view that this package is unacceptable.
Marc suggested the TC. I don't think the TC is appropriate for this
question.
But of course the Release Team could delegate this decision to the TC.
Or, the Release Team might want to informally consult the TC, or other
relevant people in Debian such as the DPL, ftpmaster or the
antiharassment team.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#906119: weboob, Gratuitous sexual references
Hi.
Dear Release Team, would you please decide whether this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906119
is, in your opinion, RC ?
(Also, as I imagine this is not so easy, can you please let me know
when I should expect to hear back?)
Marc Dequènes (duck) writes ("Re: Gratuitous sexual references"):
> Control: tag -1 wontfix
> Control: severity -1 wishlist
As I wrote in my initial mail:
| If you as maintainer disagree with my assessment, then we should
| refer the dispute about the bug severity to the Release Team, in
| accordance with usual practice.
So I am doing that now.
I also wrote:
| For the avoidance of doubt: if the Release Team feel the project's
| consensus is not sufficiently clear; or that a removal decision by
| the Release Team would lack legitimacy, I would quite understand.
| In that case the right next step would be a General Resolution. If
| necessary I will propose and/or sponsor a GR to definitively
| establish Debian's view that this package is unacceptable.
Marc suggested the TC. I don't think the TC is appropriate for this
question.
But of course the Release Team could delegate this decision to the TC.
Or, the Release Team might want to informally consult the TC, or other
relevant people in Debian such as the DPL, ftpmaster or the
antiharassment team.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Thanks again for autopkgtest testing migration gating.
I just wanted to say thank you again for getting this working. I know I have been sending a lot of messages about how things can be improved. That doesn't really reflect how good a change this has been. Now, when I have a package with a good test suite, development speed is very substantially increased. With the reduction in migration delays, I feel closer to (at least some of) my users. The migration delay effect is great in both directions: I feel less need to run very formal (and therefore very time consuming) tests manually on my laptop. (Although I do still find them useful, so they're not out of my workflow completely, and I do do quite thorough ad-hoc testing.) This is good redirection of my time, away from setting up and babysitting tests. And the rdependency testing has already meant that one obscure potential data loss regression, due to complicated interactions between different programs, was detected by my test suite, and fixed, before the affected combinations of software reached testing. With a program which makes heavy use of some of its dependencies, it is good to feel confident that regressions will be detected, and quickly reported to me.[1] I would encourage everyone who can do so, to jump on this bandwagon. Development is so much faster and easier when a solid set of tests stand between you and releasing bugs. Ian. [1] I'm using grep-excuses --autopkgtests for this, which is in very recent versions of devscripts. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: Etiquette about test regression, bug severities, etc.
Niels Thykier writes ("Re: Etiquette about test regression, bug severities,
etc."):
> Ian Jackson:
> > There are some problems with this, though:
> >
> > * The only available bug severity is `serious' which also triggers
> >testing autoremovals. [...]
>
> FTR: If you want to block testing migration, you can simply file the RC
> bug against the unstable version of the package. When the bug only
> affects unstable, britney counts it as a regression and blocks testing
> migration. However, the auto-removal only considers bugs that affect
> testing, so the bug is not going to trigger an auto-removal.
Ah, of course.
> If yes, then move the discussion to which package should be changed to
> resolve the situation. Note that if the reverse dependency is the one
> that need changes to cope, then it often makes sense to file an RC bug
> against *both* packages[1].
...
> For (ii), a regression in the testing will cause a 10 day delay on top
> of the regular urgency under normal circumstances and will eventually be
> a migration blocker.
> If we need a standardized process for blocking uploads in this
> situation, then it smells like we are doing something wrong (acting too
> slow, or focusing on the wrong aspects, etc.).
I guess what I'm saying is that by delaying testing migrations, and by
planning to block them, we are giving the tests quite a high status.
Nearly as high a status as RC bugs. I don't think that's
inappropriate. (And note that the block can be as low as 2 days if
for some reason britney thinks the upload has urgency=high.)
Maybe the right approach is to have a convention that if the
maintainer of the depending package wishes to preserve the status quo
for longer than the current testing migration regression delay[1],
they should file two RC bugs: one against their own (depending)
package, and one against the dependency. And that the maintainer of
the depending package should usually be OK with that - even if the
only problem is a test failure.
Filing an RC bug against the version in testing, and triggering the
autoremoval clock, is a sufficiently disruptive thing to do one of
one's own packages that this wouldn't be done lightly. So there would
be some kind of equity.
Maybe I am belabouring all of this rather too much. But this
autopkgtest testing migration stuff is new and will generate new
behaviours, and we need to establish new social norms. It's probably
better if we write too many mails about it than too few.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored
Julien Cristau writes ("Bug#831699: release.debian.org: urgency is sticky
across dists - low urgency on sid upload ignored"):
> On Wed, Jun 20, 2018 at 15:55:31 +0100, Ian Jackson wrote:
> > I experimented and dpkg-genchanges -vX provides a Changes file with
> > the maximum urgency of any of the included changelog stanzas. So if
> > you say
> >
> >blah (2.0-3) unstable; urgency=low
> >blah (2.0-2) experimental; urgency=high
> >blah (2.0-1) experimental; urgency=medium
> >blah (1.0-1) unstable; urgency=whatever
> >
> > and you (correctly) do your upload of 2.0-3 to unstable with -v1.0-1,
> > the .changes file will say `high', even though from the pov of users
> > of unstable and testing, it ought to be `low'.
>
> Why should it be low? What else would the urgency=high in 2.0-2 mean?
Often, an upload to experimental has quite severe bugs. I think the
`urgency=high' for 2.0-2 means `if you are running 2.0-1 you *really*
want this update'. I think the urgency information can be displayed
in advance of the update by apt, so you can see whether you want to be
bothered. It's also helpful as a very brief summary for humans.
I doubt that many people use `experimental; urgency=high' to mean
`fixes an RC bug present in sid'. That would be an unusual way to
carry on. In those cases it is easy enough to manually make sure that
the upload to sid says `unstable; urgency=high'.
Does that make sense ?
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored
Niels Thykier writes ("Bug#831699: release.debian.org: urgency is sticky across
dists - low urgency on sid upload ignored"):
> Britney does not have access to the changelog directly and it sounds too
> resource intensive to do directly in britney.
I suspected that would be the case.
> There are three alternatives to solving this bug AFAICT:
>
> 1) dak (or a replacement service) excludes urgency entries irrelevant
> for britney, so those entries are never included in the data set.
If the information is provided for the benefit of britney that seems
an obvious solution. AIUI someone with a suitable dak hat is maybe
looking at this now...
> Then orthogonal to these proposals, there is a point about whether the
> entries in the data files should be computed from .changes files or from
> changelog files. It is certainly relevant, but that is a problem that
> should be solved in the service providing the data and not britney.
Indeed so. That's not really a service, it's dpkg-dev. If we agree
on the desired semantics I will file a bug against dpkg-dev. In
practice we might want to get that update into a stable update for
people who are doing their development on stable.
> Hopefully that clarifies the situation.
Thanks, yes, I feel less confused.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored
Adam D. Barratt writes ("Bug#831699: release.debian.org: urgency is sticky
across dists - low urgency on sid upload ignored"):
> On 2018-06-20 15:55, Ian Jackson wrote:
> > What I don't understand is why it is not correct for britney to use
> > the urgency of the actual version it is considering migrating, rather
> > than some other version.
>
> If you upload 1.0-2 containing an RC bug fix, so with "Urgency: high"
> and then, before 1.0-2 has migrated, upload 1.0-3 with default urgency,
> what should happen?
Oh, I see. Sorry, I was being dim.
This seems to suggest that britney ought to do max of all the
urgencies of all the uploads to unstable after (or with higher
version than) the version in testing. Which requires the info from
dak discussed earlier in this bug log.
But I think it *also* requires the change to dpkg-genchanges, because
otherwise the urgency of uploads to unstable can be artificially
inflated there too.
I guess it is too much to hope that britney has access to the
changelog ? If it did it could do its own calculation, which would be
max of the changelog entries *mentioning unstable* between the version
in testing and the version being considered.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#831699: release.debian.org: urgency is sticky across dists - low urgency on sid upload ignored
I have just read this bug report (which affects a situation I care about) and I don't quite understand. Adam writes: > britney knows nothing about changelogs. The input is a strictly > chronological (in terms of when dak accepted the package) list of > source package name, version and urgency tuples for all uploads to > the main archive. What I don't understand is why it is not correct for britney to use the urgency of the actual version it is considering migrating, rather than some other version. Or is that what it does ? I get the impression from what was written in this bug that it does something more complicated, but that may be a misunderstanding. (Sadly no-one copied the actual database information from the original case into the bug log, so it is not now possible to make sense of what is written early in the bug.) I assume that the urgency information reported by dak to britney is that from the .changes file. Is that right ? I experimented and dpkg-genchanges -vX provides a Changes file with the maximum urgency of any of the included changelog stanzas. So if you say blah (2.0-3) unstable; urgency=low blah (2.0-2) experimental; urgency=high blah (2.0-1) experimental; urgency=medium blah (1.0-1) unstable; urgency=whatever and you (correctly) do your upload of 2.0-3 to unstable with -v1.0-1, the .changes file will say `high', even though from the pov of users of unstable and testing, it ought to be `low'. I think that the right fix for this bug is as follows: dpkg-genchanges should not consider as higher-urgency any changelog entries for "unrelated" suites in previous changelog entries that are being included, as a reason to bump the urgency for *this* .changes. (An "unrelated" suite is perhaps one whose ^\w+ is not the same as that of the final, target, suite.) Ie in the examle above, dpkg-genchanges -v1.0-1 should say Urgency: medium. dak should use the Urgency from the .changes file and report that in its /britney/urgencies output. (It may already do this.) britney should use the urgency of the particular package, only. (It may already do this.) An in-archive copy should not be done to move a package into testing, since doing so does not afford anyone the opportunity to specify the proper urgency. (I don't think we do this.) What do others think ? Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Etiquette about test regression, bug severities, etc.
Now that we have autopkgtests blocking testing migration, there is a much stronger incentive for people to keep their tests passing in testing. If one's tests are broken by an update to another package, and the increased britney migration delay doesn't do the job (perhaps the delay is too short, or there is a problem with the ci arrangements) then ideally there would be a bug open against the other package. That bug would stop the migration. There are some problems with this, though: * The only available bug severity is `serious' which also triggers testing autoremovals. Testing autoremovals have very wide visibility - random maintainers of nth-level dependencies are at the very least alerted, and perhaps alarmed or inconvenienced. They can suddenly pop up and need things explaining. That is not helpful. And certainly autoremoving things for such a situation is not appropriate. * By Debian convention the bug severity is a matter for the maintainer of the package the bug is reported against. filing a high-seveerity bug is sometimes seen as hostile. Worse, if the maintainer disagrees about the severity (perhaps they take a different view about some technical details of the bad interaction) the maintainer of broken package has no recourse. IMO we need a bug severity or tag that has the following properties: * The maintainer of a (direct or indirect) rdependency of A is entitled to maintain an open bug, with that tag, against A, even if the maintainer of A disagrees. * Such bugs, when appropriately tagged with fixed and found versions, prevent or *substantially* delay testing migration. In the absence of such a self-help system, would it normally be appropriate to ask the release team to manually defer the migration ? If so then maybe that could be written down somewhere. Also it should probably make clear that such a request should not occur routinely, only if either (i) the maintainers of the packages involved disagree or (ii) the matter is urgent (eg because the dependency package will migrate in the next day or two). Thanks, Ian. -- Ian JacksonThese opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: Summary of discussion regarding improvements needed in autopkgtest and britney
Paul Gevers writes ("Summary of discussion regarding improvements needed in
autopkgtest and britney"):
> 2.a. If autopkgtest is told which packages are needed from unstable
> (even with the exact version) to have a coherent set, it doesn't need to
> guess what is a reasonable solution for britney. Therefore britney could
> output a set of packages from unstable per test, instead of just the
> current trigger.
I think this is by far the best solution to this problem. Britney is
proposing some set of migrations, and that is what ought to be tested.
Having two places where the set of migrations is caclculated is just
asking for disagremeents and, therefore, wrong test results.
> pro:
A `pro' you haven't listed is that because often packages are proposed
for migration in groups, the number of different tests which have to
run may reduce.
Ian.
Re: Proposed (lib)curl switch to openssl 1.1
Ian Jackson writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> > What I suggest above would be a transition that should be coordinated
> > with the release team like other transitions.
>
> I'm not 100% opposed to doing this as a normal library transition with
> a soname change. I don't feel I understand the tradeoffs well.
PS, I should say: thank you for taking an interest and having an
opinion!
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Proposed (lib)curl switch to openssl 1.1
Adrian Bunk writes ("Re: Proposed (lib)curl switch to openssl 1.1"):
> What I suggest above would be a transition that should be coordinated
> with the release team like other transitions.
I'm not 100% opposed to doing this as a normal library transition with
a soname change. I don't feel I understand the tradeoffs well.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Proposed (lib)curl switch to openssl 1.1
(Resending to fix the mail headers, sorry. Please reply to this one, not the previous one.) Hi. You're receiving this mail because you fall into one or more of the following categories: * Are associated with the curl package (To) * Have been involved in discussions I found in the BTS about libcurl and openssl 1.1 (CC), eg in #850880 or #844018 * Maintain a package which calls CURLOPT_SSL_CTX_FUNCTION (CC, "CURLOPT_SSL_CTX_FUNCTION callers") * Are the Release Team (To, see bullet point 3 below) We really need to migrate libcurl to openssl 1.1. This is #858398, which has not seen activity from any libcurl maintainers. I am listed as an Uploader for curl but I haven't done a curl upload and don't really understand the issues well. But, as far as I understand it, the right thing to do is just to change the build-dependencies. I have prepared a patch to do this and intend to upload it to sid on Sunday unless someone explains to my why it's a bad idea. See below. Reasons I am aware that it *might* be a bad idea are: 1. libcurl exposes parts of the openssl ABI, via CURLOPT_SSL_CTX_FUNCTION, and this would be an implicit ABI break without libcurl soname change. This is not good, but it seems like the alternative would be to diverge our soname from everyone else's for the same libcurl. 2. For the reason just mentioned, it might be a good idea to put in a Breaks against old versions of packages using CURLOPT_SSL_CTX_FUNCTION. However, (a) I am not sure if this is actually necessary (b) in any case I don't have a good list of all the appropriate versions (c) maybe this would need coordination. 3. This might be an implicit a "transition" (in the Debian release management sense) which I would be mishandling, or starting without permission, or something. 4. Perhaps not all of libcurl's rdepends can cope with openssl 1.1. However, now is a good time to break them so we discover them and can fix them. It seems to me that now is a good time in the Buster release cycle to take all these risks. If you think uploading this on Sunday would be a bad idea please let me know ASAP. This issue has been festering and obviously we should fix #858398 which is RC for libcurl, but nevertheless I'm prepared to wait a bit longer because (i) I'm not confident I know what I'm doing (ii) I don't think these issues have necessarily been explored properly. If someone else has a better understanding I would be quite happy to hand this issue over to someone else. Failing that, any contribution of relevant facts, opinions, suggestions, etc. would be very welcome. Thanks, Ian. >From 87df3380466355ac58572f5bff93734624fc214a Mon Sep 17 00:00:00 2001 From: Ian Jackson <ijack...@chiark.greenend.org.uk> Date: Thu, 23 Nov 2017 12:49:08 + Subject: [PATCH] Change build-depends to list libssl-dev first. Outcome in sid/buster is to switch to openssl 1.1. I am not changing the soname despite the implied change to the libcurl ABI, because we don't want to make our libcurl have a nonstandard soname. --- debian/changelog | 9 + debian/control | 4 ++-- 2 files changed, 11 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index d5bb5791..f2413cdd 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,12 @@ +curl (7.56.1-2) unstable; urgency=low + + * Change build-depends to list libssl-dev first. Outcome in sid/buster +is to switch to openssl 1.1. I am not changing the soname despite the +implied change to the libcurl ABI, because we don't want to make our +libcurl have a nonstandard soname. + + -- Ian Jackson <ijack...@chiark.greenend.org.uk> Thu, 23 Nov 2017 12:48:48 + + curl (7.56.1-1) unstable; urgency=medium * New upstream release diff --git a/debian/control b/debian/control index 0871ade6..20b33f42 100644 --- a/debian/control +++ b/debian/control @@ -18,7 +18,7 @@ Build-Depends: debhelper (>= 9.20141010~), libpsl-dev, librtmp-dev (>= 2.4+20131018.git79459a2-3~), libssh2-1-dev, - libssl1.0-dev | libssl-dev (<< 1.1), + libssl-dev | libssl1.0-dev, libtool, openssh-server , python:native, @@ -130,7 +130,7 @@ Suggests: libcurl4-doc, libldap2-dev, librtmp-dev, libssh2-1-dev, - libssl1.0-dev | libssl-dev (<< 1.1), + libssl-dev | libssl1.0-dev, pkg-config, zlib1g-dev Multi-Arch: same -- 2.11.0 -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?
Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff
against security?"):
> The source code for gtk-doc.make is itself.
Ah. OK. That's fine then for the stable update.
I think therefore that this should be approved. I hope RMs have time
to formally approve it although we're a bit late now :-/.
> [lots of discussion]
I agree with you that this wider discussion is all out of scope for
the stable update. The question is only the appropriate workarounud
for the situation we have.
Would you mind if I took those aspects of your mail to debian-devel ?
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?
Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff
against security?"):
> On Sat, 15 Jul 2017 at 22:13:14 +0100, Ian Jackson wrote:
> > * document-portal/xdp-dbus.c was generated by a version of
> >gdbus-codegen which seems to be only in Debian experimental. !
>
> This is regenerated at build time. I sent patches upstream to exclude
> it from the distributed orig.tar.gz, which were accepted, so this won't
> be an issue in 0.9.x; but that patch isn't going to be included in the
> 0.8.x stable branch (unless someone from the stable release team asks
> for it) because it isn't a fix for a user-observable bug.
Ah. Indeed. OK, I'm happy about that.
> I can exclude it from future diffs if desired.
I don't think that would be proper.
> > * gtk-doc.make has some noise (which seems to be just whitespace
> >changes but which is a bit hard to review as-is)
>
> gtk-doc.make is copied in from gtk-doc-tools by gtkdocize during the
> upstream autogen.sh run. It isn't currently replaced by dh_autoreconf.
> I could re-run gtkdocize with Debian's gtk-doc-tools at dh_autoreconf
> time if the release team want, but my assumption had been that this
> non-minimal change would be rejected.
It seems to me that this means that the source code for your proposed
updated package is not entirely within Debian. That is, your source
code includes the source in gtk-doc-tools which produces gtk-doc.make.
If I wanted to rebuild your package with an altered gtk-doc.make, I
would need the source to the corresponding gtk-doc-tools. But the
relevant gtk-doc-tools is not in Debian, because it's the one upstream
used to prepare their flatpak "source" package.
So this is, technically, a violation of the licence and of policy.
However, these files are functionally equivalent, because:
> I can confirm that
>
> git diff --ignore-space-change debian/stretch..debian/stretch-proposed --
> gtk-doc.make
>
> eliminates all the changes except for deletion of one blank line,
> and the re-wrapping in the last patch band.
Personally, I would manually rerun gtkdocize on the source package, on
stretch, and include the resulting change as a Debian patch. Then the
resulting patched source tree in stretch-pu would be from Debian
stretch's gtk-doc-tools.
But maybe the release team have a different opinion.
> > This is a bit odd. Are these generated files even though they are in
> > the source package ?
>
> Yes. Blame Autotools.
I think that's unfair on autotools...
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?
Simon McVittie writes ("Re: stretch-pu: package flatpak, maybe want debdiff
against security?"):
> Yes, this update was proposed while stretch was still in freeze,
> and I didn't want to annoy the release team with more pings if they
> were deliberately leaving it dormant until after r1. Diff against
> stretch-security attached (diffing patched tree against patched tree,
> and excluding Autotools noise, translations, HTML docs, and the patches
> that were dropped but not their effects).
Thanks. This is IMO much better. I looked at the diff and almost
everything in it is covered by your changelog entries. However:
* document-portal/xdp-dbus.c was generated by a version of
gdbus-codegen which seems to be only in Debian experimental. !
* gtk-doc.make has some noise (which seems to be just whitespace
changes but which is a bit hard to review as-is)
This is a bit odd. Are these generated files even though they are in
the source package ? Is it possible to exclude these updates
somehow ?
(FTR: I have no other concerns.)
> If the release team would be willing to accept a bit more
> delta, I could also add some patches (accepted and queued to
> be released upstream in 0.8.8) to make this flatpak compatible
> with behaviour changes in buster's libostree, which would
> effectively mean a backport of 0.8.7-2 rather than 0.8.7-1. Please
> let me know whether this is desired. That would basically mean adding
> https://anonscm.debian.org/git/collab-maint/flatpak.git/diff/?id=debian/0.8.7-2=debian/0.8.7-1
> to the diff.
If I were the release team I would prefer not to take that unless we
had to.
> > The only one I'm a bit wary of is this one
> >
> > +- Let KDE apps bind-mount ~/.config/kdeglobals into the sandbox:
> >
> > whose security implications I don't feel I understand. Is there any
> > more discussion of that ?
>
> tl;dr: This has no new security implications.
Jolly good.
Thanks,
Ian.
Bug#863734: stretch-pu: gnupg2
I am not an RM. I have been reviewing some stretch-pu requests in an effort to help out the release managers. I have reviewed this bug log, and taken a look at the debdiff. tl;dr: IMO this update needs better justification. It also requires a greater level of frankness about the downsides or risks of the update. Nevertheless it may be better to take it. Possible COI warning: I have had occasional disagreements with gnupg upstream, relating to my own experiences with gnupg2 in a dgit context. However, I don't think that has affected my opinion on this request. I have given it the same level of scrutiny as my other recent reviews. So: I looked at the debdiff provided in #11. The first thing that struck me was the very large update to scdaemon. I tried to find a discussion of the specific changes, and the potential risks. But I was not able to do so. All we have in the bug report and debdiff is +Backport from master branch: +99d4dfe83 +e2792813a +031e3fa7b +Additionally, fix another bug when tested with 2.1.18-7 with PC/SC. in what appears to be an upstream commit message to a stable branch. The use of the upstream's stable branch requires justification (unless the upstream processes are very high-quality and self-documenting, as I found for example with most of my KDE reviews0. Specifically, using an upstream branch requires consideration of upstream's processes (including any realistic critical analysis which may be relevant). This is so that we can weigh up the risks of updating by taking upstream's branch, vs. by trying to cherry pick individual fixes. The only commentary about this aspect of the update is this: Most fixes are all pulled from upstream to make it easier to integrate future security patches, It is not quite clear to me exactly which upstream branch we are talking ab out (and whether we are talking about an upstream release at all, or a "git fetch"). All of this left me with a lot of unanswered questions. I tried persevering. I found it very difficult to correlate the information found in #863734 with the diffs etc. For example, we have: The bugs addressed include: #862032 #854359 #854829 #834922 #858082 This unblock would also address the concerns rasied around win32-loader by odyx. I went and looked up some of these bugs and many of them do seem to be things we should fix. But relating them to the upstream commits is hard. The comment about win32-loader seems to be a reference to #864973 etc., and the fact that (AFAICT) win32-loader includes gpgv. I don't know what "concerns" there are. My view is that it is for the submitter of a stretch-pu or release unblock request to - make the case - supply all necessary information - frankly disclose any risks of the update - explain the Debian project's alternative choices - provide the RMs and reviewers with good pointers so that the review is easy to conduct Having said all that, there are clearly some important bugfixes here. The risk of delaying may be worse than the risk of taking these changes, even though we don't have the level of confidence we would like. Ian.
Bug#865537: stretch-pu: plasma 5.8.7 LTS pre-approval
(resending with right list address)
Maximiliano Curia writes ("stretch-pu: plasma 5.8.7 LTS pre-approval"):
> The source packages that I would like to update in stretch are:
Thanks. I am not a RM but I am trying to help out by providing review
comments. I have reviewed this request.
tl;dr: Most of them are very good. Two are questionable:
plasma-workspace
plasma-desktop
One caveat for all the packages: they all had big translation updates.
I ignored these. I assume these are fine for stretch-pu.
In each case I have been relying on the accuracy not only of the
provided debdiff but the provided "packaging" diff and upstream
git log. I found the latter particularly helpful - thank you!
Overall I would like to say that I am impressed with the associated
documentation, and what I saw of upstream relase processes. With the
two exceptions I mention above, I was convinced by the thoroughness of
the approach upstream. Even when I didn't understand the code
etc. myself, upstream seemed to be making decisions on the right basis
and with good review.
> bluedevil/4:5.8.7-1+deb9u1
> breeze-gtk/5.8.7-1+deb9u1
> kde-cli-tools/4:5.8.7-1+deb9u1
> kscreenlocker/5.8.7-1+deb9u1
> plasma-pa/4:5.8.7-1+deb9u1
> user-manager/4:5.8.7-1+deb9u1
> kwin/4:5.8.7-1+deb9u1
> libksysguard/4:5.8.7-1+deb9u1
> systemsettings/4:5.8.7-1+deb9u1
These LGTM. I did notice a few things that are IMO not of concern:
The urls
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/kscreenlocker_5.8.4_5.8.7.upstream.gitlog
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/systemsettigns_5.8.4_5.8.7.upstream.gitlog
referred to in the bug report are 404. The urls are wrong and should
be
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/libksysguard_5.8.4_5.8.7.upstream.gitlog
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/systemsettings_5.8.4_5.8.7.upstream.gitlog
Do you generate these requests by hand ?!
Secondly, this in the changelog entry for libksysguard 4:5.8.7-1 is
rather odd:
| * Add new patch: Drop-html-markup-from-polkit-action-file.patch.
| Thanks to Michael Biebl for reporting (Closes: 696905)
...
| * Drop upstream applied patch: Drop-html-markup-from-polkit-action-file.patch
and it confused me briefly.
Now for plasma-workspace and plasma-desktop.
These have a strikingly lower level of explanation in the upstream
commit messages. In many cases I was left wondering whether
- anyone had even considered why or why not this ought to
go to a stable branch, and what its risks might be
- anyone had reviewed the patch
- why it was even being done.
Plus some specific issues:
> plasma-workspace/4:5.8.7-1+deb9u1
There was a lot of noise in the packaging debdiff about the header of
many of the patches. This effectively prevented me from doing a
thorough review, without more admin work.
IMO this needs an explanation, and/or a mechanical verification that
the patches-applied code is unchanged.
> plasma-desktop/4:5.8.7.1-1+deb9u1
The following two changes were particularly questionable IMO:
+ Backport 5.9/Master's GroupDialog code to 5.8.
This brings us to a common baseline on the three active branches
and addresses regressions on the 5.8 branch.
5.9's code added a scrollbar and improved keyboard nav.
Fixes KDE#378042
+ [Task Manager] Keep entry highlighted when context menu or
group dialog is open This makes it easier to see what item the
menu or popup is for. In fact, the item should have stayed
highlighted when the context menu is open but this was broken.
Also, for consistency, use the hover effect also for the group
dialog (it used to be the "active" task).
I think it is probably not practical to separate out these changes
(and indeed other inappropriate ones) from the upstream stable
branches.
I think taken together the changes are probably a net benefit but
there is a nontrivial risk that some of them are more intrusive than
our users expect from Debian sta[b]le.
In any case, the final decision is for the RMs.
Regards,
Ian.
Bug#865537: stretch-pu: plasma 5.8.7 LTS pre-approval
Maximiliano Curia writes ("stretch-pu: plasma 5.8.7 LTS pre-approval"):
> The source packages that I would like to update in stretch are:
Thanks. I am not a RM but I am trying to help out by providing review
comments. I have reviewed this request.
tl;dr: Most of them are very good. Two are questionable:
plasma-workspace
plasma-desktop
One caveat for all the packages: they all had big translation updates.
I ignored these. I assume these are fine for stretch-pu.
In each case I have been relying on the accuracy not only of the
provided debdiff but the provided "packaging" diff and upstream
git log. I found the latter particularly helpful - thank you!
Overall I would like to say that I am impressed with the associated
documentation, and what I saw of upstream relase processes. With the
two exceptions I mention above, I was convinced by the thoroughness of
the approach upstream. Even when I didn't understand the code
etc. myself, upstream seemed to be making decisions on the right basis
and with good review.
> bluedevil/4:5.8.7-1+deb9u1
> breeze-gtk/5.8.7-1+deb9u1
> kde-cli-tools/4:5.8.7-1+deb9u1
> kscreenlocker/5.8.7-1+deb9u1
> plasma-pa/4:5.8.7-1+deb9u1
> user-manager/4:5.8.7-1+deb9u1
> kwin/4:5.8.7-1+deb9u1
> libksysguard/4:5.8.7-1+deb9u1
> systemsettings/4:5.8.7-1+deb9u1
These LGTM. I did notice a few things that are IMO not of concern:
The urls
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/kscreenlocker_5.8.4_5.8.7.upstream.gitlog
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/systemsettigns_5.8.4_5.8.7.upstream.gitlog
referred to in the bug report are 404. The urls are wrong and should
be
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/libksysguard_5.8.4_5.8.7.upstream.gitlog
https://gnuservers.com.ar/~maxy/debian/plasma_5.8.7_stretch-pu/systemsettings_5.8.4_5.8.7.upstream.gitlog
Do you generate these requests by hand ?!
Secondly, this in the changelog entry for libksysguard 4:5.8.7-1 is
rather odd:
| * Add new patch: Drop-html-markup-from-polkit-action-file.patch.
| Thanks to Michael Biebl for reporting (Closes: 696905)
...
| * Drop upstream applied patch: Drop-html-markup-from-polkit-action-file.patch
and it confused me briefly.
Now for plasma-workspace and plasma-desktop.
These have a strikingly lower level of explanation in the upstream
commit messages. In many cases I was left wondering whether
- anyone had even considered why or why not this ought to
go to a stable branch, and what its risks might be
- anyone had reviewed the patch
- why it was even being done.
Plus some specific issues:
> plasma-workspace/4:5.8.7-1+deb9u1
There was a lot of noise in the packaging debdiff about the header of
many of the patches. This effectively prevented me from doing a
thorough review, without more admin work.
IMO this needs an explanation, and/or a mechanical verification that
the patches-applied code is unchanged.
> plasma-desktop/4:5.8.7.1-1+deb9u1
The following two changes were particularly questionable IMO:
+ Backport 5.9/Master's GroupDialog code to 5.8.
This brings us to a common baseline on the three active branches
and addresses regressions on the 5.8 branch.
5.9's code added a scrollbar and improved keyboard nav.
Fixes KDE#378042
+ [Task Manager] Keep entry highlighted when context menu or
group dialog is open This makes it easier to see what item the
menu or popup is for. In fact, the item should have stayed
highlighted when the context menu is open but this was broken.
Also, for consistency, use the hover effect also for the group
dialog (it used to be the "active" task).
I think it is probably not practical to separate out these changes
(and indeed other inappropriate ones) from the upstream stable
branches.
I think taken together the changes are probably a net benefit but
there is a nontrivial risk that some of them are more intrusive than
our users expect from Debian sta[b]le.
In any case, the final decision is for the RMs.
Regards,
Ian.
Bug#865093: stretch-pu review: package mariadb-10.1/10.1.24-0+deb9u1
I looked at this request. tl/dr: it contains undiscussed upstream changes and I think it should be referred back to the submitter for more information. I had some difficulty figuring out what was going on because the pu bug didn't contain an explanation of the changes in the upstream parts of the package. To clarify: the proposal is to upgrade from 10.1_10.1.23-9+deb9u1 to this 10.1.24-0+deb9u1. I wasn't able to find the upstream changelog in the source package. Admittedly I didn't look very hard - I eyeballed the source package. There doesn't seem to be any discussion from the proponent to explain what the upstream changes are and why (or whether) they are desirable. Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#864028: stretch-pu: package flatpak, maybe want debdiff against security?
tl/dr: I started reviewing this request, but didn't finish. The biggest thing I tripped over was that the debdiff is against current stretch, not against stretch-security. So I found myself seeing changes in the diff which had already been made on stretch installations, in practice. Is this normal ? IMO a debdiff against the most recent update, including any security update, would be much more useful. I stopped when I noticed this, so my review was incomplete. But, I found, while reading the diff, that the extra code to fix the permissions code is large and complicated. OTOH I'm not sure we can afford not to have it. OTOH most of the changes described in the changelog sound like ones we would want to take for stretch-updates. The only one I'm a bit wary of is this one +- Let KDE apps bind-mount ~/.config/kdeglobals into the sandbox: whose security implications I don't feel I understand. Is there any more discussion of that ? Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#864027: stretch-pu: review, package swift/2.10.2-1
I have reviewed this request. tl/dr: I recommend approval. I have looked at the debdiff and the changes seem to be as described in the bug report. Almost all of the things described sound very much like important bugfixes. I'm not entirely sure about "Improvements in key parts of the consistency engine" but the approach taken by upstream seem reassuring and if I were the maintainer I think I would choose to take that change too rather than trying to drop it. I did notice that the debdiff contains a fair few test suite changes, including notably what looks like new tests. I am comfortable with that, even though this was not called out in the bug or the changelog. I guess that's just upstream practice. The risk of accepting is course is that there is some bug in these changes - perhaps even a data loss bug. But the fact that this code has been in the upstream stable branch for a month mitigates against that, and the known problems described seem worse than the cure. I did not do a code review in context, and I'm not familiar with the codebase, so I'm not sure that the changes are indeed right. Such a detailed code review exercise seems beyond our realistic capabilities for a stable update. I'm not an ftpmaster and have no formal status. I'm just hoping to be helpful. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#868017: stretch-pu: package dgit/3.11~deb9
Package: release.debian.org Severity: normal Tags: stretch User: release.debian@packages.debian.org Usertags: pu dgit 3.10 has a number of bugs which need to be fixed urgently. I considered them RC for buster and uploaded 3.11 to fix them there. They need to be fixed in stable too. 3.11 has only stable-targeted bugfixes. I would like to rebuild it for stretch-p-u as 3.11~deb9, ASAP. For full details of the changes, please see: git clone https://git.dgit.debian.org/dgit cd dgit git log archive/debian/3.10..archive/debian/3.11 NB that that doesn't contain the proposed changelog entry for 3.11~deb9. That *is* in the attached combined diff. The changes I'm here proposing for stable are to fix these bugs (along with, in many cases, corresponding tests): #857694 "Died at /usr/bin/dgit line 2196." with .xz files This critical bug makes dgit clone and dgit fetch fail for many current packages. It is due to dgit not tolerating the compressor dying with SIGPIPE. That is an expected situation which ought not to cause dgit to bomb out. #867189 combined suite "foo,-security" does not work #867189 cloning a combined suite deletes the working directory Combined suites are an important feature (recommended in dgit-user(7) and required by downstream users). These bugs make this feature quite hard to use (although there are workarounds). Both fixes are to the combined suite code (so cannot break other use cases). Each fix is a single line, but in the case of #867189 quite subtle (as discussed in the commit messages). #865863 Cope with newer git which hates --local outside a working tree Newer git than is in stretch breaks "dgit clone" completely. I consider this a serious bug even for stretch because many people - especially keen git users - will install a newer git (from Debian backports, or from upstream). The fix is annoyingly textuallly large, but conceptually simple. #867702 Cope with new git-receive-pack which has quarantine feature Newer git than is in stretch breaks the backend dgit-infrastructure. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867702#10 for discussion. The workaround is necessary to get the test suite to pass on buster, and I would prefer to send to stretch an identical package of bugfixes to that I have sent to buster in dgit 3.11. The change is confined to dgit-infrastructure; for users using the dgit-infrastructure package from stretch, the arguments about them maybe wanting newer git apply, again. #858054 clone fails if git does not create info/ (eg due to templatedir) This bug is annoying in this use case and risks breaking with future git versions. The fix is extremely simple and low-risk. #867603 dgit-badcommit-fixup: does not respect core.sharedRepository This causes this script to, in a very common case, leave the shared repo with broken permissions which prevent other pushes. I have fixed this in a way that is confined to the prticular script, so users of dgit proper (and who aren't affected by the bug which this script exists to fix) are not at risk from this change. However, an analogous bug affects dgit itself, because dgit also manipulates the user's object store via a special-purpose tree, private to dgit. These object store manipulations ought to honour core.sharedRepository (and some other options which control the object store). (I have also found a couple of other less-critical issues which ought to be fixed in stable, but which can be dealt with in a more leisurely fashion. I won't discuss those further in this bug submission.) Thanks for your attention, Ian. -- System Information: Debian Release: 9.0s APT prefers stable-debug APT policy: (500, 'stable-debug'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) diff --git a/debian/changelog b/debian/changelog index 392f1291..51e03acc 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,36 @@ +dgit (3.11~deb9) stable; urgency=high + + * Rebuild and upload to stretch. + + -- Ian Jackson <ijack...@chiark.greenend.org.uk> Tue, 11 Jul 2017 09:28:15 +0100 + +dgit (3.11) unstable; urgency=high + + Important bugfixes to dgit: + * Fix rpush+buildinfo: Transfer buildinfos for signing. Closes:#867693. + * Cope if the archive server sends an HTTP redirect, +by passing -L to curl. Closes:#867185,#867309. + * Cope with newer git which hates --local outside a tree. Closes:#865863. + * rpush: Honour local git config from build host working tree. + * Tolerate compressor terminating with SIGPIPE. Closes:#857694. + * Honour more pre-tree git config options in our private trees
Bug#861663: unblock: xen/4.8.1-1+deb9u1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package xen
This contains two urgent security patches and nothing else.
unblock xen/4.8.1-1+deb9u1
diff --git a/debian/changelog b/debian/changelog
index 0e6cf0f..5b5896f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+xen (4.8.1-1+deb9u1) unstable; urgency=medium
+
+ * Security fixes for XSA-213 (Closes:#861659) and XSA-214
+(Closes:#861660). (Xen 4.7 and later is not affected by XSA-215.)
+
+ -- Ian Jackson <ian.jack...@eu.citrix.com> Tue, 02 May 2017 12:19:57 +0100
+
xen (4.8.1-1) unstable; urgency=high
* Update to upstream 4.8.1 release.
diff --git a/debian/patches/multicall-deal-with-early-exit-condition
b/debian/patches/multicall-deal-with-early-exit-condition
new file mode 100644
index 000..cc2c560
--- /dev/null
+++ b/debian/patches/multicall-deal-with-early-exit-condition
@@ -0,0 +1,181 @@
+From: Jan Beulich <jbeul...@suse.com>
+Date: Tue, 2 May 2017 12:18:35 +0100
+X-Dgit-Generated: 4.8.1-1+deb9u1 993a6534cae6d9ca2793799cfe369c9b3694ee1e
+Subject: multicall: deal with early exit conditions
+
+In particular changes to guest privilege level require the multicall
+sequence to be aborted, as hypercalls are permitted from kernel mode
+only. While likely not very useful in a multicall, also properly handle
+the return value in the HYPERVISOR_iret case (which should be the guest
+specified value).
+
+This is XSA-213.
+
+Reported-by: Jann Horn <ja...@google.com>
+Signed-off-by: Jan Beulich <jbeul...@suse.com>
+Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
+Acked-by: Julien Grall <julien.gr...@arm.com>
+
+---
+
+--- xen-4.8.1.orig/xen/arch/arm/traps.c
xen-4.8.1/xen/arch/arm/traps.c
+@@ -1531,7 +1531,7 @@ static bool_t check_multicall_32bit_clea
+ return true;
+ }
+
+-void arch_do_multicall_call(struct mc_state *state)
++enum mc_disposition arch_do_multicall_call(struct mc_state *state)
+ {
+ struct multicall_entry *multi = >call;
+ arm_hypercall_fn_t call = NULL;
+@@ -1539,23 +1539,26 @@ void arch_do_multicall_call(struct mc_st
+ if ( multi->op >= ARRAY_SIZE(arm_hypercall_table) )
+ {
+ multi->result = -ENOSYS;
+-return;
++return mc_continue;
+ }
+
+ call = arm_hypercall_table[multi->op].fn;
+ if ( call == NULL )
+ {
+ multi->result = -ENOSYS;
+-return;
++return mc_continue;
+ }
+
+ if ( is_32bit_domain(current->domain) &&
+ !check_multicall_32bit_clean(multi) )
+-return;
++return mc_continue;
+
+ multi->result = call(multi->args[0], multi->args[1],
+ multi->args[2], multi->args[3],
+ multi->args[4]);
++
++return likely(!psr_mode_is_user(guest_cpu_user_regs()))
++ ? mc_continue : mc_preempt;
+ }
+
+ /*
+--- xen-4.8.1.orig/xen/arch/x86/hypercall.c
xen-4.8.1/xen/arch/x86/hypercall.c
+@@ -255,15 +255,19 @@ void pv_hypercall(struct cpu_user_regs *
+ perfc_incr(hypercalls);
+ }
+
+-void arch_do_multicall_call(struct mc_state *state)
++enum mc_disposition arch_do_multicall_call(struct mc_state *state)
+ {
+-if ( !is_pv_32bit_vcpu(current) )
++struct vcpu *curr = current;
++unsigned long op;
++
++if ( !is_pv_32bit_vcpu(curr) )
+ {
+ struct multicall_entry *call = >call;
+
+-if ( (call->op < ARRAY_SIZE(pv_hypercall_table)) &&
+- pv_hypercall_table[call->op].native )
+-call->result = pv_hypercall_table[call->op].native(
++op = call->op;
++if ( (op < ARRAY_SIZE(pv_hypercall_table)) &&
++ pv_hypercall_table[op].native )
++call->result = pv_hypercall_table[op].native(
+ call->args[0], call->args[1], call->args[2],
+ call->args[3], call->args[4], call->args[5]);
+ else
+@@ -274,15 +278,21 @@ void arch_do_multicall_call(struct mc_st
+ {
+ struct compat_multicall_entry *call = >compat_call;
+
+-if ( (call->op < ARRAY_SIZE(pv_hypercall_table)) &&
+- pv_hypercall_table[call->op].compat )
+-call->result = pv_hypercall_table[call->op].compat(
++op = call->op;
++if ( (op < ARRAY_SIZE(pv_hypercall_table)) &&
++ pv_hypercall_table[op].compat )
++call->result = pv_hypercall_table[op].compat(
+ call->args[0], call->args[1], call->args[2],
+ call->args[3], call->args[4], call->args[5]);
+ else
+ call->result = -ENOSYS;
+ }
+ #endif
++
++return unlikely(op == __HYPERVISOR_iret)
++ ? mc_exit
++ : likely(guest_kernel_mode(curr, guest_cpu_user_regs()))
Bug#858164: unblock: chiark-tcl/1.2.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package chiark-tcl This fixes the RC bug #856526 (detected by piuparts of src:sauce). There are no other changes. The source diff is below. unblock chiark-tcl/1.2.1 diff --git a/debian/changelog b/debian/changelog index 1848e82..f002642 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +chiark-tcl (1.2.1) unstable; urgency=high + + * Multiarch: Use correct M-A triplet (DEB_HOST_MULTIARCH) for +libsubdir. Closes:#856526. + + -- Ian Jackson <ijack...@chiark.greenend.org.uk> Sun, 19 Mar 2017 09:22:48 + + chiark-tcl (1.2.0) unstable; urgency=medium * wiringpi module. Built only if the wiringpi headers are actually diff --git a/debian/rules b/debian/rules index f9ed503..3675728 100755 --- a/debian/rules +++ b/debian/rules @@ -26,11 +26,12 @@ docdir=usr/share/doc/$(docpackage) tclh:=$(firstword $(wildcard /usr/include/tcl8.*/tcl.h)) tclversion:=$(patsubst /usr/include/tcl%/tcl.h,%,$(tclh)) +march := $(shell dpkg-architecture -q DEB_HOST_MULTIARCH) +libsubdir = /$(march) + garch := $(shell dpkg-architecture -q DEB_HOST_GNU_TYPE) ifneq ($(garch),) -libsubdir = /$(garch) - ifeq ($(origin CC),default) export CC=$(garch)-gcc endif -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#857257: Re: Supporting configuration file changes between versions in unstable/testing
Adam D. Barratt writes ("Bug#857257: Re: Supporting configuration file changes
between versions in unstable/testing"):
> On 2017-03-09 9:41, Pirate Praveen wrote:
> > I request CTTE to declare this bug as not RC.
>
> That's not something that the Technical Committee has a remit to do.
>
> The determination as to whether a bug is release-critical is delegated
> to the Release Team. So far as I can tell you haven't approached them to
> discuss this, so you can't be asking the TC to override a decision by a
> delegate either, as there hasn't explicitly been one.
To be fair to Pirate, Andreas Beckmann suggested #856606 that if
Pirate disagreed with Andreas, Pirate should go to the TC.
I don't think any of the Release Team have been asked yet.
Sadly, there isn't a "reportbug release.debian.org" category for
"please determine RCness of #". So I am just emailing
debian-release@l.d.o on this mail.
To debian-release:
The question is whether #856606 is RC.
I think you will find the best summary of the arguments in this
message:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856606#37
Ian.
Re: Help requested: Packages which FTBFS randomly
Santiago Vila writes ("Help requested: Packages which FTBFS randomly"):
> The following packages FTBFS for me randomly. First column is the bug
> number, second column is the estimated probability of failure in my
> build environment, which is described here:
IMO all of these bugs should be RC. A randomly-reproducible build
failure with more than negligible probabilty is likely to show up for
some of Debian's users and downstreams and cause them mysterious
trouble. It also causes trouble for stalwarts like Santiago, doing
much needed and largely-unloved QA work.
If there is to be a failure probability threshold I would set it at
10^-4 or so. After all, computer time is cheap.
To the release team: please would you provide a clear answer to
Santiago's question. In particular, please provide an answer (or a
rule which can be used to answer) to each of the 28 bugs mentioned in
Santiago's mail. If you think it will take you a while to answer the
question, please say when you think you will have an answer.
Santiago: please keep up the good work.
Thanks,
Ian.
Bug#854358: unblock: dgit/3.10
Control: tag -1 - moreinfo
Jonathan Wiltshire writes ("Re: Bug#854358: unblock: dgit/3.10"):
> On 2017-02-06 11:30, Ian Jackson wrote:
> > I would like fix some bugs by providing a new dgit in stretch. I have
> > not yet uploaded this package to sid, in case you dislike some of my
> > changes and want an even more minimal update. (If that is the case, I
> > can strip them out and retest, since I have them as individual git
> > commits.)
>
> They look fine. Please go ahead and update this bug when the package is
> in sid.
Thanks. Now uploaded.
FTR, I attach the debdiff, which as promised is identical to the
previous diff apart from the changelog timestamp (and diff formatting
differences; git diff produces some more decoration).
Regards,
Ian.
diff -Nru dgit-3.9/debian/changelog dgit-3.10/debian/changelog
--- dgit-3.9/debian/changelog 2017-01-25 16:21:53.0 +
+++ dgit-3.10/debian/changelog 2017-02-06 17:49:39.0 +
@@ -1,3 +1,25 @@
+dgit (3.10) unstable; urgency=medium
+
+ Bugfixes:
+ * dgit: Copy several user.* settings from main tree git local config
+to dgit private workarea. Closes:#853085.
+ * dgit: Strip initial newline from Changes line from dpkg-parsechangelog
+so as to avoid blank line in commit messages. Closes:#853093.
+ * dgit: Do not fail when run with detached HEAD. Closes:#853022.
+ * dgit: Be much better about commas in maintainer changelog names.
+Closes:#852661.
+
+ Test suite:
+ * quilt-useremail: New test for user config copying (#853085).
+ * lib-import-chk: Test that commits have smae authorship as appears in
+the changelog. (Or, at least, the same authorship set.)
+ * import-maintmangle: New test for changelog Maintainer mangling.
+
+ Documentation:
+ * Fix typos. Closes:#853125. [Nicholas D Steeves]
+
+ -- Ian Jackson <ijack...@chiark.greenend.org.uk> Mon, 06 Feb 2017 17:49:39
+
+
dgit (3.9) unstable; urgency=medium
Improvements:
diff -Nru dgit-3.9/debian/tests/control dgit-3.10/debian/tests/control
--- dgit-3.9/debian/tests/control 2017-01-23 16:20:07.0 +
+++ dgit-3.10/debian/tests/control 2017-02-06 17:49:31.0 +
@@ -29,7 +29,7 @@
Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot,
build-essential
Restrictions: x-dgit-git-only
-Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-asplit
build-modes-gbp-asplit clone-clogsigpipe clone-gitnosuite clone-nogit
debpolicy-dbretry debpolicy-newreject debpolicy-quilt-gbp defdistro-rpush
defdistro-setup distropatches-reject drs-clone-nogit drs-push-masterupdate
drs-push-rejects dsd-clone-nogit dsd-divert fetch-localgitonly
fetch-somegit-notlast gbp-orig gitconfig import-dsc import-native
import-nonnative import-tarbomb inarchivecopy mismatches-contents
mismatches-dscchanges multisuite newtag-clone-nogit oldnewtagalt
oldtag-clone-nogit orig-include-exclude orig-include-exclude-chkquery
overwrite-chkclog overwrite-junk overwrite-splitbrains overwrite-version
protocol-compat push-buildproductsdir push-newpackage push-nextdgit quilt
quilt-gbp quilt-gbp-build-modes quilt-singlepatch quilt-splitbrains rpush
tag-updates test-list-uptodate trustingpolicy-replay unrepresentable version-opt
+Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-asplit
build-modes-gbp-asplit clone-clogsigpipe clone-gitnosuite clone-nogit
debpolicy-dbretry debpolicy-newreject debpolicy-quilt-gbp defdistro-rpush
defdistro-setup distropatches-reject drs-clone-nogit drs-push-masterupdate
drs-push-rejects dsd-clone-nogit dsd-divert fetch-localgitonly
fetch-somegit-notlast gbp-orig gitconfig import-dsc import-maintmangle
import-native import-nonnative import-tarbomb inarchivecopy mismatches-contents
mismatches-dscchanges multisuite newtag-clone-nogit oldnewtagalt
oldtag-clone-nogit orig-include-exclude orig-include-exclude-chkquery
overwrite-chkclog overwrite-junk overwrite-splitbrains overwrite-version
protocol-compat push-buildproductsdir push-newpackage push-nextdgit quilt
quilt-gbp quilt-gbp-build-modes quilt-singlepatch quilt-splitbrains
quilt-useremail rpush tag-updates test-list-uptodate trustingpolicy-replay
unrepresentable version-opt
Tests-Directory: tests/tests
Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot,
build-essential
diff -Nru dgit-3.9/dgit dgit-3.10/dgit
--- dgit-3.9/dgit 2017-01-25 15:43:50.0 +
+++ dgit-3.10/dgit 2017-02-06 17:49:31.0 +
@@ -1699,6 +1699,11 @@
sub mktree_in_ud_here () {
runcmd qw(git init -q);
runcmd qw(git config gc.auto 0);
+foreach my $copy (qw(user.email user.name user.useConfigOnly)) {
+ my $v = $gitcfgs{local}{$copy};
+ next unless $v;
+ runcmd qw(git config), $copy, $_ foreach @$v;
+}
rmtree('.git/objects');
symlink '../../../../objects','.git/objects' or die $!;
Bug#854358: unblock: dgit/3.10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package dgit unblock dgit/3.10 I would like fix some bugs by providing a new dgit in stretch. I have not yet uploaded this package to sid, in case you dislike some of my changes and want an even more minimal update. (If that is the case, I can strip them out and retest, since I have them as individual git commits.) Below you can find a summary of the changes, and references to enable you to review the proposed update in detail. I attach a `git diff' (which is going to be identical to the debdiff of the package I will upload if you approve, modulo changelog timestamp and any updates requested by you). But you may prefer to review the changes as very fine-grained git commits. These are available in my personal git repository at: git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git as the changes 9b2d1c414982a096...e800a2be9f43a049 (aka the changes from current `dgit fetch stretch' to my personal `stable'.) So for example, you could: git clone git://git.chiark.greenend.org.uk/~ianmdlvl/dgit.git cd dgit git-log --reverse --stat -p 9b2d1c414982a096...e800a2be9f43a049 The updates in my proposed 3.10 correspond precisely to the bugs marked "pending" in the BTS. I will summarise them for you: There are three fixes for bugs marked "important": #852661 dgit: fails to fetch when Maintainer has `,` in name This can prevent dgit from being used, at all, on some packages currently in Debian. #853085 ud private tree needs some git config copying from user's This can cause dgit to produce commits containing unintended (but usually not *entirely* wrong) authorship information. #853093 git `3.0 (quilt)' import can generate commits with extra blank line This causes dgit to generate suboptimal commits. (The extra blank line is helpfully ignored by most git tools.) There are two further bugfixes: #853022 dgit fetch can fail on detached head The fix to this is simple and obviously does not disturb existing functionality. This seems likely to be a thing that many users will do, and the error message is quite unenlightening. #853125 fix typos in dgit documentation These seem to me to be covered by the freeze policy. Additionally, the changes include changes to the autopkgtest test suite, to add regression tests for most of the bugfixes. The new tests do not pose a stability or FTBFS risk because the tests are not run during package build. The test suite changes are the changes to tests/ and to debian/tests/control. As part of my usual pre-releaase-preparation I have run this through the test suite both using the ad-hoc in-tree arrangements, and formally via autopkgtest. Thanks four your attention. Regards, Ian. debian/changelog | 22 ++ debian/tests/control | 2 +- dgit | 22 -- dgit-nmu-simple.7.pod | 4 ++-- dgit-user.7.pod| 2 +- tests/lib-import-chk | 13 + tests/tests/import-maintmangle | 41 + tests/tests/quilt-useremail| 27 +++ 8 files changed, 127 insertions(+), 6 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5b674604..24a1bf0d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,25 @@ +dgit (3.10) unstable; urgency=medium + + Bugfixes: + * dgit: Copy several user.* settings from main tree git local config +to dgit private workarea. Closes:#853085. + * dgit: Strip initial newline from Changes line from dpkg-parsechangelog +so as to avoid blank line in commit messages. Closes:#853093. + * dgit: Do not fail when run with detached HEAD. Closes:#853022. + * dgit: Be much better about commas in maintainer changelog names. +Closes:#852661. + + Test suite: + * quilt-useremail: New test for user config copying (#853085). + * lib-import-chk: Test that commits have smae authorship as appears in +the changelog. (Or, at least, the same authorship set.) + * import-maintmangle: New test for changelog Maintainer mangling. + + Documentation: + * Fix typos. Closes:#853125. [Nicholas D Steeves] + + -- Ian Jackson <ijack...@chiark.greenend.org.uk> Sun, 05 Feb 2017 20:50:34 + + dgit (3.9) unstable; urgency=medium Improvements: diff --git a/debian/tests/control b/debian/tests/control index ea79c22d..0df610e7 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -29,7 +29,7 @@ Tests-Directory: tests/tests Depends: dgit, dgit-infrastructure, devscripts, debhelper (>=8), fakeroot, build-essential Restrictions: x-dgit-git-only -Tests: absurd-gitapply badcommit-rewrite build-modes build-modes-asplit build-modes-gbp-asplit clone-clogsigpipe clone-gitnosuite clone-nogit debpolic
Re: Accepted dpkg 1.18.19 (source) into unstable
Hi, Guillem. I'm afraid I find myself writing a critical email.
Guillem Jover writes ("Accepted dpkg 1.18.19 (source) into unstable"):
> Date: Fri, 27 Jan 2017 05:43:36 +0100
> Source: dpkg
> Binary: dpkg libdpkg-dev dpkg-dev libdpkg-perl dselect
AIUI this has missed the deadline for migration into stretch.
Did you intend this for stretch ? If not then I don't think
it was appropriate to upload it to sid.
I have just filed three bugs, at least the first two of which I think
are troubling for stretch:
#852822 signing buildinfo by default breaks compatibility
#852821 Dropping Built-For-Profiles is risky
#852820 Testsuite-Restrictions field is hard to use
If you did intend it for stretch, then I question the wisdom of making
such large changes so close to the deadline. If (as I calculate) you
have missed the formal deadline, you will need a freeze exception.
I think at the very least changes like these:
>* Avoid useless repeated lstat()s in update-alternatives.
>* Only check for debian/tests/control file once in dpkg-source.
...
>* Do not compute the architecture list twice in dpkg-genchanges.
...
>* Perl modules:
...
> - Call anonymous subs via -> operator instead of casting with &, and fix
>bogus POD documentation to match the code.
...
> - Add a new debug() reporting function, and switch code to use it.
> - Add new Dpkg::BuildOption parse_features() method refactored from
>Dpkg::Vendor::Debian.
ought not to get a freeze exception and are unwise at this point in
the release cycle.
Can you clarify your intent ?
Ian.
Re: Bug#850887: [TIMELY for TC members] Interim Ballot Proposal: #850887 binutils mips
Sam Hartman writes ("Bug#850887: [TIMELY for TC members] Interim Ballot
Proposal: #850887 binutils mips"):
> [stuff]
Thanks for pushing this issue, for your IMO correct approach to the
process, and for your clear and straightforward communication.
>
> In #850887, the Debian Technical Committee was asked to choose a
> solution for #840227, a bug that prevents a significant number of
> packages from building on the mips architecture. Given the upcoming
> Stretch freeze, this issue is urgent.
>
> As an interim measure, using its powers under section 6.1.4 of the
> Debian Constitution, the Technical Committee overrules Matthias
> Klose's decision to revert the NMU of binutils fixing #840227. The
> committee requests Lisandro Damián Nicanor Pérez Meyer to make a new
> NMU fixing #840227.
You should explicitly state whether you want this NMU to be DELAYED.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#850196: unblock: dgit/2.14
Package: release.debian.org
Severity: grave
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package dgit
dgit 2.13 has a HIDEOUS bug which causes it to generate malformed git
commits. (#849041) To my surprise, extreme disappointment, and soon
everyone's annoyance, nothing in git (not even the usual git server
code) detected this.
Everyone who is using dgit 2.x must upgrade to 2.14 immediately.
The changes from 2.13 to 2.14 are:
* The changelog.
* The fixes for the two occurrences of this bug.
* Changes to the test suite which I think will avoid any further
bugs of this kind.
The test suite changes are textually large and hard to review, but:
This is a DEP-8 test suite and it is not run during build, so it
cannot cause a FTBFS bug. Furthermore, I have (of course) run it:
both in its ad-hoc mode on stretch and done a formal full-on adt-run
in a sid schroot. It passes (provided I work around the existing bug
#840673 in dput).
I will attach the output of
debdiff dgit_2.{13,14}.dsc >dgit_2.13-2.14.debdiff
debdiff --exclude=test dgit_2.{13,14}.dsc >dgit_2.13-2.14.exclude-test.debdiff
Under the circumstances I hope you agree I have chosen the right
severity for this bug.
unblock dgit/2.14
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru dgit-2.13/debian/changelog dgit-2.14/debian/changelog
--- dgit-2.13/debian/changelog 2016-12-21 01:32:41.0 +
+++ dgit-2.14/debian/changelog 2017-01-04 22:52:55.0 +
@@ -1,3 +1,14 @@
+dgit (2.14) unstable; urgency=critical
+
+ CRITICAL BUGFIX:
+ * Do not generate bogus commits with --overwrite or import-dsc.
+Closes:#849041.
+
+ Test suite:
+ * Run a lot of git-fsck.
+
+ -- Ian Jackson <ijack...@chiark.greenend.org.uk> Wed, 04 Jan 2017 22:52:55 +
+
dgit (2.13) unstable; urgency=high
Changed behaviour:
diff -Nru dgit-2.13/dgit dgit-2.14/dgit
--- dgit-2.13/dgit 2016-12-20 21:34:21.0 +
+++ dgit-2.14/dgit 2017-01-04 22:11:08.0 +
@@ -3538,7 +3538,7 @@
parent $dgitview
parent $archive_hash
author $authline
-commiter $authline
+committer $authline
$msg_msg
@@ -5944,10 +5944,14 @@
progress "Import, merging.";
my $tree = cmdoutput @git, qw(rev-parse), "$newhash:";
my $version = getfield $dsc, 'Version';
+ my $clogp = commit_getclogp $newhash;
+ my $authline = clogp_authline $clogp;
$newhash = make_commit_text <<END;
tree $tree
parent $newhash
parent $oldhash
+author $authline
+committer $authline
Merge $package ($version) import into $dstbranch
END
diff -Nru dgit-2.13/tests/lib dgit-2.14/tests/lib
--- dgit-2.13/tests/lib 2016-12-19 17:32:27.0 +
+++ dgit-2.14/tests/lib 2017-01-04 22:11:07.0 +
@@ -349,6 +349,25 @@
esac
}
+t-git-fsck () {
+ git fsck --no-dangling --strict
+}
+
+t-fscks () {
+ (
+ shopt -s nullglob
+ for d in $tmp/*/.git $tmp/git/*.git; do
+ cd "$d"
+ t-git-fsck
+ done
+ )
+}
+
+t-ok () {
+ t-fscks
+ echo ok.
+}
+
t-rm-dput-dropping () {
rm -f $tmp/${p}_${v}_*.upload
}
diff -Nru dgit-2.13/tests/setup/examplegit dgit-2.14/tests/setup/examplegit
--- dgit-2.13/tests/setup/examplegit 2016-10-31 01:21:59.0 +
+++ dgit-2.14/tests/setup/examplegit 2017-01-04 22:11:07.0 +
@@ -50,4 +50,4 @@
t-setup-done 'p v suitespecs majorv revision' "aq git mirror $p"
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/setup/gnupg dgit-2.14/tests/setup/gnupg
--- dgit-2.13/tests/setup/gnupg 2016-10-30 21:20:28.0 +
+++ dgit-2.14/tests/setup/gnupg 2017-01-04 22:11:07.0 +
@@ -12,4 +12,4 @@
t-setup-done 'GNUPGHOME' 'gnupg'
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/absurd-gitapply dgit-2.14/tests/tests/absurd-gitapply
--- dgit-2.13/tests/tests/absurd-gitapply 2016-11-08 20:40:18.0 +
+++ dgit-2.14/tests/tests/absurd-gitapply 2017-01-04 22:11:07.0 +
@@ -13,4 +13,4 @@
cd $p
grep moo moo
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/build-modes dgit-2.14/tests/tests/build-modes
--- dgit-2.13/tests/tests/build-modes 2016-11-08 20:50:17.0 +
+++ dgit-2.14/tests/tests/build-modes 2017-01-04 22:11:07.0 +
@@ -32,4 +32,4 @@
bm-act-iterate
done
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/build-modes-gbp dgit-2.14/tests/tests/build-modes-gbp
--- dgit-2.13/tests/tests/build-modes-gbp 2016-11-08 20:50:17.0 +
+++ dgit-2.14/tests/tests/build-modes-gbp 2017-01-04 22:11:07.0 +
@@ -36,4 +36,4 @@
bm-act-iterate
done
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/build-modes-sbuild dgit-2.14/tests/tests/build-modes-sbuild
--- dgit-2.13/te
Re: OpenSSL 1.1.0
Jonathan Wiltshire writes ("Re: OpenSSL 1.1.0"):
> On 2016-11-16 12:26, Ian Jackson wrote:
> > If we are going to wind back on this change we should do it ASAP. We
> > should not allow ourselves to make the decision to press on, simply by
> > failing to decide otherwise.
>
> Indeed it's been under discussion for the past week or so independent of
> the thread on -devel. I hope you'll forgive me for not breaking
> confidences just yet, but we expect to be able to resolve this very
> soon.
Excellent, I'm glad to hear that you're discussing it.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: OpenSSL 1.1.0
Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> > Lots of people have posted in this thread that they see problems with
> > our current approach to the openssl transition.
> >
> > Do the openssl maintainers have an response ?
...
> In the absence of input from the openssl maintainers, I would like to
> ask the Release Team's opinion.
I tried to find previous opinions of the release team by reading the
transition bug #827061.
I was not able to find the message where the release team gave
permission for the upload of openssl 1.1.x (in particular, the new
version of libssl-dev) to unstable, that started the transition. Can
someone point me to the formal instruction to upload to unstable ? Or
was permission granted by irc or something ?
The most recent message I can find from a release team member in that
bug report is:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827061#944
That does seem to suggest that in late October the release team had
more or less decided to go ahead.
Reading that bug I think it's a shame that we didn't manage to
effectively identify the issues we've now discussed here on -devel
earlier, despite Kurt's several messages to d-d-a.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: OpenSSL 1.1.0
Ian Jackson writes ("Re: OpenSSL 1.1.0"):
> Lots of people have posted in this thread that they see problems with
> our current approach to the openssl transition.
>
> Do the openssl maintainers have an response ?
I count the following people who expressed concern[1] about this some
time before the 11th of November (last activity from an openssl
maintainer):
Lisandro Damin Nicanor Prez Meyer
Ian Jackson
Pau Garcia i Quiles
Colin Tuckley
Jan Niehusmann
On the 11th Kurt replied, but only to a specific technical aspect of
Jan Niehusmann's message. (On the 10th there was a second openssl
revision upload.) It seems to me that there has been no real answer
to most of those comments, and ample time to do so.
Since then I additionally count the following people who have
expressed concern[1]:
Jan Wagner
Ondřej Surý
Adam Borowski
Russ Allbery
Dimitri John Ledkov
Jan Niehusmann
Adrian Bunk
Scott Leggett
I appreciate that not everyone can be available all of the time, but
a maintainer has a choice of when to initiate a transition and should
arrange to do so at a time when they can be available in a timely
manner to help steward their transition.
A maintainer should be ready to explain, and if necessary change,
decisions they have taken. (Ideally wider consultation before taking
such a decision would be better.)
In the absence of input from the openssl maintainers, I would like to
ask the Release Team's opinion.
If we are going to wind back on this change we should do it ASAP. We
should not allow ourselves to make the decision to press on, simply by
failing to decide otherwise.
If we decide to wind back the transition and the openssl maintainers
continue not to be available (within the short timeframes required),
we have a lot of people who could competently prepare an NMU.
Thanks,
Ian.
[1] I have had to make some judgements about the implications in
people's mails. "Expresse concern" for me includes suggestions that
the current situation would need a substantial slip to the release.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#827061: Processed (with 1 error): block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412 828298 828277
Control: fixed 812166 4.8.0~rc3-0exp1
Control: fixed 812166 4.8.0~rc5-1
Control: unblock 827061 by 812166
Control: clone 812166 -2
Control: retitle -2 consider dropping libssl-dev build-dep
Control: severity -2 normal
Sebastian Andrzej Siewior writes ("Re: Bug#827061: Processed (with 1 error):
block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412
828298 828277"):
> Xen (#812166) is (was) listed as a blocker because it depends on
> `openssl' and according to the bug it can't be build. It could be
> possible that Xen fails to build due to incompatible changes in the
> openssl binary. The rebuild also included the linux package which passed
> (so it is possible that Xen passes, too).
Thanks for looking at this. What you say make sense.
I see that Xen does indeed Build-Depend on libssl-dev. However, none
of the binary packages Depend on anything containing `ssl'. I think
the libssl check in configure.ac and the corresponding libssl-dev
build-dep is cruft. I'm investigating.
So in fact I think, despite appearances, neither src:xen nor any of
the binaries it generates is entangled with openssl.
Anyway, #812166 was fixed upstream in 4.7.0 anyway, so is fixed in
sid/stretch. I'm closing that bug with this message.
Thanks,
Ian.
Bug#827061: Processed (with 1 error): block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412 828298 828277
Debian Bug Tracking System writes ("Processed (with 1 error): block 827061 with
828253 828367 828586 828309 828307 828513 812166 828412 828298 828277"):
> Processing commands for cont...@bugs.debian.org:
>
> > block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412
> > 828298 828277
> Bug #827061 [release.debian.org] transition: openssl
...
> Added blocking bug(s) of 827061: 812166, 828586, 828277, 828367, 828298,
> 828253, 828309, 828412, 828513, and 828307
812166 is nothing to do with openssl AFAICT.
I don't think Xen is involved with the openssl transition.
Did you get the wrong bug ?
Ian.
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
Kurt Roeckx writes ("Re: failed armhf build of xen 4.8.0~rc3-1 [and 1 more
messages]"):
> I just gave back xen and set an extra depends for the fixed
> version.
>
> The chroots get updated on sunday and wednesday. It seems to be
> easier to just wait for wednesday and give back those few that are
> affected. It looks like all buildds actually need the new chroot.
FYI it looks[1] like the libvirt rebuilds for the xen transition have
been afflicted with the same problem, on at least some architectures.
Ian.
[1] eg from
https://buildd.debian.org/status/package.php?p=libvirt=sid
which mentions under "Tail of log for libvirt on armhf":
E: Caught signal ‘Terminated’: terminating immediately
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
Kurt Roeckx writes ("Re: failed armhf build of xen 4.8.0~rc3-1 [and 1 more
messages]"):
> I just gave back xen and set an extra depends for the fixed
> version.
Thanks.
> The chroots get updated on sunday and wednesday. It seems to be
> easier to just wait for wednesday and give back those few that are
> affected. It looks like all buildds actually need the new chroot.
This all seems like quite a lot of palaver for you. Thanks!
Ian.
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
Kurt Roeckx writes ("Re: failed armhf build of xen 4.8.0~rc3-1 [and 1 more
messages]"):
> On Mon, Nov 07, 2016 at 08:05:22PM +, Ian Jackson wrote:
> > Have I done something wrong ? Do the buildd chroots need to be
> > updated ?
>
> The buildd chroots are automatically generated once a week. No
> package that's installed in the chroot get upgraded without a
> reason like a Depends requiring them.
Ah. We were unlucky then that the broken bintuils ended up cached
this way.
> I'll see about upgrading the chroots, I have no idea how to do
> this myself.
Thanks. I do think this should be done, then, as other packages are
likely to be affected.
This probably applies to all the architectures, not just armhf and
i386. The xen package for sid escaped the bug on amd64 because I
built it myself.
Thanks,
Ian.
Bug#842919: failed armhf build of xen 4.8.0~rc3-1 [and 1 more messages]
Debian buildds writes ("failed armhf build of xen 4.8.0~rc3-1"):
> * Source package: xen
> * Version: 4.8.0~rc3-1
> * Architecture: armhf
> * State: failed
> * Suite: sid
> * Builder: hartmann.debian.org
> * Build log:
> https://buildd.debian.org/status/fetch.php?pkg=xen=armhf=4.8.0%7Erc3-1=1478544996=log
Debian buildds writes ("failed i386 build of xen 4.8.0~rc3-1"):
> * Source package: xen
> * Version: 4.8.0~rc3-1
> * Architecture: i386
> * State: failed
> * Suite: sid
> * Builder: x86-grnet-01.debian.org
> * Build log:
> https://buildd.debian.org/status/fetch.php?pkg=xen=i386=4.8.0%7Erc3-1=1478544915=log
These builds failed because they were done with binutils
2.27.51.20161105-1. That version had a severe bug that causes ld to
spin on the cpu (on amd64 and other architectures, apparently).
I uploaded xen 4.8.0~rc3-1 to sid after I observed that my amd64 sid
chroot had obtained 2.27.51.20161105-2 which has the fix. 4.8.0~rc3-1
has no code changes compared to 4.8.0~rc3-0exp2 which built on all
applicable architectures in experimental.
I see from
https://buildd.debian.org/status/package.php?p=binutils=sid
that the fixed version of binutils is showing as "Installed" for armhf
and i386.
Have I done something wrong ? Do the buildd chroots need to be
updated ?
FYI, this is blocking the xen 4.8 transition. (CCing the transition
bug.)
Thanks,
Ian.
Bug#842919: transition: xen (vs. grub2) [and 1 more messages]
Debian FTP Masters writes: > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Sat, 05 Nov 2016 15:08:47 + > Source: xen > Binary: libxen-4.8 libxenstore3.0 libxen-dev xenstore-utils xen-utils-common > xen-utils-4.8 xen-hypervisor-4.8-amd64 xen-system-amd64 > xen-hypervisor-4.8-arm64 xen-system-arm64 xen-hypervisor-4.8-armhf > xen-system-armhf > Architecture: all amd64 source > Version: 4.8.0~rc3-1 Emilio Pozuelo Monfort writes: > I don't plan to binNMU any package that doesn't depend on > libxen-4.6. IOW, only qemu and libvirt will be rebuilt. Please go ahead (unless it needs to wait for xen itself to clear the buildd queues). (There are no sourceful uploads needed for this transition.) Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#842919: closed by Matthias Klose <d...@debian.org> (Re: Bug#842919: ld spins eating cpu)
Control: reopen 842919
Debian Bug Tracking System writes ("Bug#842919 closed by Matthias Klose
<d...@debian.org> (Re: Bug#842919: ld spins eating cpu)"):
> This is an automatic notification regarding your Bug report
> which was filed against the release.debian.org package:
>
> #842919: transition: xen
>
> It has been closed by Matthias Klose <d...@debian.org>.
...-
> 842919: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842919
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> From: Matthias Klose <d...@debian.org>
> To: 842919-d...@bugs.debian.org
> Subject: Re: Bug#842919: ld spins eating cpu
> Date: Sun, 6 Nov 2016 19:41:11 +0100
>
> Version: 2.27.51.20161105-2
Wrong bug number ?
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#842919: ld spins eating cpu
# Package: binutils # Version: 2.27.51.20161105-1 # Severity: important # Control: block 842919 by -1 # -> #843451 # -iwj To reproduce, in an amd64 sid chroot: dgit clone xen experimental cd xen dpkg-buildpackage -uc -b top reports: PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 14434 ian 20 0 19652 7844 3208 R 100.0 0.0 40:21.81 ld This is blocking the xen-4.8 transition. Thanks, Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#842919: transition: xen
Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 05/11/16 01:00, Ian Jackson wrote:
> > Thanks. For the avoidance of doubt, was that an instruction to upload
> > the new version of xen to unstable ?
>
> It is.
Thanks. I will do this as soon as the fixed binutils makes it to my
mirror...
15:58 Urrr. I have an ld process which has used 41 minutes of cpu
time and not finished linking.
15:58 Diziet: known bug in unstable binutils
15:59 Great
15:59 Thanks for the info!
15:59 * Diziet looks in the bts for the bug...
16:00 * bunk didn't report it to the BTS after he debugged it yesterday
evening and Matthias said an upload will come the next day
16:02 The already uploaded 2.27.51.20161105-1 should be fine, I assume.
Thanks to Adrian for the info.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#842919: transition: xen (vs. grub2)
Colin Watson writes ("Re: Bug#842919: transition: xen (vs. grub2)"):
> In any case, I don't think grub2 needs to be rebuilt for this
> transition.
Noted, thanks.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#842919: transition: xen
Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> Control: tags -1 confirmed
...
> Sounds good to me. Please go ahead.
Thanks. For the avoidance of doubt, was that an instruction to upload
the new version of xen to unstable ?
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#842919: transition: xen (vs. grub2)
Hi, grub2 maintainers. I'm CCing you into this conversation in the
hope you can help explain the semantics of the grub2 package's
build-dependency on libxen-dev.
I will quote the whole transition mail:
Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 02/11/16 11:47, Ian Jackson wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Hi. This is the update from Xen 4.6 to Xen 4.8, as previously
> > discussed. (Currently, Xen 4.8.0 RC3. I expect the Xen 4.8.0 release
> > to be out by the time Debian freezes.)
> >
> > libxen-* contains libraries needed for management tools. The
> > corresponding xen-utils-* packages are intended to be coinstallable,
> > so perhaps a "smooth" transition may still be possible ? (Contrary to
> > what the autogenerated transition tracker thinks.)
> >
> > All that is needed from the build-rdeps is a rebuild. That is, of:
> > libvirt qemu xenwatch python-pyxenstore collectd grub2
> >
> > I have checked that they all build against the new libxen{-4.8,-dev},
> > at least on amd64. I don't anticipate trouble on other architectures.
>
> The ben tracker only lists qemu and libvirt as rdeps of the binaries
> that are removed in the new version. Why do the other packages need
> a rebuild? Do any of them statically link libxen or something?
(Emilio will see that I discussed other the packages in another mail.
Also, I am somewhat full of wine right now, so my answers may be
wrong. It seemed better to reply sooner. My work hat can produce
more sober replues tomorrow. Regarding grub2:)
I don't know why grub2 Build-Depends libxen-dev. None of the binaries
in my test-rebuild end up Depending on libxen-4.8.
Perhaps the B-D is just because it needs a copy of the Xen public
headers for the hypervisor API. I doubt it statically links against
libxen* libraries, but I don't think I can entirely rule it out.
There is a binary grub-xen-bin which is probably relevant.
grub-xen-bin contains grub compiled for the Xen PV environment: that
is, to run directly under Xen as part of a guest startup. It will
need header files describing the Xen public ABI. These are the "Xen
public headers", and because of Xen's ABI compatibility guarantees the
normal upstream recommendation is to actually copy those into the
trees of projects which are building binaries to run on Xen. (So for
example Linux has its own - modified - copies.)
If this is the only reason why grub2 Build-Depends libxen-dev then
there is no need to rebuild grub2.
It seems unlikely to me that grub2 could somehow statically link
actual libxen-dev library code (and statically embed it into a grub
binary), but perhaps I'm just not being imaginative enough.
And I guess it is possible that grub2 has some other function which
somehow embeds pieces from libxen-dev.
I hope the grub2 maintainers will be able to shed some light.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
.
Bug#842919: transition: xen
Emilio Pozuelo Monfort writes ("Re: Bug#842919: transition: xen"):
> On 02/11/16 11:47, Ian Jackson wrote:
...
> > All that is needed from the build-rdeps is a rebuild. That is, of:
> > libvirt qemu xenwatch python-pyxenstore collectd grub2
> >
> > I have checked that they all build against the new libxen{-4.8,-dev},
> > at least on amd64. I don't anticipate trouble on other architectures.
>
> The ben tracker only lists qemu and libvirt as rdeps of the binaries
> that are removed in the new version. Why do the other packages need
> a rebuild? Do any of them statically link libxen or something?
(Hi. Thanks for your attention. I am somewhat full of wine right
now, so my answers may be wrong. It seemed better to reply sooner.
My work hat can produce more sober replies tomorrow:)
I got the list from "build-rdeps". Is it wrong ? It's the list of
things which have libxen-dev as a build-dep.
Hrm. I looked at xenwatch and python-pyxenstore and though the source
packages Build-Depend on libxen, the binaries Depend only libxenstore
whose ABI version and package name have not changed. So I think,
then, that there is actually no need to recompile those two, although
it would probably be best to do so as a precaution (in case the ABI
has unwittingly changed, in which case it would be somewhat better for
stretch to be internally consistent).
In my test rebuild, collectd.deb Depends libxen-4.8. My apt-cache
show thinks that sid's current collectd Depends libxen-4.6. I'm not
sure why a collectd rebuild would not be needed.
grub2 is more complicated. I am going to reply separately about that,
CC grub2@p.d.o.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#842919: transition: xen [and 1 more messages]
Ian Jackson writes ("transition: xen"):
> I am filing this transition bug now even though the armhf buildd has
> yet to get to the package. It seems like it nearly 4 days behind
> right now. Instead, I have verified on a porterbox that the armhf
> build is successful. I hope that is sufficient.
As I hoped, all the builds were successful.
Ian.
Bug#842919: transition: xen
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hi. This is the update from Xen 4.6 to Xen 4.8, as previously
discussed. (Currently, Xen 4.8.0 RC3. I expect the Xen 4.8.0 release
to be out by the time Debian freezes.)
libxen-* contains libraries needed for management tools. The
corresponding xen-utils-* packages are intended to be coinstallable,
so perhaps a "smooth" transition may still be possible ? (Contrary to
what the autogenerated transition tracker thinks.)
All that is needed from the build-rdeps is a rebuild. That is, of:
libvirt qemu xenwatch python-pyxenstore collectd grub2
I have checked that they all build against the new libxen{-4.8,-dev},
at least on amd64. I don't anticipate trouble on other architectures.
I am filing this transition bug now even though the armhf buildd has
yet to get to the package. It seems like it nearly 4 days behind
right now. Instead, I have verified on a porterbox that the armhf
build is successful. I hope that is sufficient.
I think the Ben file generated by reportbug from my responses to the
prompts is about right.
Thanks for your attention. Please let me know if I have done anything
wrong. This is the first time I have been responsible for a
transition.
Thanks,
Ian.
Ben file:
title = "xen";
is_affected = .depends ~ "libxen-4.6" | .depends ~ "libxen-4.8";
is_good = .depends ~ "libxen-4.8";
is_bad = .depends ~ "libxen-4.6";
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Re: Xen in stretch - 4.7 or 4.8 ?
Emilio Pozuelo Monfort writes ("Re: Xen in stretch - 4.7 or 4.8 ?"):
> On 19/10/16 17:37, Ian Jackson wrote:
> > There are no changes between 4.7 and 4.8 that would upset any of the
> > rdeps. So, great, thanks.
>
> What about between 4.6 and 4.[78]? As we currently have 4.6 in the archive.
The 4.6 that is currently in stretch is in very bad shape. It could
perhaps be fixed but I don't think it's a good idea. It will have a
very limited upstream support lifetime.
But in any case I don't think 4.7 will be a problem for the rdeps
either. I explicitly checked libvirt (which is the biggest risk) and
it's fine - although it will need a rebuild.
> >
> > I don't know how long it will take me. But I work for Citrix as part
> > of the Xen Project upstream, and this is currently my top priority.
> > So I'm hoping to have something RSN, in a matter of (working) days.
>
> Great! Let us know when you have more news, preferably in a transition bug :-)
Ack.
Regards,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Xen in stretch - 4.7 or 4.8 ?
Emilio Pozuelo Monfort writes ("Re: Xen in stretch - 4.7 or 4.8 ?"):
> On 19/10/16 16:54, Ian Jackson wrote:
> > Sorry to hassle you, but I would appreciate an opinion so that I can
> > get started on the integration work etc.
>
> Assuming the rdeps are fine with Xen 4.8, then I'd be all for moving
> to it.
There are no changes between 4.7 and 4.8 that would upset any of the
rdeps. So, great, thanks.
> Xen is a security sensitive package and I think it'd be good
> to get the extra security support from upstream. Note the transition
> freeze will start soon. Do you have an idea of how long it may take
> to prepare for this?
I don't know how long it will take me. But I work for Citrix as part
of the Xen Project upstream, and this is currently my top priority.
So I'm hoping to have something RSN, in a matter of (working) days.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Xen in stretch - 4.7 or 4.8 ?
Ian Jackson writes ("Xen in stretch - 4.7 or 4.8 ?"):
> Hi. I was wanting an initial opinion from the Release Team, about the
> Xen packages. Currently they are in bad shape in stretch and I intend
> to fix them ASAP.
>
> The question is whether I should move to Xen 4.7, or Xen 4.8.
I just asked the Xen Project's Release Manager and their current best
guess is that Xen 4.8.0 will be released in "early to mid November".
Sorry to hassle you, but I would appreciate an opinion so that I can
get started on the integration work etc.
Thanks,
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Xen in stretch - 4.7 or 4.8 ?
Hi. I was wanting an initial opinion from the Release Team, about the Xen packages. Currently they are in bad shape in stretch and I intend to fix them ASAP. The question is whether I should move to Xen 4.7, or Xen 4.8. Xen 4.8 is currently at RC2 and seems in pretty good shape. I think it's more probable than not that we'll have Xen 4.8.0 by the Debian freeze date, but this is by no means certain. If 4.8.0 arrives after the Debian freeze, then at the Debian freeze stretch will contain a late RC. The only things going into the upstream 4.8 branch after then will be fairly important bugfixes which we would probably want to take for stretch. The biggest improvements in 4.8 compared to 4.7 are improvements to ARM support, including AIUI fairly important overhauls. There are also changes to support the new PVH2 guest mode, which Xen upstream are intending to ultimately replace PV with. There are also more minor features, and some bugfixes which upstream won't backport. Upstream support ends as follows: End of bugfix supportEnd of security support Xen 4.6 [1] Apr 2017 Oct 2018 Xen 4.7 Dec 2018 Jun 2019 Xen 4.8 May/Jun 2019 [2] Nov/Dec 2019 [2] [1] Currently in stretch, in bad shape, we shouldn't release with this. [2] Xen 4.8 support dates are not formally promised yet and will depend on the Xen 4.8.0 release date. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Bug#823460: lightdm: SIGPIPE ignored in session
In stretch, lightdm invokes the user's session with SIGPIPE ignored. This can cause programs with careful error handling to fail. See, for example, #841090. I see that this bug is still outstanding in stretch. To debian-release: The lightdm maintainers disagreed with me about the bug severity. Please would you confirm that this bug is RC. To the lightdm maintainers: I intend to NMU (to DELAYED/7) to apply the patch, unless you object. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
Re: Bug#830978: Browserified javascript and DFSG 2
Sam Hartman writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> [stuff]
There is much that you've said that I don't necessarily disagree with,
but:
> Part of having good governance is to have those discussions on devel.
The problem isn't having the discussion.
The problem is that we keep having the discussion again and again.
The same people rehearse the same points. Over and over.
This is a terrible pattern in our community, because it invites the
more functional people to disengage. They leave -devel, or kill these
threads, because they want to get something useful done.
That leaves the less functional to dominate the discourse. Eventually
we end up with situations where the apparent public discourse elides
large sections of the community, or is even substantially at variance
with the consensus view of the project as a whole.
> The TC isn't going to be able to add anything here. We have similar
> biases to the ftp team. We deal with licenses less often, so they are
> probably even more aware of the issues than we are.
> Having two teams say the same thing isn't going to shut up anyone on
> devel frustrated that we're insisting they do significantly more work.
"Adding" does not necessarily mean disagreeing. If the TC agrees with
ftpmaster, the TC can still help.
The TC can communicate the status quo more clearly, and provide it
with more legitimacy. The TC members are focused on communication.
TC members are (or should be) able to reason and write exceptionally
clearly. The TC has an established mechanism by which it can debate
an issue, vote on it, and publish a clear an authoritative statement
of the collective view.
Now I agree that it would be nice if ftpmaster were better at these
things, but ftpmaster have lots of other things to do besides clear up
these kind of disputes.
Specifically, Pirate has acknowledged the authority of the TC by
asking the TC to intervene. I think it is possibly even rather
disrespectful to Pirate to suggest that if the TC formally disagrees
with them, they'll continue their campaign on -devel as before.
Absent a radical change in the ftpmaster team's approach to
communicating these kind of decisions, the only other way we are going
to settle this is a GR.
To put it another way: could you (the TC) please at least _try_ to
help ? If it doesn't work then little harm is done.
Ian.
Re: Bug#830978: Browserified javascript and DFSG 2
Ian Jackson writes ("Re: Bug#830978: Browserified javascript and DFSG 2"):
> I would like to comment briefly
I'm sorry that I so evidently failed !
Ian.
Re: Bug#830978: Browserified javascript and DFSG 2
Sam Hartman writes ("Bug#830978: Browserified javascript and DFSG 2"):
> Speaking as an individual TC member, here's my personal reading of the
> TC discussion.
>
> It's not clear that the TC is the right body for this discussion. We
> certainly could offer advice, but it's not clear that the ftpmasters or
> release team--the parties most likely to need such advice-- would
> benefit from our advice.
I would like to comment briefly on the general idea about the TC
offering advice and making statements of opinion.
If someone in authority in the project, such as a maintainer of the
ftpmasters or the release team, is doing something which the TC thinks
is wrong, then (if the question is important) I think it would be
entirely appropriate for the TC to issue a statement of opinion,
disagreeing with the other authority.
Conversely, if a contributor has been criticised, they may welcome a
message of support from the TC. That may help lay to rest an
unfounded criticism and save the contributor the energy required to
wonder whether they're really right, rebut any public criticisms, and
so on.
And finally if a question needs authoritative input but the relevant
authority in Debian has not made a clear decision, TC involvement
might help get the matter properly resolved.
In this case I think that it would be worth TC members considering,
for themselves, briefly, and without too much back-and-forth enquiry,
what their initial assessments of the merits of the situation are.
If TC members feel that the submitter of #817092 (Luke, who is
complaining that the aggregated file is not source, along with Ben,
Jonas etc.) are right, they could ask the release team and the
ftpmasters (informally, perhaps) whether the release team would
welcome a supportive TC intervention.
That would allow the TC to help settle this long-running question
(which keeps coming up on -devel and is frankly quite annoying).
This is true even though it seems the specific case of
libjs-handlebars has a more clear-cut problem, as found by Ansgar and
described in #830986.
Concretely, as one of the people who agree with the submitter of
#817092, I would like to see the TC pass a resolution along these
lines:
The TC gives a non-binding statement of opinion:
* The point of having the source code (with an appropriate licence
etc.) is so that all our contributors, downstreams, and users are
able to modify the code and to share their modifications with each
other, with Debian, and with upstream.
* In particular, Debian will often want to share modifications with
upstream, which means that we need to be working with the software
in a form which lets us do so.
* For Debian, therefore, the source code for a file or program is the
form which can be conveniently modified and shared; specifically,
the form in which upstream will accept patches.
* There may be exceptions to this principle but none of them apply in
the case of libjs-handlebars. We do not expect that any such
exception would be applicable to other concatenated or
`browserified' JavaScript files generated with tools like Grunt,
even if the JavaScript output is not minified or obfuscated.
* So in the case of bug #817092 against libjs-handlebars, the
concatened JavaScript is not, in our opinion, source code. This
would remain true even if the parser-generator input mentioned in
bug #830986 were available.
I think this would help save debian-devel a lot of annoying threads.
Ian.
Re: GCC-5 transition will move to testing tonight
Niels Thykier writes ("GCC-5 transition will move to testing tonight"):
> Thanks to Adam, Julien, Jonathan, Matthias, Scott, Simon and many
> others, we are ready to migrate the bulk of the GCC-5 transition and
> related sub-transitions to testing tonight. Apologise for the short notice.
Wow, impressive work to get this done so quickly and with so little
breakage. Well done everyone.
Ian.
Bug#776156: unblock: chiark-tcl/1.1.3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package chiark-tcl. This version fixes a problem with the build-depends which made it FTBFS on jessie (although 1.1.2 built on sid). That is the only change. The debdiff is below. I have also verified with debdiff on my .changes, and with ldd on a sample .so file in the package, that there are no relevant differences to the generated binaries. Thanks, Ian. unblock chiark-tcl/1.1.3 diff -Nru chiark-tcl-1.1.2/debian/changelog chiark-tcl-1.1.3/debian/changelog --- chiark-tcl-1.1.2/debian/changelog 2014-11-09 12:53:58.0 + +++ chiark-tcl-1.1.3/debian/changelog 2015-01-22 19:00:48.0 + @@ -1,3 +1,12 @@ +chiark-tcl (1.1.3) unstable; urgency=low + + * Build-Depends: Add tcl8.5-dev to the front of the list of +possibilities. Current Tcl packages do not provide tcl-dev, and no +earlier version than 8.5 is, in fact, in jessie (8.4 was removed in +April 2014). Closes:#775635. (FTBFS) + + -- Ian Jackson ijack...@chiark.greenend.org.uk Thu, 22 Jan 2015 19:00:22 + + chiark-tcl (1.1.2) unstable; urgency=low * tuntap: Use net/if.h not linux/if.h. Closes:#768766. (FTBFS) diff -Nru chiark-tcl-1.1.2/debian/control chiark-tcl-1.1.3/debian/control --- chiark-tcl-1.1.2/debian/control 2014-11-09 12:33:35.0 + +++ chiark-tcl-1.1.3/debian/control 2015-01-22 17:10:51.0 + @@ -3,7 +3,7 @@ Priority: optional Section: interpreters Standards-Version: 3.9.1 -Build-Depends: libadns1-dev (= 1.2), nettle-dev, libcdb-dev | tinycdb (= 0.75), tcl8.4-dev | tcl8.3-dev | tcl8.2-dev | tcl-dev, debhelper (= 5) +Build-Depends: libadns1-dev (= 1.2), nettle-dev, libcdb-dev | tinycdb (= 0.75), tcl8.5-dev | tcl8.4-dev | tcl8.3-dev | tcl8.2-dev | tcl-dev, debhelper (= 5) Package: libtcl-chiark-1 Architecture: any -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150124181617.21254.85576.report...@zealot.relativity.greenend.org.uk
Re: new pre-dependency: perl{,-base,-modules} - dpkg (= 1.17.17)
Niko Tyni writes (Re: new pre-dependency: perl{,-base,-modules} - dpkg (=
1.17.17)):
On Mon, Jan 19, 2015 at 11:15:04AM +0100, Guillem Jover wrote:
I've not looked into the details yet, but just to comment that there's
been talk about possibly reverting that fix, because in some error
situations it can get apt into an unrecoverable state (#774124). :(
...
(I guess this just calls for both a fixed apt, and a dpkg that
workarounds any such situation.)
Thanks. So do you think I should wait for that to be resolved first?
I don't think so, no.
AFAICS the worst that could happen with such a revert is that the perl
Pre-Depends+Breaks fix stops working and xfonts-traditional 'postinst
triggered' functionality needs to be changed to survive missing
dependencies.
As Guillem said:
Of course reverting that fix brings back all upgrade issues related
to trigger processing w/o the required dependencies. Which are
probably more, and easier to get into.
I agree with Guillem that reverting the triggers dependency fix would
be a worse idea.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/21699.62787.25974.48...@chiark.greenend.org.uk
Re: new pre-dependency: perl{,-base,-modules} - dpkg (= 1.17.17)
Guillem Jover writes (Re: new pre-dependency: perl{,-base,-modules} - dpkg
(= 1.17.17)):
On Sun, 2015-01-18 at 20:12:55 +0200, Niko Tyni wrote:
In order to fix trigger related wheezy-jessie upgrade failures in
xfonts-traditional (#774844, cc'd), I intend to make the main perl
binary packages (perl, perl-base, and perl-modules) Pre-Depend on dpkg
(= 1.17.17), which has this change:
* Defer trigger processing if the package does not fulfill dependencies.
Closes: #671711
Together with making the jessie perl-modules and perl-base Break the
wheezy perl, this should ensure that the xfonts-traditional trigger will
not run when perl is in a broken state during upgrades.
Please see the #774844 bug log for details, and let me know if you have
objections or other suggestions.
Thanks, Niko, I think you have the correct fix. I was meaning to
follow up suggesting a Pre-Depends.
I've not looked into the details yet, but just to comment that there's
been talk about possibly reverting that fix, because in some error
situations it can get apt into an unrecoverable state (#774124). :(
Of course reverting that fix brings back all upgrade issues related
to trigger processing w/o the required dependencies. Which are
probably more, and easier to get into.
Yes.
(I guess this just calls for both a fixed apt, and a dpkg that
workarounds any such situation.)
Do we know what change is needed to apt ?
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21693.9092.311523.933...@chiark.greenend.org.uk
Bug#774627: unblock: xfonts-traditional/1.7.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package xfonts-traditional
This is the last-minute translation update. There are no changes
other than to the es.po Spanish translation file.
unblock xfonts-traditional/1.7.1
debdiff xfonts-traditional_{1.7,1.7.1}_multi.changes =
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
Installed-Size: [-124-] {+122+}
Version: [-1.7-] {+1.7.1+}
The source debdiff is attached.
diff -Nru xfonts-traditional-1.7/debian/changelog xfonts-traditional-1.7.1/debian/changelog
--- xfonts-traditional-1.7/debian/changelog 2014-12-12 00:20:18.0 +
+++ xfonts-traditional-1.7.1/debian/changelog 2015-01-05 14:39:53.0 +
@@ -1,3 +1,10 @@
+xfonts-traditional (1.7.1) unstable; urgency=low
+
+ [ Camale?n noela...@gmail.com ]
+ * Spanish debconf translation update. Closes: #669375.
+
+ -- Ian Jackson ijack...@chiark.greenend.org.uk Mon, 05 Jan 2015 14:39:53 +
+
xfonts-traditional (1.7) unstable; urgency=low
* Use interest-noawait to fix dpkg trigger cycle. Closes: #772860.
diff -Nru xfonts-traditional-1.7/debian/po/es.po xfonts-traditional-1.7.1/debian/po/es.po
--- xfonts-traditional-1.7/debian/po/es.po 2012-06-14 19:43:50.0 +0100
+++ xfonts-traditional-1.7.1/debian/po/es.po 2015-01-05 14:39:27.0 +
@@ -4,197 +4,161 @@
#
# Changes:
# - Initial translation
-# Camale??n noela...@gmail.com, 2010
+# Camalen noela...@gmail.com, 2010
#
# - Updates
#
#
# Traductores, si no conocen el formato PO, merece la pena leer la
-# documentaci??n de gettext, especialmente las secciones dedicadas a este
+# documentacin de gettext, especialmente las secciones dedicadas a este
# formato, por ejemplo ejecutando:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
-# Equipo de traducci??n al espa??ol, por favor lean antes de traducir
+# Equipo de traduccin al espaol, por favor lean antes de traducir
# los siguientes documentos:
#
-# - El proyecto de traducci??n de Debian al espa??ol
+# - El proyecto de traduccin de Debian al espaol
# http://www.debian.org/intl/spanish/
-# especialmente las notas y normas de traducci??n en
+# especialmente las notas y normas de traduccin en
# http://www.debian.org/intl/spanish/notas
#
-# - La gu??a de traducci??n de po's de debconf:
+# - La gua de traduccin de po's de debconf:
# /usr/share/doc/po-debconf/README-trans
# o http://www.debian.org/intl/l10n/po-debconf/README-trans
#
msgid
msgstr
-Project-Id-Version: xfonts-traditional 1.5\n
+Project-Id-Version: xfonts-traditional 1.4\n
Report-Msgid-Bugs-To: xfonts-traditio...@packages.debian.org\n
-POT-Creation-Date: 2012-06-10 21:16+0100\n
-PO-Revision-Date: 2012-06-12 00:09+0200\n
-Last-Translator: Camale??n noela...@gmail.com\n
+POT-Creation-Date: 2012-02-27 07:21+0100\n
+PO-Revision-Date: 2012-04-06 10:08+0200\n
+Last-Translator: Camalen noela...@gmail.com\n
Language-Team: Debian Spanish debian-l10n-span...@lists.debian.org\n
-Language: \n
MIME-Version: 1.0\n
Content-Type: text/plain; charset=UTF-8\n
-Content-Transfer-Encoding: 8bit\n
+Content-Transfer-Encoding: 8bit
#. Type: boolean
#. Description
-#: ../xfonts-traditional.templates:1001
+#: ../xfonts-traditional.templates:2001
msgid Generate traditional versions of fonts?
-msgstr ??Desea generar versiones tradicionales de los tipos de letra?
+msgstr Desea generar versiones tradicionales de los tipos de letra?
#. Type: boolean
#. Description
-#: ../xfonts-traditional.templates:1001
+#: ../xfonts-traditional.templates:2001
msgid
-xfonts-traditional can automatically generate traditional versions (with
-foundry \Trad\ instead of \Misc\) of all fonts for which it has an idea
-about the glyphs. (Currently this is versions of 6x13, aka \fixed\.)
-msgstr
-xfonts-traditional puede generar autom??ticamente las versiones tradicionales
-(con la fundici??n ??Trad?? en lugar de ??Misc??) de todos los tipos de letra de
-los que conoce sus glifos (actualmente comprende las versiones 6x13, tambi??n
-conocidas como ??fixed??).
+With xfonts-traditional it is possible to automatically generate traditional
+versions (with foundry \Trad\ instead of \Misc\) of all fonts where it
+is clear what needs to be done. Currently this means versions of 6x13, also
+known as \fixed\.
+msgstr Con xfonts-traditional se puede generar automticamente las versiones tradicionales (con la fundicin Trad en lugar de Misc) de todos los tipos de letra en los que se sabe con claridad qu es lo hay que hacer. Actualmente comprende las versiones 6x13, tambin conocidas como fixed.
#. Type: boolean
#. Description
-#: ../xfonts-traditional.templates:1001
+#: ../xfonts-traditional.templates:2001
msgid
-But you may prefer not to do
Bug#773652: unblock: chiark-utils/4.4.2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Hi. Please unblock package chiark-utils. Alternatively, please decide that #773650 is not RC. #773650 is: The chiark-utils package is missing a formal copyright licence for nntpid. I know all the authors personally and they intend distribution, but this permission ought to be properly documented in the VCS history and in the Debian package. Note that the offending script `nntpid' is (due to another bug) not currently actually shipped in any .deb. But it is in the source package. The debdiff is below. The changes are: - Add a copyright message to nntpid and the perl module it uses, and a corresponding stanza to debian/copyright (#773650). - Update the copyright year for git-cache-proxy and mention that in debian/copyright. To check that the rebuild has had no deleterious effect, I have debdiffed the .debs, and they all say: File lists identical (after any substitutions) No differences were encountered between the control files Thanks, Ian. unblock chiark-utils/4.4.2 diff -Nru chiark-utils-4.4.1/debian/changelog chiark-utils-4.4.2/debian/changelog --- chiark-utils-4.4.1/debian/changelog 2014-10-27 00:14:34.0 + +++ chiark-utils-4.4.2/debian/changelog 2014-12-21 15:14:10.0 + @@ -1,3 +1,12 @@ +chiark-utils (4.4.2) unstable; urgency=low + + Copyright licencing fixes: + * nntpid: Provice actual licence (dual MIT/GPL3+). Closes:#773650. + * git-cache-proxy: Mention in debian/copyright. + * git-cache-proxy: Update copyright year list to include 2014. + + -- Ian Jackson ijack...@chiark.greenend.org.uk Sun, 21 Dec 2014 15:07:20 + + chiark-utils (4.4.1) unstable; urgency=low Safety and convenience fix: diff -Nru chiark-utils-4.4.1/debian/copyright chiark-utils-4.4.2/debian/copyright --- chiark-utils-4.4.1/debian/copyright 2014-10-26 14:20:47.0 + +++ chiark-utils-4.4.2/debian/copyright 2014-12-21 15:12:51.0 + @@ -69,6 +69,17 @@ Miscellaneous utilities. Copyright 2004,2006 Ian Jackson i...@chiark.greenend.org.uk +nntpid + Utility for finding usenet articles by messageid from an NNTP server + Copyright -2011 Simon Tatham + Copyright 2011 Richard Kettlewell + Copyright 2011 Colin Watson + Copyright 2011 Ian Jackson + Dual licence MIT/GPL3+ + +git-cache-proxy + Copyright 2010 Tony Finch + Copyright 2013,2014 Ian Jackson The chiark utilities are all free software; you can redistribute them and/or modify them under the terms of the GNU General Public License diff -Nru chiark-utils-4.4.1/scripts/ChiarkNNTP.pm chiark-utils-4.4.2/scripts/ChiarkNNTP.pm --- chiark-utils-4.4.1/scripts/ChiarkNNTP.pm2014-10-26 14:14:18.0 + +++ chiark-utils-4.4.2/scripts/ChiarkNNTP.pm2014-12-21 15:11:09.0 + @@ -1,5 +1,31 @@ #!/usr/bin/perl +# Originally by Simon Tatham +# Modified by Richard Kettlewell, Colin Watson, Ian Jackson +# +# Copyright -2011 Simon Tatham +# Copyright 2011 Richard Kettlewell +# Copyright 2011 Colin Watson +# Copyright 2011 Ian Jackson +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the Software), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice shall be included in +# all copies or substantial portions of the Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# SOFTWARE IN THE PUBLIC INTEREST, INC. BE LIABLE FOR ANY CLAIM, DAMAGES OR +# OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +# ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. + use strict qw(subs); use warnings; diff -Nru chiark-utils-4.4.1/scripts/git-cache-proxy chiark-utils-4.4.2/scripts/git-cache-proxy --- chiark-utils-4.4.1/scripts/git-cache-proxy 2014-10-26 14:14:18.0 + +++ chiark-utils-4.4.2/scripts/git-cache-proxy 2014-12-21 15:12:46.0 + @@ -29,7 +29,7 @@ # git-cache-proxy # Copyright 2010 Tony Finch -# Copyright 2013 Ian Jackson +# Copyright 2013,2014 Ian Jackson # # git-cache-proxy is free software; you can redistribute it and/or # modify them under the terms of the GNU General Public License as diff -Nru chiark-utils-4.4.1/scripts/nntpid chiark-utils-4.4.2/scripts/nntpid --- chiark-utils-4.4.1/scripts/nntpid 2014-10-26 14:14:18.0 + +++ chiark-utils-4.4.2/scripts/nntpid 2014-12-21
