Re: Lots of buggy packages propagated to trixie today (?)
On Sun, 22 Oct 2023, Sebastian Ramacher wrote: > Adding owner to the loop: Don, any idea what caused the RC bugs export > to miss all the non-pseudo package RC bugs? Would it be possible to > fail the export in such a case instead of providing partial RC bug > data? Not sure what might have caused that; I'll need to look into it more closely. There are definitely some cases where the status counting seems to be missing set -e where it should have it (and has some race conditions). [I personally haven't gone through every stich of code there, so it's hard to say for a fact.] I'll take a look at the cron output for it shortly to see if I have any better ideas. [And clean up the few cases I see where we're not propogating failures or have non-atomic file creation.] -- Don Armstrong https://www.donarmstrong.com One day I put instant coffee in my microwave oven and almost went back in time. -- Steven Wright
Re: udeb uninstallability trend: worse (+20/-0)
On Mon, 01 Jan 2018, Don Armstrong wrote: > On Mon, 01 Jan 2018, Cyril Brulebois wrote: > > udeb uninstallability watcher <debian-b...@lists.debian.org> (2018-01-01): > > > Newly-broken packages in testing > > > multipath-udeb amd64 arm64 armel armhf i386 > > > mips mips64el mipsel ppc64el s390x > > > partman-multipathamd64 arm64 armel armhf i386 > > > mips mips64el mipsel ppc64el s390x > > > > I'm wondering how this is possible with an RC bug filed against the > > multipath-udeb udeb (#885556). For some reason, it's listed as found in > > multipath-tools/0.7.4-2 on the BTS side, without a version graph; and > > it isn't listed by tracker or by the old PTS. I'm suspecting there's > > something fishy on the BTS side so britney didn't notice the RC bug > > and let it migrate? > > Yeah, this definitely looks like a BTS mistake. It seems to know that > the right versions are in unstable, but they're not showing up on the > graph. OK. Found the issue. Apparently, packages in the */debian-installer components were being skipped when the BTS was figuring out what was in which distribution. I've fixed that now, and the versions database is being updated with that information. The underlying issue should show up as fixed once the version graph for this bug looks sane. [Probably in another 10-20 minutes.] -- Don Armstrong https://www.donarmstrong.com Every gun that is made, every warship launched, every rocket fired signifies [...] a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. [...] This is not a way of life at all in any true sense. Under the cloud of threatening war, it is humanity hanging from a cross of iron. [...] [I]s there no other way the world may live? -- President Dwight D. Eisenhower, April 16, 1953
Re: udeb uninstallability trend: worse (+20/-0)
On Mon, 01 Jan 2018, Cyril Brulebois wrote: > udeb uninstallability watcher <debian-b...@lists.debian.org> (2018-01-01): > > Newly-broken packages in testing > > multipath-udeb amd64 arm64 armel armhf i386 > > mips mips64el mipsel ppc64el s390x > > partman-multipathamd64 arm64 armel armhf i386 > > mips mips64el mipsel ppc64el s390x > > I'm wondering how this is possible with an RC bug filed against the > multipath-udeb udeb (#885556). For some reason, it's listed as found in > multipath-tools/0.7.4-2 on the BTS side, without a version graph; and > it isn't listed by tracker or by the old PTS. I'm suspecting there's > something fishy on the BTS side so britney didn't notice the RC bug > and let it migrate? Yeah, this definitely looks like a BTS mistake. It seems to know that the right versions are in unstable, but they're not showing up on the graph. I'll try to track this down today and see what is going on there. -- Don Armstrong https://www.donarmstrong.com The terrorist's job is to terrorize the people, to interfere with freedom in such a way that disrupts ordinary life and commerce. With due respect, it is clear that the above referenced governmental agencies are aiding the terrorists' objective. -- Gary Fielder in Gary Fielder vs Janet Napolitano et al.
Bug#863211: unblock: perltidy/20140328-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package perltidy
Fixes an important security bug (CVE-2016-10374) #862667 by erroring
out. [The bug is severity important, but should be fixed.]
unblock perltidy/20140328-2
-- System Information:
Debian Release: 9.0
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64
(x86_64)
Kernel: Linux 4.10.0-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru perltidy-20140328/debian/changelog perltidy-20140328/debian/changelog
--- perltidy-20140328/debian/changelog 2014-04-07 18:27:20.0 -0700
+++ perltidy-20140328/debian/changelog 2017-05-21 12:41:30.0 -0700
@@ -1,3 +1,10 @@
+perltidy (20140328-2) unstable; urgency=high
+
+ * Backport fix for CVE-2016-10374 which fixes insecure file deletion of
+perltidy.ERR and perltidy.LOG files (closes: #862667)
+
+ -- Don Armstrong <d...@debian.org> Sun, 21 May 2017 12:41:30 -0700
+
perltidy (20140328-1) unstable; urgency=medium
* New upstream release
diff -Nru perltidy-20140328/debian/patches/die_on_unlink_failures
perltidy-20140328/debian/patches/die_on_unlink_failures
--- perltidy-20140328/debian/patches/die_on_unlink_failures 1969-12-31
16:00:00.0 -0800
+++ perltidy-20140328/debian/patches/die_on_unlink_failures 2017-05-21
12:39:07.0 -0700
@@ -0,0 +1,30 @@
+Description: die if perltidy.ERR and other temporary files cannot be unlinked
+Origin: Upstream, Cherrypicked from 20170521.
+Author: Don Armstrong <d...@debian.org>, Steve Hancock
+--- a/lib/Perl/Tidy.pm
b/lib/Perl/Tidy.pm
+@@ -3643,7 +3643,10 @@
+ # now wish for luck...
+ my $msg = qx/perl $flags $quoted_stream_filename $error_redirection/;
+
+-unlink $stream_filename if ($is_tmpfile);
++if ($is_tmpfile) {
++unlink $stream_filename
++ or Perl::Tidy::Die("couldn't unlink stream $stream_filename: $!\n");
++}
+ return $stream_filename, $msg;
+ }
+
+@@ -4074,7 +4077,11 @@
+
+ # remove any old error output file if we might write a new one
+ unless ( $fh_warnings || ref($warning_file) ) {
+-if ( -e $warning_file ) { unlink($warning_file) }
++if ( -e $warning_file ) {
++unlink($warning_file)
++ or Perl::Tidy::Die(
++"couldn't unlink warning file $warning_file: $!\n");
++}
+ }
+
+ my $logfile_gap =
diff -Nru perltidy-20140328/debian/patches/series
perltidy-20140328/debian/patches/series
--- perltidy-20140328/debian/patches/series 2014-04-07 18:23:44.0
-0700
+++ perltidy-20140328/debian/patches/series 2017-05-21 12:38:51.0
-0700
@@ -1 +1,2 @@
+die_on_unlink_failures
document_bst_better
Bug#827061: Processed (with 1 error): block 827061 with 828253 828367 828586 828309 828307 828513 812166 828412 828298 828277
On Tue, 15 Nov 2016, Apollon Oikonomopoulos wrote:
> Hi Ian,
>
> On 11:16 Tue 15 Nov , Ian Jackson wrote:
> > 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 ?
>
> I'm terribly sorry for this mess. I re-added the block that was
> accidentally removed after cloning(!) #828286, and it appears that
> #812166 was previously a blocker[1].
>
> On a side note, I have no idea why the BTS removed all blocking bugs on
> #827061 after cloning just one of them, and it turns out it did so on
> two occasions, my clone[2] and Adrian's one[3].
Hrm; that's not supposed to happen.
Let me check that out and see if I can fix it.
--
Don Armstrong https://www.donarmstrong.com
Information wants to be free to kill again.
-- Red Robot http://www.dieselsweeties.com/archive.php?s=1372
bugscan doesn't obey Extra-Source-Only: yes (and debbugs probably doesn't either)
Package: bugs.debian.org Severity: important On Sat, 30 Jul 2016, Francesco Poli wrote: > On Mon, 25 Jul 2016 22:03:36 +0200 Francesco Poli wrote: > > > On Mon, 25 Jul 2016 10:41:08 -0500 Don Armstrong wrote: > [...] > > > OK, this is going to take a bit of work; I think the short-term answer > > > is for the BTS to completely ignore source entries which are > > > Extra-Source-Only: yes > > > > > > I'll try to get to that shortly so we don't have more bad migrations > > > like this in the future. > > > [...] > > And thanks to you, Don, for your willingness to fix the issue soon. > > Hello Don, any progress on this issue? I haven't had a chance to work on the code in bugscan yet, unfortunately. I'm going to try to get to it this week. > Would you like to have an actual bug report filed against debbugs, in > order to track the issue more easily? Sure, done with this email. -- Don Armstrong https://www.donarmstrong.com Live and learn or die and teach by example -- a softer world #625 http://www.asofterworld.com/index.php?id=625
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Mon, 25 Jul 2016, Adam D. Barratt wrote: > [dropped #830267 from CC; it's not directly relevant to this branch of the > discussion] > > On 2016-07-24 17:43, Don Armstrong wrote: > >On Sun, 24 Jul 2016, Francesco Poli wrote: > [...] > >>could you please investigate on what happened to bug #830267 on > >>2016-07-19T10:00 ? > >> > >>Please take a look at > >>https://bugs.debian.org/830267#20 > >>https://bugs.debian.org/830267#25 > >>for more context. > > > >Hrm; it was shown as affecting testing at T0600 (and all subsequent > >runs): > > > >status-201607190600:number=830267 > >status-201607190600-testing=1 > >status-201607190600-unstable=1 > > > >but not on the immediately preceding run: > [...] > >That's really odd; I haven't changed anything on the BTS side during > >that time period which would explain that happening. > > > >Unfortunately, I don't know when the BTS thought that 1.18.9 was > >actually in testing and not in unstable. I'll try to check out snapshots > >later this week to see if I can figure out when the transition actually > >happened, or if there was something else going on in the archive to > >explain it. > > Does the BTS take account of entries in Sources marked > "Extra-Source-Only: yes" when determining bugginess? No, we totally ignore that field. > If so, a possible explanation is that debsig-verify 0.15 migrated to > testing overnight on the 18th/19th. The binary packages have > "Built-Using: dpkg (= 1.18.9)", which would have led dak to add the > corresponding source package to testing with an E-S-O marker. Ah. Yep, that definitely explains it. OK, this is going to take a bit of work; I think the short-term answer is for the BTS to completely ignore source entries which are Extra-Source-Only: yes I'll try to get to that shortly so we don't have more bad migrations like this in the future. -- Don Armstrong https://www.donarmstrong.com "I always tend to assume there's an infinite amount of money out there." "There might as well be, [...] but most of it gets spent on pornography, sugar water, and bombs. There is only so much that can be scraped together for particle accelerators." -- Neal Stephenson _Anathem_ p262
Re: Bug#830267: dpkg: Segmentation fault when purging package in APT test case
On Sun, 24 Jul 2016, Francesco Poli wrote:
> On Sun, 24 Jul 2016 16:24:19 +0100 Jonathan Wiltshire wrote:
>
> > On 2016-07-24 16:00, Francesco Poli wrote:
> [...]
> > > Should <owner@bugs.d.o> be contacted, perhaps?
> >
> > Sure, if you'd like to.
>
> Dear BTS owner,
> could you please investigate on what happened to bug #830267 on
> 2016-07-19T10:00 ?
>
> Please take a look at
> https://bugs.debian.org/830267#20
> https://bugs.debian.org/830267#25
> for more context.
Hrm; it was shown as affecting testing at T0600 (and all subsequent
runs):
status-201607190600:number=830267
status-201607190600-testing=1
status-201607190600-unstable=1
but not on the immediately preceding run:
status-20160719:number=830267
status-20160719-testing=0
status-20160719-unstable=1
(You can check this out with grep -C 14 number=830267
/srv/bugs.debian.org/bugscan/stati/status-201607{19,20}*; on buxtehude or by
getting those status files from the web interface and examining them.)
That's really odd; I haven't changed anything on the BTS side during
that time period which would explain that happening.
Unfortunately, I don't know when the BTS thought that 1.18.9 was
actually in testing and not in unstable. I'll try to check out snapshots
later this week to see if I can figure out when the transition actually
happened, or if there was something else going on in the archive to
explain it.
--
Don Armstrong https://www.donarmstrong.com
Americans can always be counted on to do the right thing, after they
have exhausted all other possibilities.
-- W. Churchill
Re: Bug#746005: guile-2.0 migration
On Fri, 29 Apr 2016, Emilio Pozuelo Monfort wrote: > We talked about this on the RT meeting yesterday and agreed to bump > this to RC again. We wouldn't like to release Stretch with guile-1.8 > just for lilypond's sake, and it is better to act now that there's > plenty of time before the freeze so that a new version can be uploaded > (possibly to experimental for the time being) and fixes can be > applied. OK. Basically, there's no way that 2.18 will be fixed to work with Guile 2.0, but assuming that 2.20 gets released before stretch, this will be workable. > We can discuss this again later in the cycle if necessary, though > hopefully lilypond can get in shape and we won't need to do that :) Well, the shape that will be required is the release of a stable lilypond release which supports guile. Hopefully soon. > There have been plenty of 'unstable' releases (last one was 2.19.40 > just a few days ago) and those have a --with-guile2 configure switch. > It may be a good idea to upload that to experimental with guile 2.0 > support? Sure, but this won't fix the version of lilypond in unstable. [I at least do not have the time to support a development release of lilypond through the lifetime of a stable release.] Are auto-removals from testing currently off? [Basically, I'd like to avoid having lilypond removed from testing until we're closer to the release if that's at all possible.] -- Don Armstrong https://www.donarmstrong.com A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia
Bug#765639: Bug#802159: New OpenSSL upstream version
On Sat, 31 Oct 2015, Kurt Roeckx wrote: > On Fri, Oct 30, 2015 at 02:38:13PM -0700, Don Armstrong wrote: > > On Tue, 20 Oct 2015, Don Armstrong wrote: > > > If there's something specific that you'd like the CTTE to try to do > > > beyond what I've just reported now, let me know. > > > > Let me know if you'd like the CTTE to do something beyond what I've > > already done. > > I guess I would like to know what the options are. The way I see > it: > - The release team makes a decision > - The release team asks someone else to make the decision If the SRMs want to delegate their decision to the CTTE in this specific case, they can, and then the CTTE would be able to decide. > - Someone makes a policy of what is acceptable, not the current > situtation where there don't seem to be any rules. This doesn't require the CTTE itself, though certainly we could be tasked with suggesting a policy. I'd much rather have the SRMs task a specific individual with this, though. In this specific case, the specific set of changes which have been made, coupled with documenting the policy of upstream for testing and making changes to openssl would be a good start. This is necessary for the SRMs (or CTTE if delegated) to decide, and would be a basis for someone else developing a policy for newer upstream revisions in stable. -- Don Armstrong http://www.donarmstrong.com An elephant: A mouse built to government specifications. -- Robert Heinlein _Time Enough For Love_ p244
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, 20 Oct 2015, Don Armstrong wrote: > If there's something specific that you'd like the CTTE to try to do > beyond what I've just reported now, let me know. Let me know if you'd like the CTTE to do something beyond what I've already done. -- Don Armstrong http://www.donarmstrong.com
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, 20 Oct 2015, Kurt Roeckx wrote: > So as already pointed out before, since the 1.0.0 release there is a > new release strategy that in the 1.0.x series, where x doesn't change, > no new features are added unless it's really needed for either > security reasons or compatibility reasons. As far as I know between > the version in oldstable (a patched 1.0.1e) and 1.0.1p only 1 feature > got added, and people really have been asking for that one. > > OpenSSL upstream also already has a policy that at least 2 people from > the team should review all the changes. Since there are so many > changes I don't think it's reasonable for the release team to review > all of them. It certainly doesn't seem reasonable to expect the SRMs to review line by line, but maybe a summary of the changes would help them make a decision? > The alternative is that I go and cherry pick the important bug fixes. > By this time there are really a lot that I would like to have in the > stable releases and I think going that way actually has a higher > chance of breaking things. Right. SRMs: what would be the best way for Kurt to move forward? Would a list of the specific bug fixes and additional features be enough for an initial yes/no, given the review process upstream? -- Don Armstrong http://www.donarmstrong.com There is no more concentrated form of evil than apathy.
Bug#765639: Bug#802159: New OpenSSL upstream version
On Tue, 20 Oct 2015, Don Armstrong wrote: > On Sat, 17 Oct 2015, Kurt Roeckx wrote: > > I've been waiting for the release team for a while to make a decision > > on #765639 for a year now. Could you help in getting a decision? > > > > I've actually been waiting for longer than that, I can't directly find > > all links, but previous discussions about it are at least: > > https://lists.debian.org/debian-devel/2013/09/msg00466.html > > https://lists.debian.org/debian-project/2013/12/msg00140.html > > Is there anything that it would be helpful for the technical committee > to do here to help facilitate coming to a decision on this? From discussions (briefly) on IRC: my general thoughts offhand are that new upstream versions in stable always make me twitchy, new upstream versions that introduce features or are sensitive / important packages more so, new upstream versions that do both doubly. and we try and avoid ending up saying no to people, which often ends up actually making things worse as they linger (and we're not doing that well at keeping up with the "easy" requests right now) So from what I'm gathering, this looks like a case where there isn't enough eyeballs to adequately review this particularly set of updates, coupled with the importance of making sure that these updates are correct and don't cause any unintended issues. There was some discussion of whether a more concrete process might help alleviate the time requirements of these reviews, but I think that's something for the stable release managers (and other interested parties) to hash out. If there's something specific that you'd like the CTTE to try to do beyond what I've just reported now, let me know. -- Don Armstrong http://www.donarmstrong.com Where I sleep at night, is this important compared to what I read during the day? What do you think defines me? Where I slept or what I did all day? -- Thomas Van Orden of Van Orden v. Perry
Bug#765639: Bug#802159: New OpenSSL upstream version
On Sat, 17 Oct 2015, Kurt Roeckx wrote: > I've been waiting for the release team for a while to make a decision > on #765639 for a year now. Could you help in getting a decision? > > I've actually been waiting for longer than that, I can't directly find > all links, but previous discussions about it are at least: > https://lists.debian.org/debian-devel/2013/09/msg00466.html > https://lists.debian.org/debian-project/2013/12/msg00140.html Is there anything that it would be helpful for the technical committee to do here to help facilitate coming to a decision on this? Specifically, this being (FWICT), bringing a new(er) version of openssl into jessie and/or wheezy. I personally don't have enough information to form an opinion yet, but I recognize that some decision should be made. -- Don Armstrong http://www.donarmstrong.com Rule 30: "A little trust goes a long way. The less you use, the further you'll go." -- Howard Tayler _Schlock Mercenary_ March 8th, 2003 http://www.schlockmercenary.com/d/20030308.html
Bug#777570: unblock: debbugs/2.4.1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package debbugs
This fixes the RC bug #775053 where examples in
/usr/share/doc/debbugs/examples were parsed in the postinst to
generate config files. This is pretty broken in general, but this
minimal fix fixes the issue until I really fix it with a new release
for jessie+1.
diff -Nru debbugs-2.4.1/debian/changelog debbugs-2.4.1.1/debian/changelog
--- debbugs-2.4.1/debian/changelog 2003-06-06 01:28:51.0 -0700
+++ debbugs-2.4.1.1/debian/changelog2015-02-05 09:37:34.0 -0800
@@ -1,3 +1,11 @@
+debbugs (2.4.1.1) unstable; urgency=medium
+
+ * Move examples out of /usr/share/doc/debbugs/examples which are parsed
+in postinst to /usr/share/debbugs/examples. Thanks to Vagrant
+Cascadian for the patch. (Closes: #775053).
+
+ -- Don Armstrong d...@debian.org Wed, 04 Feb 2015 18:04:08 -0800
+
debbugs (2.4.1) unstable; urgency=low
* Colin Watson:
diff -Nru debbugs-2.4.1/debian/control debbugs-2.4.1.1/debian/control
--- debbugs-2.4.1/debian/control2003-06-05 19:26:20.0 -0700
+++ debbugs-2.4.1.1/debian/control 2015-02-05 07:17:08.0 -0800
@@ -2,7 +2,7 @@
Section: misc
Priority: optional
Maintainer: Debbugs developers debian-debb...@lists.debian.org
-Uploaders: Josip Rodin jro...@jagor.srce.hr, Colin Watson
cjwat...@debian.org
+Uploaders: Don Armstrong d...@debian.org
Standards-Version: 3.2.1
Build-Depends-Indep: debhelper
diff -Nru debbugs-2.4.1/debian/debbugsconfig
debbugs-2.4.1.1/debian/debbugsconfig
--- debbugs-2.4.1/debian/debbugsconfig 2002-11-25 04:34:56.0 -0800
+++ debbugs-2.4.1.1/debian/debbugsconfig2015-02-04 18:08:27.0
-0800
@@ -72,7 +72,7 @@
sub template {
my ($name, $destdir) = @_;
if (! -f $destdir/$name) {
- system(cp /usr/share/doc/debbugs/examples/$name $destdir/$name) == 0 ||
+ system(cp /usr/share/debbugs/examples/$name $destdir/$name) == 0 ||
die $!;
print created $destdir/$name from template.\n;
}
diff -Nru debbugs-2.4.1/debian/dirs debbugs-2.4.1.1/debian/dirs
--- debbugs-2.4.1/debian/dirs 2002-11-17 09:09:40.0 -0800
+++ debbugs-2.4.1.1/debian/dirs 2015-02-04 18:08:27.0 -0800
@@ -2,7 +2,7 @@
etc/debbugs/indices
usr/lib/debbugs
usr/sbin
-usr/share/doc/debbugs/examples
+usr/share/debbugs/examples
var/lib/debbugs/indices
var/lib/debbugs/www/cgi
var/lib/debbugs/www/db
diff -Nru debbugs-2.4.1/debian/rules debbugs-2.4.1.1/debian/rules
--- debbugs-2.4.1/debian/rules 2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1.1/debian/rules2015-02-04 18:08:27.0 -0800
@@ -28,6 +28,7 @@
$(MAKE) install_mostfiles DESTDIR=$(tmp_dir)
dh_installdocs
dh_installchangelogs
+ dh_link usr/share/debbugs/examples usr/share/doc/debbugs/examples
dh_strip
dh_compress -X examples/text
dh_fixperms
diff -Nru debbugs-2.4.1/Makefile debbugs-2.4.1.1/Makefile
--- debbugs-2.4.1/Makefile 2002-11-25 04:25:05.0 -0800
+++ debbugs-2.4.1.1/Makefile2015-02-04 18:08:27.0 -0800
@@ -8,7 +8,7 @@
doc_dir:= $(DESTDIR)/usr/share/doc/debbugs
man_dir:= $(DESTDIR)/usr/share/man
man8_dir := $(man_dir)/man8
-examples_dir := $(doc_dir)/examples
+examples_dir := $(DESTDIR)/usr/share/debbugs/examples
scripts_in := $(filter-out scripts/config.in scripts/errorlib.in
scripts/text.in, $(wildcard scripts/*.in))
htmls_in := $(wildcard html/*.html.in)
unblock debbugs/2.4.1.1
-- System Information:
Debian Release: 8.0
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
--
Don Armstrong http://www.donarmstrong.com
You could say to the Universe this is not /fair/. And the Universe
would say: Oh it isn't? Sorry.
-- Terry Pratchett _Soul Music_ p357
--
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/2015021422.gf27...@teltox.donarmstrong.com
Bug#774737: unblock: libjpeg9/1:9a-2
On Wed, 04 Feb 2015, Bill Allombert wrote: My understanding was and is still that the CTTE overrided the release team on this point. That's incorrect. At least recently, when the CTTE is overriding people, we have been very explicit about the fact that they are being overridden. [This is important, because decisions which override developers require 3:1.] In this case, we merely noted that the release team was interested in having only one jpeg implementation, and the CTTE was asked to decide which implementation was to be used. On Wed, 04 Feb 2015, Paul Tagliamonte wrote: Can the CTTE overrule delegates? Only if the decision of the delegate falls under 6.1.1, 6.1.2, or 6.1.4 (and of course, that it was a decision delegated to the delegate by the DPL). If it's not a technical matter, than only a GR can override a delegate. -- Don Armstrong http://www.donarmstrong.com It was a very familiar voice. [...] It was a voice you could have used to open a bottle of whine. -- Terry Pratchett _The Last Continent_ p270 -- 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/20150204222040.gc15...@teltox.donarmstrong.com
Bug#771848: unblock libapache-gallery-perl/1.0.2-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
This is a simple fix for the important bug #770687, which breaks icons
for apache gallery. This particular bug was introduced by me, and the
fix returns to the upstream configuration. [Basically, it was appending
the wrong path to $filename; everything under /icons should be declined
and handled by Apache itself.]
diff -u libapache-gallery-perl-1.0.2/debian/changelog
libapache-gallery-perl-1.0.2/debian/changelog
--- libapache-gallery-perl-1.0.2/debian/changelog
+++ libapache-gallery-perl-1.0.2/debian/changelog
@@ -1,3 +1,11 @@
+libapache-gallery-perl (1.0.2-4) unstable; urgency=medium
+
+ * Remove regex and filename setting for icons/gallery which caused the
+wrong file to be used. Thanks to Andreas Pakulat for identifying the
+issue. (Closes: #770687)
+
+ -- Don Armstrong d...@debian.org Tue, 02 Dec 2014 11:33:24 -0800
+
libapache-gallery-perl (1.0.2-3) unstable; urgency=medium
* Create var/cache/www and make it writable by www-data (Closes: #710281)
diff -u libapache-gallery-perl-1.0.2/lib/Apache/Gallery.pm
libapache-gallery-perl-1.0.2/lib/Apache/Gallery.pm
--- libapache-gallery-perl-1.0.2/lib/Apache/Gallery.pm
+++ libapache-gallery-perl-1.0.2/lib/Apache/Gallery.pm
@@ -120,11 +120,7 @@
# Let Apache serve icons without us modifying the request
if ($r-uri =~ m/^\/icons/i) {
- if ($r-uri =~ m/^\/icons\/gallery\/([^\/]+$)/i) {
- $filename = /usr/share/libapache-gallery-perl/icons/$filename;
- $r-filename($filename);
- }
- return $::MP2 ? Apache2::Const::DECLINED() :
Apache::Constants::DECLINED();
+ return $::MP2 ? Apache2::Const::DECLINED() :
Apache::Constants::DECLINED();
}
# Lookup the file in the cache and scale the image if the cached
# image does not exist
--
Don Armstrong http://www.donarmstrong.com
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
-- Patrick McGoohan as Number 6 in The Prisoner
--
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/20141202210914.gf31...@rzlab.ucr.edu
Bug#770370: unblock fontconfig/2.11.0-6.2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
This is a simple partial fix for the RC bug #768598, with a typoed bug
in the changelog for good measure:
diff -Nru fontconfig-2.11.0/debian/changelog fontconfig-2.11.0/debian/changelog
--- fontconfig-2.11.0/debian/changelog 2014-08-20 06:36:05.0 -0700
+++ fontconfig-2.11.0/debian/changelog 2014-11-10 11:30:45.0 -0800
@@ -1,3 +1,13 @@
+fontconfig (2.11.0-6.2) unstable; urgency=medium
+
+ * Non-maintainer upload to delayed
+ * Switch to noawait triggers to allow self-triggering; will still need
+Breaks from dpkg to resolve this (closes: #768599)
+ * Add Pre-Depends on dpkg to allow for noawait just in case this gets
+backported to squeeze.
+
+ -- Don Armstrong d...@debian.org Mon, 10 Nov 2014 11:26:37 -0800
+
fontconfig (2.11.0-6.1) unstable; urgency=low
* Non-maintainer upload to delayed.
diff -Nru fontconfig-2.11.0/debian/control fontconfig-2.11.0/debian/control
--- fontconfig-2.11.0/debian/control2014-08-20 06:32:13.0 -0700
+++ fontconfig-2.11.0/debian/control2014-11-10 11:28:42.0 -0800
@@ -18,6 +18,7 @@
Section: fonts
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, fontconfig-config
+Pre-Depends: dpkg (= 1.16.1)
Replaces: fontconfig-config ( 2.5.93-1)
Multi-Arch: foreign
Description: generic font configuration library - support binaries
diff -Nru fontconfig-2.11.0/debian/fontconfig.triggers
fontconfig-2.11.0/debian/fontconfig.triggers
--- fontconfig-2.11.0/debian/fontconfig.triggers2013-06-25
11:12:30.0 -0700
+++ fontconfig-2.11.0/debian/fontconfig.triggers2014-11-10
11:28:03.0 -0800
@@ -1,3 +1,3 @@
-interest /usr/share/fonts
-interest /usr/share/ghostscript/fonts
-interest /usr/share/texmf/fonts
+interest-noawait /usr/share/fonts
+interest-noawait /usr/share/ghostscript/fonts
+interest-noawait /usr/share/texmf/fonts
--
Don Armstrong http://www.donarmstrong.com
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
-- Patrick McGoohan as Number 6 in The Prisoner
--
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/20141120195623.gb5...@rzlab.ucr.edu
Bug#770370: unblock fontconfig/2.11.0-6.2
On Thu, 20 Nov 2014, Jonathan Wiltshire wrote:
Control: tag -1 d-i
On Thu, Nov 20, 2014 at 11:56:23AM -0800, Don Armstrong wrote:
This is a simple partial fix for the RC bug #768598, with a typoed bug
in the changelog for good measure:
diff -Nru fontconfig-2.11.0/debian/changelog
fontconfig-2.11.0/debian/changelog
--- fontconfig-2.11.0/debian/changelog 2014-08-20 06:36:05.0 -0700
+++ fontconfig-2.11.0/debian/changelog 2014-11-10 11:30:45.0 -0800
@@ -1,3 +1,13 @@
+fontconfig (2.11.0-6.2) unstable; urgency=medium
+
+ * Non-maintainer upload to delayed
+ * Switch to noawait triggers to allow self-triggering; will still need
+Breaks from dpkg to resolve this (closes: #768599)
+ * Add Pre-Depends on dpkg to allow for noawait just in case this gets
+backported to squeeze.
+
+ -- Don Armstrong d...@debian.org Mon, 10 Nov 2014 11:26:37 -0800
+
fontconfig (2.11.0-6.1) unstable; urgency=low
* Non-maintainer upload to delayed.
diff -Nru fontconfig-2.11.0/debian/control fontconfig-2.11.0/debian/control
--- fontconfig-2.11.0/debian/control2014-08-20 06:32:13.0 -0700
+++ fontconfig-2.11.0/debian/control2014-11-10 11:28:42.0 -0800
@@ -18,6 +18,7 @@
Section: fonts
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, fontconfig-config
+Pre-Depends: dpkg (= 1.16.1)
Replaces: fontconfig-config ( 2.5.93-1)
Multi-Arch: foreign
Description: generic font configuration library - support binaries
diff -Nru fontconfig-2.11.0/debian/fontconfig.triggers
fontconfig-2.11.0/debian/fontconfig.triggers
--- fontconfig-2.11.0/debian/fontconfig.triggers2013-06-25
11:12:30.0 -0700
+++ fontconfig-2.11.0/debian/fontconfig.triggers2014-11-10
11:28:03.0 -0800
@@ -1,3 +1,3 @@
-interest /usr/share/fonts
-interest /usr/share/ghostscript/fonts
-interest /usr/share/texmf/fonts
+interest-noawait /usr/share/fonts
+interest-noawait /usr/share/ghostscript/fonts
+interest-noawait /usr/share/texmf/fonts
Fine by me, but needs a d-i ack.
Cool; let me know if any more information on this would be useful.
--
Don Armstrong http://www.donarmstrong.com
Quite the contrary; they *love* collateral damage. If they can make
you miserable enough, maybe you'll stop using email entirely. Once
enough people do that, then there'll be no legitimate reason left for
anyone to run an SMTP server, and the spam problem will be solved.
-- Craig Dickson in 20020909231134.GA18917@linux700.localnet
--
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/20141120201239.ge5...@rzlab.ucr.edu
Bug#770003: unblock lilypond/2.18.2-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
This is a simple fix for the RC bug #768272:
diff -Nru lilypond-2.18.2/debian/changelog lilypond-2.18.2/debian/changelog
--- lilypond-2.18.2/debian/changelog2014-09-26 11:43:19.0 -0700
+++ lilypond-2.18.2/debian/changelog2014-11-16 17:38:32.0 -0800
@@ -1,11 +1,20 @@
+lilypond (2.18.2-4) unstable; urgency=medium
+
+ * Fix the wrong maintscript-helper invocation which was trying to
+symlink to /usr/share/doc/lilypond/Documentation/user instead of
+/usr/share/doc/lilypond/Documentation. (Closes: #768272)
+ * Add missing Pre-Depends: ${misc:Depends} for dpkg-maintscript-helper.
+
+ -- Don Armstrong d...@debian.org Sun, 16 Nov 2014 17:38:32 -0800
+
lilypond (2.18.2-3) unstable; urgency=medium
* Revert previous patch (no parallel); the issue was actually running
tests on architecture independent builds which had not built any of
the documentation. (Closes: #760794)
* Stop setting HOME to /tmp in debian/rules. (Closes: #762230)
-- Don Armstrong d...@debian.org Tue, 16 Sep 2014 14:50:14 -0700
lilypond (2.18.2-2) unstable; urgency=high
diff -Nru lilypond-2.18.2/debian/control lilypond-2.18.2/debian/control
--- lilypond-2.18.2/debian/control 2014-09-25 15:34:19.0 -0700
+++ lilypond-2.18.2/debian/control 2014-11-16 17:36:59.0 -0800
@@ -66,6 +66,7 @@
Package: lilypond-doc
Section: doc
Architecture: all
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${misc:Depends}, dpkg (= 1.15.4) | install-info
Recommends: lilypond-doc-html, lilypond-doc-pdf
Suggests: lilypond (= ${source:Version})
diff -Nru lilypond-2.18.2/debian/lilypond-doc.maintscript
lilypond-2.18.2/debian/lilypond-doc.maintscript
--- lilypond-2.18.2/debian/lilypond-doc.maintscript 2014-09-03
12:33:29.0 -0700
+++ lilypond-2.18.2/debian/lilypond-doc.maintscript 2014-11-11
14:19:22.0 -0800
@@ -1 +1 @@
-symlink_to_dir /usr/share/info/lilypond
/usr/share/doc/lilypond/html/Documentation/user 2.18.2-1~
+symlink_to_dir /usr/share/info/lilypond
/usr/share/doc/lilypond/html/Documentation 2.18.2-4~
--
Don Armstrong http://www.donarmstrong.com
I will not make any deals with you. I've resigned. I will not be
pushed, filed, stamped, indexed, briefed, debriefed or numbered. My
life is my own. I resign.
-- Patrick McGoohan as Number 6 in The Prisoner
--
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/20141118071226.gl32...@teltox.donarmstrong.com
Re: Test package for testing dgit upload infrastructure
On Wed, 29 Oct 2014, Ian Jackson wrote: Is there already a test package name I can use for this purpose ? There currently isn't, at least as far the BTS is concerned. Because I think your major plan is to test other parts of the infrastructure, I think something under the dgit-*; namespace would work. -- Don Armstrong http://www.donarmstrong.com First you take a drink, then the drink takes a drink, then the drink takes you. -- F. Scott Fitzgerald -- 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/20141029215547.gc14...@teltox.donarmstrong.com
Re: Bug#760986: RM: guile-1.8 -- ROM; replaced by guile-2.0
On Mon, 13 Oct 2014, Jonathan Wiltshire wrote: lilypond is a shame, especially as it has an active and caring maintainer, but if upstream support is not ready yet I don't think we should hold up for them. The alternative is supporting guile-1.8 ourselves, if it isn't upstream any longer. I'd personally vote for supporting guile 1.8 for one more release, but I'm obviously biased. I'm willing to assist in keeping it maintained, for whatever that's worth. I agree that we should definitely get rid of any of the packages which can support 2.0 and don't, though. It would be ideal if the only reverse dependency of guile 1.8 in jessie was lilypond. -- Don Armstrong http://www.donarmstrong.com You have many years to live--do things you will be proud to remember when you are old. -- Shinka proverb. (John Brunner _Stand On Zanzibar_ p413) -- 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/20141014165647.ge4...@teltox.donarmstrong.com
Re: BTS and UDD disagrees on the number of RC bugs in stable
On Tue, 18 Feb 2014, Don Armstrong wrote: Yeah, it's not working. I've got it on my TODO list, but haven't had a chance to work on it yet. I will probably have a chance next weekend to spend some time on it. So I think I've fixed this now; had to finally set up a testing framework for bugscan to get at it, but that was long overdue anyway. I've just merged the changes, so we'll have to wait until the next bugscan run to be sure it got fixed up. -- Don Armstrong http://www.donarmstrong.com Taxes are not levied for the benefit of the taxed. -- Robert Heinlein _Time Enough For Love_ p250 -- 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/20140321024952.gk16...@teltox.donarmstrong.com
Re: BTS and UDD disagrees on the number of RC bugs in stable
On Wed, 12 Feb 2014, Niels Thykier wrote: Looks like it didn't work. UDD is now listing ~310 RC bugs for testing and the BTS thinks there are ~480 RC bugs in stable. There was a drop a little while back, but I suspect it was the related to the recent stable update. On Tue, 18 Feb 2014, Holger Levsen wrote: On Freitag, 7. Februar 2014, Don Armstrong wrote: I've now rolled this out, but bugscan's crontab hasn't run yet. I'll keep an eye on it to make sure it works. https://bugs.debian.org/release-critical/ doens't look like it's working :/ Could you please have a look again? Yeah, it's not working. I've got it on my TODO list, but haven't had a chance to work on it yet. I will probably have a chance next weekend to spend some time on it. -- Don Armstrong http://www.donarmstrong.com People selling drug paraphernalia ... are as much a part of drug trafficking as silencers are a part of criminal homicide. -- John Brown, DEA Chief -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218221343.gd5...@teltox.donarmstrong.com
Re: BTS and UDD disagrees on the number of RC bugs in stable
On Wed, 05 Feb 2014, Don Armstrong wrote: Yeah. I think this is a bug I introduced when I switched to using bugcfg instead of the hardcoded values which were being used before. I just fixed this in @81492, but I haven't rolled it out to the BTS yet. I've now rolled this out, but bugscan's crontab hasn't run yet. I'll keep an eye on it to make sure it works. -- Don Armstrong http://www.donarmstrong.com Physics is like sex. Sure, it may give some practical results, but that's not why we do it. -- Richard Feynman -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140207202835.gd24...@rzlab.ucr.edu
Re: BTS and UDD disagrees on the number of RC bugs in stable
On Wed, 05 Feb 2014, Lucas Nussbaum wrote: On 05/02/14 at 18:52 +0100, Niels Thykier wrote: Hi BTS people and UDD, We have noticed that some bugs tagged wheezy-ignore appears on the BTS list of RC bugs affecting stable. As an example, the list[1] contains #710069 and #710357. Both of these were tagged wheezy-ignore on the 28th of November. Currently, UDD's bug view[2] claims that Wheezy has ~400 RC bugs where as the BTS summary page[3] thinks the number is ~500 RC bugs. The BTS lists e.g. #710310, which is wheezy-ignore. So it seems that the BTS ignores wheezy-ignore. Yeah. I think this is a bug I introduced when I switched to using bugcfg instead of the hardcoded values which were being used before. I just fixed this in @81492, but I haven't rolled it out to the BTS yet. -- Don Armstrong http://www.donarmstrong.com I cannot find rest Because I am powerless To amend a broken world. -- Guy Gavriel Kay _Under Heaven_ p295 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140206011325.gf5...@teltox.donarmstrong.com
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I'm OK with assisting with either, but I need to know which solution porters would prefer. -- Don Armstrong http://www.donarmstrong.com For those who understand, no explanation is necessary. For those who do not, none is possible. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105183439.gy9...@rzlab.ucr.edu
Re: Potential issues for most ports (Was: Re: Bits from the Release Team (Jessie freeze info))
On Tue, 05 Nov 2013, Don Armstrong wrote: On Tue, 05 Nov 2013, Niels Thykier wrote: In this regard; I am guilty of filing some those bugs without tagging them. Honestly, adding the tags get a bit in the way right now. If a package FTBFS on 4 architectures, I have to dig up 3-4 different usertags (with different user) and associate it with the bug. This sounds like a case where we should turn these usertags into fully fledged tags. [Or alternatively, they should just be made usertags under the debian-po...@lists.debian.org user or similar.] I would also be OK with creating a pseudopackage as well as Ian suggested. [Or multiple pseudopackages.] Something like i386.ports.debian.org or similar would work, with each current port getting a pseudopackage, and the maintainer of the pseudopackage being the ports list. -- Don Armstrong http://www.donarmstrong.com America was far better suited to be the World's Movie Star. The world's tequila-addled pro-league bowler. The world's acerbic bi-polar stand-up comedian. Anything but a somber and tedious nation of socially responsible centurions. -- Bruce Sterling, _Distraction_ p122 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131105185031.gz9...@rzlab.ucr.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Tue, 05 Feb 2013, Julien Cristau wrote: - the latest of these uploads breaks the installer, making it impossible to build and upload the planned wheezy release candidate, since build-dependencies are fetched from unstable - when asked to revert this change, the syslinux maintainer refused, and said disagreements should be referred to the technical committee Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? [I can understand a bit of wariness of having d-i built with a version of syslinux that isn't being distributed in wheezy, but I think that might need to be discussed and a technical solution fleshed out elsewhere, and probably isn't ripe for a CTTE decision.] Don Armstrong 0: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#30 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=699742#40 -- [Panama, 1989. The U.S. government called it Operation Just Cause.] I think they misspelled this. Shouldn't it be Operation Just 'Cause? -- TekPolitik http://slashdot.org/comments.pl?sid=59669cid=5664907 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206204100.gd17...@rzlab.ucr.edu
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Wed, 06 Feb 2013, Russ Allbery wrote: Don Armstrong d...@debian.org writes: Assuming that the patch for #699742[0] fixes this issue with DI RC releases being installed, is there still an outstanding issue for the CTTE? Earlier in this thread, there had been a couple of reports that fix didn't work. I haven't looked further, though. Yeah, that was for the first incomplete patch. I was referring to the second one. Don Armstrong -- Let us chat together a moment, my friend. There are still several hours until dawn, and I have the whole day to sleep. -- Count Orlock in _Nosferatu (1922)_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013020624.gf17...@rzlab.ucr.edu
Bug#696608: unlock: lilypond/2.14.2-4 (preapproval)
On Sat, 19 Jan 2013, Don Armstrong wrote:
On Sat, 19 Jan 2013, Julien Cristau wrote:
On Mon, Dec 24, 2012 at 19:43:58 +, Adam D. Barratt wrote:
Control: tags -1 + confirmed
On 23.12.2012 21:31, Don Armstrong wrote:
In making a fix to the RC bug #684817, I also fixed a problem in
disabling optimization when noopt is present, and a patch which fixes
an install-info warning which had previously collected.
I'd be okay with accepting those. Please go ahead; thanks.
Ping?
Sorry, I actually have to change the patch for this after talking to
upstream. It's going to be relatively trivial still, but slightly
different. I just haven't had a chance to completely test it yet.
I have just uploaded a new lilypond which fixes this bug with the
attached changes. The only change from the previously approved patch
is properly fixing #684817. [The complete patch, and the changes to
the preapproved patch are attached.]
Don Armstrong
--
Good people are good because they've come to wisdom through failure.
We get very little wisdom from success, you know.
-- William Saroyan _My Heart's in the Highlands_
http://www.donarmstrong.com http://rzlab.ucr.edu
diff -u lilypond-2.14.2/debian/control lilypond-2.14.2/debian/control
--- lilypond-2.14.2/debian/control
+++ lilypond-2.14.2/debian/control
@@ -17,6 +17,8 @@
Maintainer: Don Armstrong d...@debian.org
Standards-Version: 3.9.2
Homepage: http://lilypond.org/
+Vcs-Git: git://git.donarmstrong.com/lilypond.git
+Vcs-Browser: http://git.donarmstrong.com/lilypond.git
Package: lilypond
Architecture: any
diff -u lilypond-2.14.2/debian/changelog lilypond-2.14.2/debian/changelog
--- lilypond-2.14.2/debian/changelog
+++ lilypond-2.14.2/debian/changelog
@@ -1,6 +1,19 @@
+lilypond (2.14.2-4) unstable; urgency=low
+
+ * Fix warnings from install-info by splitting the direntry sections
+across the texinfo files (Closes: #648689). Thanks to Julian Gilbey
+for the patch.
+ * Fix noopt support to use --disable-optimising as ./configure does
+crazy things.
+ * Apply patch from 13fc2437e2aaa9 to fix segfault in font-mark where a
+garbage collection can trigger a null pointer dereference (closes:
+#684817)
+
+ -- Don Armstrong d...@donarmstrong.com Sun, 23 Dec 2012 13:25:44 -0800
+
lilypond (2.14.2-3) unstable; urgency=low
- * Fix redefinition of s in Music_sequence::first_start. (Closes
+ * Fix redefinition of s in Music_sequence::first_start. (Closes:
#672087).
-- Don Armstrong d...@debian.org Sun, 13 May 2012 16:07:16 -0700
diff -u lilypond-2.14.2/debian/rules lilypond-2.14.2/debian/rules
--- lilypond-2.14.2/debian/rules
+++ lilypond-2.14.2/debian/rules
@@ -56,8 +56,12 @@
CFLAGS := $(filter-out -O%, $(CFLAGS))
CXXFLAGS := $(filter-out -O%, $(CXXFLAGS))
else
+ifneq (,$(filter $(DEB_BUILD_OPTIONS),noopt))
+ config_opt = --disable-optimising
+else
config_opt = --enable-optimising
endif
+endif
build: build-stamp
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/lily/pango-font.cc
+++ lilypond-2.14.2/lily/pango-font.cc
@@ -47,6 +47,10 @@
PangoFontDescription const *description,
Real output_scale)
{
+ // This line looks stupid, but if we don't initialize physical_font_tab_ befo
+ // we allocate memory in scm_c_make_hash_table, then that could trigger a gar
+ // collection.
+ physical_font_tab_ = SCM_EOL;
physical_font_tab_ = scm_c_make_hash_table (11);
PangoDirection pango_dir = PANGO_DIRECTION_LTR;
context_ = pango_context_new ();
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/learning.tely
+++ lilypond-2.14.2/Documentation/learning.tely
@@ -13,6 +13,11 @@
@documentlanguage en
@afourpaper
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
+* LilyPond Learning Manual: (lilypond-learning). Start here.
+@end direntry
+
@macro manualIntro
This file provides an introduction to LilyPond version
@version{}.
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/music-glossary.tely
+++ lilypond-2.14.2/Documentation/music-glossary.tely
@@ -6,6 +6,11 @@
@documentlanguage en
@afourpaper
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
+* Music Glossary: (music-glossary). For non-English users.
+@end direntry
+
@macro manualIntro
This glossary provides definitions and translations of musical
terms used in the documentation manuals for LilyPond version
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/usage.tely
+++ lilypond-2.14.2/Documentation/usage.tely
@@ -13,6 +13,18 @@
@documentlanguage en
@afourpaper
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
+* LilyPond Application Usage: (lilypond-usage). Installing and running applications.
+* lilypond: (lilypond-usage)Running lilypond. Invoking the LilyPond program.
+* abc2ly: (lilypond-usage)Invoking abc2ly. Importing ABC.
+* convert-ly: (lilypond-usage)Updating files with convert-ly. Older
Re: Bug#699808: tech-ctte: syslinux vs the wheezy release
On Wed, 06 Feb 2013, Cyril Brulebois wrote: Daniel Baumann daniel.baum...@progress-technologies.net (05/02/2013): or: * apply the following tested and working patch from #699742 in debian-installer, […] Except that this “tested and working patch” doesn't fix anything. Same issue, as seen by Michael and myself. Is it the intention of the Release Managers not to accept a newer version of syslinux into wheezy? [That is, if the CTTE were to decide to require some fix to d-i, we'd also have to override the RMs?] Don Armstrong -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130205235509.gm6...@rzlab.ucr.edu
Bug#696608: unlock: lilypond/2.14.2-4 (preapproval)
On Sat, 19 Jan 2013, Julien Cristau wrote: On Mon, Dec 24, 2012 at 19:43:58 +, Adam D. Barratt wrote: Control: tags -1 + confirmed On 23.12.2012 21:31, Don Armstrong wrote: In making a fix to the RC bug #684817, I also fixed a problem in disabling optimization when noopt is present, and a patch which fixes an install-info warning which had previously collected. I'd be okay with accepting those. Please go ahead; thanks. Ping? Sorry, I actually have to change the patch for this after talking to upstream. It's going to be relatively trivial still, but slightly different. I just haven't had a chance to completely test it yet. Don Armstrong -- There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. -- Jeremy S. Anderson http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130119181841.gg10...@teltox.donarmstrong.com
Re: RC bugs missing after experimental upload
On Mon, 24 Dec 2012, Steven Chamberlain wrote: I was wondering why bug #651636 was no longer listed among RC bugs, in the UDD bugs.cgi interface or on the webkit PTS/BTS pages. It's still listed, but because that binary package is now present in different source packages, you won't see it in just the source package listing. [This is yet another reason why changing source package names is problematic. Eventually the BTS will handle this situation slightly more gracefully, but it's a bit of work to get it to that state.] And I also wonder if this may have happened with any other packages; could RC bugs for Wheezy have gone missing for similar reasons? No, because they still show up in http://bugs.debian.org/bugscan/britney/testing-nr and http://bugs.debian.org/bugscan/other/testing.html for example. Don Armstrong -- Sometimes I wish I could take back all my mistakes but then I think what if my mother could take back hers? -- a softer world #498 http://www.asofterworld.com/index.php?id=498 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121224183208.gs5...@teltox.donarmstrong.com
Bug#696608: unlock: lilypond/2.14.2-4 (preapproval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
In making a fix to the RC bug #684817, I also fixed a problem in
disabling optimization when noopt is present, and a patch which fixes
an install-info warning which had previously collected.
The first is necessary, but the second two would be nice to have, and
don't introduce anything that is particularly odd to the package.
[However, I can strip both of them out if it is not ok at this point
in the release; I only hadn't added them before because I had to fix
#684817 first.]
Diff attached for proposed upload to unstable.
Don Armstrong
--
My spelling ability, or rather the lack thereof, is one of the wonders
of the modern world.
http://www.donarmstrong.com http://rzlab.ucr.edu
diff -u lilypond-2.14.2/debian/control lilypond-2.14.2/debian/control
--- lilypond-2.14.2/debian/control
+++ lilypond-2.14.2/debian/control
@@ -17,6 +17,8 @@
Maintainer: Don Armstrong d...@debian.org
Standards-Version: 3.9.2
Homepage: http://lilypond.org/
+Vcs-Git: git://git.donarmstrong.com/lilypond.git
+Vcs-Browser: http://git.donarmstrong.com/lilypond.git
Package: lilypond
Architecture: any
diff -u lilypond-2.14.2/debian/changelog lilypond-2.14.2/debian/changelog
--- lilypond-2.14.2/debian/changelog
+++ lilypond-2.14.2/debian/changelog
@@ -1,6 +1,18 @@
+lilypond (2.14.2-4) unstable; urgency=low
+
+ * Fix warnings from install-info by splitting the direntry sections
+across the texinfo files (Closes: #648689). Thanks to Julian Gilbey
+for the patch.
+ * Fix noopt support to use --disable-optimising as ./configure does
+crazy things.
+ * Make sure that the guile garbage collection does not collect s in
+font-metric.cc when it gets optimized away (closes: #684817)
+
+ -- Don Armstrong d...@donarmstrong.com Sun, 23 Dec 2012 13:25:44 -0800
+
lilypond (2.14.2-3) unstable; urgency=low
- * Fix redefinition of s in Music_sequence::first_start. (Closes
+ * Fix redefinition of s in Music_sequence::first_start. (Closes:
#672087).
-- Don Armstrong d...@debian.org Sun, 13 May 2012 16:07:16 -0700
diff -u lilypond-2.14.2/debian/rules lilypond-2.14.2/debian/rules
--- lilypond-2.14.2/debian/rules
+++ lilypond-2.14.2/debian/rules
@@ -56,8 +56,12 @@
CFLAGS := $(filter-out -O%, $(CFLAGS))
CXXFLAGS := $(filter-out -O%, $(CXXFLAGS))
else
+ifneq (,$(filter $(DEB_BUILD_OPTIONS),noopt))
+ config_opt = --disable-optimising
+else
config_opt = --enable-optimising
endif
+endif
build: build-stamp
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/essay.tely
+++ lilypond-2.14.2/Documentation/essay.tely
@@ -13,6 +13,11 @@
@documentlanguage en
@afourpaper
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
+* LilyPond Engraving Functions: (lilypond-essay). Automatic engraving functions within LilyPond.
+@end direntry
+
@macro manualIntro
This essay discusses automatic music engraving functions within
LilyPond version @version{}.
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/changes.tely
+++ lilypond-2.14.2/Documentation/changes.tely
@@ -29,6 +29,11 @@
@end macro
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
+* LilyPond Changes: (lilypond-changes). Changes to recent versions.
+@end direntry
+
@documentencoding utf-8
@documentlanguage en
@afourpaper
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/web.texi
+++ lilypond-2.14.2/Documentation/web.texi
@@ -56,20 +56,8 @@
@c expected to be found in lilypond/ subdirectory.
@dircategory GNU LilyPond --- the music typesetter
@direntry
-* LilyPond Learning Manual: (lilypond-learning). Start here.
-* Music Glossary: (music-glossary). For non-English users.
-* LilyPond: (lilypond-notation). LilyPond Notation Reference.
-* LilyPond Snippets: (lilypond-snippets). Short tricks, tips, and examples.
* LilyPond Internals Reference: (lilypond-internals). Definitions for tweaking.
-* LilyPond Application Usage: (lilypond-usage). Installing and running applications.
* LilyPond Website: (lilypond-web).Preview of new website.
-* lilypond: (lilypond-usage)Running lilypond. Invoking the LilyPond program.
-* abc2ly: (lilypond-usage)Invoking abc2ly. Importing ABC.
-* convert-ly: (lilypond-usage)Updating files with convert-ly. Older LilyPond versions.
-* etf2ly: (lilypond-usage)Invoking etf2ly. Importing Finale.
-* lilypond-book: (lilypond-usage)lilypond-book. Integrating text and music.
-* midi2ly: (lilypond-usage)Invoking midi2ly.Importing MIDI.
-* musicxml2ly: (lilypond-usage)Invoking musicxml2ly. Importing MusicXML.
@end direntry
only in patch2:
unchanged:
--- lilypond-2.14.2.orig/Documentation/extending.tely
+++ lilypond-2.14.2/Documentation/extending.tely
@@ -13,6 +13,11 @@
@documentlanguage en
@afourpaper
+@dircategory GNU LilyPond --- the music typesetter
+@direntry
Bug#693475: unblock: evince/3.4.0-3.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock evince/3.4.0-3.1 Diff attached. * Non-maintainer Upload * Support the rest of the mime types that evince used to support in evince-gtk.mime and evince.mime. Closes: #658139. This also fixes #619564, #627027, and #551734 which were related to evince.mime and evince-gtk.mime. #581441 was fixed in shared-mime-info/1.0. unblock evince/3.4.0-3.1 Thanks. Don Armstrong -- There is no such thing as social gambling. Either you are there to cut the other bloke's heart out and eat it--or you're a sucker. If you don't like this choice--don't gamble. -- Robert Heinlein _Time Enough For Love_ p250 http://www.donarmstrong.com http://rzlab.ucr.edu diff -Nru evince-3.4.0/debian/changelog evince-3.4.0/debian/changelog --- evince-3.4.0/debian/changelog 2012-08-29 17:28:06.0 -0700 +++ evince-3.4.0/debian/changelog 2012-11-08 10:34:13.0 -0800 @@ -1,3 +1,13 @@ +evince (3.4.0-3.1) unstable; urgency=low + + * Non-maintainer Upload + * Support the rest of the mime types that evince used to support in +evince-gtk.mime and evince.mime. Closes: #658139. This also fixes +#619564, #627027, and #551734 which were related to evince.mime and +evince-gtk.mime. #581441 was fixed in shared-mime-info/1.0. + + -- Don Armstrong d...@debian.org Thu, 08 Nov 2012 10:32:12 -0800 + evince (3.4.0-3) unstable; urgency=low [ Josselin Mouette ] diff -Nru evince-3.4.0/debian/control evince-3.4.0/debian/control --- evince-3.4.0/debian/control 2012-08-29 17:32:50.0 -0700 +++ evince-3.4.0/debian/control 2012-11-08 11:09:28.0 -0800 @@ -7,7 +7,7 @@ Section: gnome Priority: optional Maintainer: Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org -Uploaders: Frederic Peters fpet...@debian.org, Michael Biebl bi...@debian.org +Uploaders: Michael Biebl bi...@debian.org Build-Depends: cdbs (= 0.4.90), debhelper (= 8), dpkg-dev (= 1.16.1), diff -Nru evince-3.4.0/debian/evince-gtk.mime evince-3.4.0/debian/evince-gtk.mime --- evince-3.4.0/debian/evince-gtk.mime 1969-12-31 16:00:00.0 -0800 +++ evince-3.4.0/debian/evince-gtk.mime 2012-11-08 10:30:34.0 -0800 @@ -0,0 +1,21 @@ +application/pdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf; priority=5 +application/x-pdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf; priority=5 +application/x-bzpdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf.bz2; priority=5 +application/x-gzpdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf.gz; priority=5 +application/postscript; evince %s; test=test -n $DISPLAY; nametemplate=%s.ps; priority=5 +application/x-bzpostscript; evince %s; test=test -n $DISPLAY; nametemplate=%s.ps.bz2; priority=5 +application/x-gzpostscript; evince %s; test=test -n $DISPLAY; nametemplate=%s.ps.gz; priority=5 +image/x-eps; evince %s; test=test -n $DISPLAY; nametemplate=%s.eps; priority=5 +image/x-bzeps; evince %s; test=test -n $DISPLAY; nametemplate=%s.eps.bz2; priority=5 +image/x-gzeps; evince %s; test=test -n $DISPLAY; nametemplate=%s.eps.gz; priority=5 +application/x-dvi; evince %s; test=test -n $DISPLAY; nametemplate=%s.dvi; priority=5 +application/x-gzdvi; evince %s; test=test -n $DISPLAY; nametemplate=%s.dvi.gz; priority=5 +application/x-bzdvi; evince %s; test=test -n $DISPLAY; nametemplate=%s.dvi.bz2; priority=5 +image/vnd.djvu; evince %s; test=test -n $DISPLAY; nametemplate=%s.djvu; priority=5 +application/x-cbr; evince %s; test=test -n $DISPLAY; nametemplate=%s.cbr; priority=4 +application/x-cbt; evince %s; test=test -n $DISPLAY; nametemplate=%s.cbt; priority=4 +application/x-cbz; evince %s; test=test -n $DISPLAY; nametemplate=%s.cbz; priority=4 +application/x-cb7; evince %s; test=test -n $DISPLAY; nametemplate=%s.cb7; priority=4 +image/tiff; evince %s; test=test -n $DISPLAY; nametemplate=%s.tiff; priority=3 +application/oxps; evince %s; test=test -n $DISPLAY; nametemplate=%s.xps; priority=3 +application/vnd.ms-xpsdocument; evince %s; test=test -n $DISPLAY; nametemplate=%s.xps; priority=3 diff -Nru evince-3.4.0/debian/evince.mime evince-3.4.0/debian/evince.mime --- evince-3.4.0/debian/evince.mime 2012-08-29 17:27:46.0 -0700 +++ evince-3.4.0/debian/evince.mime 2012-11-08 10:30:34.0 -0800 @@ -1 +1,21 @@ application/pdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf; priority=5 +application/x-pdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf; priority=5 +application/x-bzpdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf.bz2; priority=5 +application/x-gzpdf; evince %s; test=test -n $DISPLAY; nametemplate=%s.pdf.gz; priority=5 +application/postscript; evince %s; test=test -n $DISPLAY; nametemplate=%s.ps; priority=5 +application/x-bzpostscript; evince %s; test=test -n $DISPLAY; nametemplate=%s.ps.bz2; priority=5 +application/x-gzpostscript; evince %s
Re: Processed (with 6 errors): your mail
On Wed, 04 Apr 2012, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
clone 666004 -1
Bug #666004 [kumofs] kumofs: Please remove packagaes for s390x and sparc --
it blocks libtokyocabinet transition.
Bug 666004 cloned as bug 667507
Failed to clone 666004: The following parameter was passed in the call to
Debbugs::Control::set_blocks but was not listed in the validation options:
blocks
Debbugs::Control::set_blocks('bug', 667507, 'blocks', 664078,
'request_msgid', '1333548859.3223.24.ca...@mordor.loewenhoehle.ip',
'request_replyto', 'Tobias Frost t...@frost.de', 'transcript', ...) called
at /usr/local/lib/site_perl/Debbugs/Control.pm line 2900
Debbugs::Control::clone_bug('transcript', 'GLOB(0x1c9bf50)',
'requester', 'Tobias Frost t...@frost.de', 'request_addr',
'cont...@bugs.debian.org', 'request_msgid',
'1333548859.3223.24.ca...@mordor.loewenhoehle.ip', 'request_subject', ...)
called at /usr/lib/debbugs/service line 912
eval {...} called at /usr/lib/debbugs/service line 910
Ugh. This is fixed now.
Don Armstrong
--
I leave the show floor, but not before a pack of caffeinated Jolt gum
is thrust at me by a hyperactive girl screaming, Chew more! Do more!
The American will to consume more and produce more personified in a
stick of gum. I grab it.
-- Chad Dickerson
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120404232056.gp13...@rzlab.ucr.edu
Re: Release Update: timings, status and awesomeness
On Tue, 18 Jan 2011, Neil McGovern wrote: Awesomeness of Squeeze Obviously, because it's a Debian release, it's awesome! Or at the very least, awe-inspiring. What more is needed? Good job everyone, and keep it up! Don Armstrong -- Herodotus says, Very few things happen at the right time, and the rest do not happen at all. The conscientious historian will correct these defects. -- Mark Twain _A Horse's Tail_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110118211559.go5...@teltox.donarmstrong.com
Bug#608993: unblock: unscd/0.47-2
On Wed, 05 Jan 2011, Philipp Kern wrote: On Wed, Jan 05, 2011 at 11:48:00AM +0200, Teodor wrote: Please unblock package unscd. It fixes RC bug #606588 although it's not listed on UDD [1] for some reason. It's not RC, it's of important severity. @Don: Do we need this band-aid fix in squeeze? It's simple enough; the only change in -2 is to remove the Provides: nscd, and add some verbiage as to what to do if you actually need it. I don't have a strong opinion either way, but given that two people have now mentioned it, it's probably worth it. Don Armstrong -- A Democracy lead by politicians and political parties, fails. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110105104435.gl5...@teltox.donarmstrong.com
Re: RC bug #527862: libmilter1.0.1: segfault in libmilter - using milter-greylist and mimedefang - both dies
fixed 527862 8.14.4-1 severity 527862 important close 527862 thanks On Sat, 11 Dec 2010, Harald Jenny wrote: first my apologies for this mass mailing but as the problem described in the subject affects a dozen of programs (at least according to their Depends-field) I thought it would be beneficial to allow everybody to participate in this conversation. The issue at hand is that a bug in the current version of libmilter which is available in Debian Squeeze (8.14.3-9.4) leads to sefaults of the affected programs when hit my milter requests. Affected packages are: You've reopened the bug, which is an indication that the underlying problem wasn't fixed at all. However, the patch has been applied, and the issue fixed in unstable, and only an unblock or a t-p-u upload is required to fix the issue. I have rectified this for you. You may want to read up on BTS versioning if this is unfamiliar to you. Secondly, this issue is not grave, as it doesn't make the package in question useless or mostly so, nor does it expose user accounts. I have return its severity to important; the release team and/or Richard can of course make the issue RC. Furthermore, it's not necessary to e-mail anyone else but the package maintainer, the bug, and possibly debian-release if the package maintainer doesn't respond. Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101211121042.gk16...@teltox.donarmstrong.com
Bug#603982: unblock unscd
On Thu, 09 Dec 2010, Nico Schottelius wrote: nscd is broken for YEARS and nobody cared (*) about it. Don is probably the only person in the Debian area, who took responsibilty and created a VERY GOOD replacement (**). Denys Vlasenko actually created it; I just packaged it. [I have enough machines with LDAP to have run into the same problems with nscd, which is why I packaged it.] But anyway, thanks to Mehdi Dogguy it's been unblocked, so it'll transition soon. I'll whip up a backport once that happens. Don Armstrong -- LEADERSHIP -- A form of self-preservation exhibited by people with autodestructive imaginations in order to ensure that when it comes to the crunch it'll be someone else's bones which go crack and not their own. -- The HipCrime Vocab by Chad C. Mulligan (John Brunner _Stand On Zanzibar_ p256-7) http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101209233618.gc16...@teltox.donarmstrong.com
Bug#603982: unblock: unscd/0.47-1 (New Package)
On Thu, 25 Nov 2010, Don Armstrong wrote: On Thu, 25 Nov 2010, Mehdi Dogguy wrote: Moreover, it doesn't seem to fix any RC bug. unscd was made to resolve the problems seen in nscd where nscd is near useless in a system with any amount of load (see #574990 et al.) So, I'd rather keep it in sid and not unblock it. That's your decision, but considering the ease with which the package can be removed if it holds up the release at all (and the real issues with nscd that it resolves), I'd suggest revisiting this decision. Ping. Don Armstrong -- He quite enjoyed the time by himself in the mornings. The day was too early to have started going really wrong. -- Terry Pratchet _Only You Can Save Mankind_ p133 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101208213235.gx16...@teltox.donarmstrong.com
Re: lilypond in squeeze
On Sat, 27 Nov 2010, Julien Cristau wrote: On Fri, Nov 26, 2010 at 15:52:21 -0800, Don Armstrong wrote: The fix is to unblock lilypond. The only reason it didn't make it in for the freeze were the failures of fontforge brought about by a new version. Unblocking lilypond is not going to help until we can get it built on s390. That's why I haven't asked for an unblock yet. There is a patch that may resolve that problem on s390 that needs to be tested (and also needs a response from the maintainers of fontforge.) I haven't had time to go deep into the problem besides creating a smaller test case. See #594629 and the work that Nico Tyni has done; I think he may be closest to a patch. Christian/Kęstutis: can you look at the patch and see if it's something that you'd be willing to make an new upload with? [I'll try to get a test in with a new fontforge on s390 if you'd be willing to upload a package with it, assuming that it fixes the problem.] Don Armstrong -- Ban cryptography! Yes. Let's also ban pencils, pens and paper, since criminals can use them to draw plans of the joint they are casing or even, god forbid, create one time pads to pass uncrackable codes to each other. Ban open spaces since criminals could use them to converse with each other out of earshot of the police. Let's ban flags since they could be used to pass secret messages in semaphore. In fact let's just ban all forms of verbal and non-verbal communication -- let's see those criminals make plans now! http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101128021018.gm16...@teltox.donarmstrong.com
Re: lilypond in squeeze
On Sat, 27 Nov 2010, Simon McVittie wrote: Julien wrote: Unblocking lilypond is not going to help until we can get it built on s390. For the record, this seems to be http://bugs.debian.org/594629 - I'll see whether I can reproduce that under emulation (hercules). Having said that, how many people are going to be typesetting their music on a mainframe? Would removing the old lilypond/s390 binaries be a feasible solution? If that's what we have to do at the end, that's fine. But I'd much rather fix the fontforge issue. We don't really need to rush to decide this yet. Don Armstrong -- [A] theory is falsifiable [(and therefore scientific) only] if the class of its potential falsifiers is not empty. -- Sir Karl Popper _The Logic of Scientific Discovery_ §21 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101128021150.gn16...@teltox.donarmstrong.com
Re: lilypond in squeeze
On Fri, 26 Nov 2010, Simon McVittie wrote: lilypond in sid seems to fix several RC bugs [1] [2] [3], but has a rather intimidating diffstat compared with the version in squeeze (a new upstream version), and appears to have failed repeatedly on s390 (possibly not lilypond's fault, it looks like fontforge dying). Do you have any plans for how to fix these RC bugs for squeeze? Are the fixes feasible to backport, for instance? The fix is to unblock lilypond. The only reason it didn't make it in for the freeze were the failures of fontforge brought about by a new version. Don Armstrong -- I'd sign up in a hot second for any cellular company whose motto was: We're less horrible than a root canal with a cold chisel. -- Cory Doctorow http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101126235221.gi16...@teltox.donarmstrong.com
Bug#603982: unblock: unscd/0.47-1 (New Package)
On Thu, 25 Nov 2010, Mehdi Dogguy wrote: On 19/11/2010 03:26, Don Armstrong wrote: I've been using it in production for months, and it's been in unstable for a while already; if worst comes to worst and there is a serious problem with it in testing, it can easily be removed. [But unless there are weird architecture-specific problems, I don't foresee this happening.] It's been in unstable for a couple of weeks only, it has been uploaded only once and it has a limited number of users (according to the popcon). It has only been uploaded once because I've been using earlier versions of the packaging from my unofficial repositories. Moreover, it doesn't seem to fix any RC bug. unscd was made to resolve the problems seen in nscd where nscd is near useless in a system with any amount of load (see #574990 et al.) So, I'd rather keep it in sid and not unblock it. That's your decision, but considering the ease with which the package can be removed if it holds up the release at all (and the real issues with nscd that it resolves), I'd suggest revisiting this decision. Don Armstrong -- Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like color television only with less plot. -- Clement Freud _Grimble_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101125173407.gc16...@teltox.donarmstrong.com
Bug#603982: unblock: unscd/0.47-1 (New Package)
Package: release.debian.org Severity: minor User: release.debian@packages.debian.org Usertags: unblock I'd like to request an unblock of unscd. This is a bit of any unusual request, because unscd is not currently in testing. However, it is pathetically small (2584 lines), is a leaf package, and works significantly better than nscd does. unscd (0.47-1) unstable; urgency=low * Initial packaging for Debian (Closes: #513305) -- Don Armstrong d...@debian.org Tue, 19 Oct 2010 22:21:13 -0700 Description: Micro Name Service Caching Daemon A daemon which handles passwd, group and host lookups for running programs and caches the results for the next query. You only need this package if you are using slow Name Services like LDAP, NIS or NIS+. . This particular NSCD is a complete rewrite of the GNU glibc nscd which is a single threaded server process which offloads all NSS lookups to worker children; cache hits are handled by the parent, and only cache misses start worker children, making the parent immune to resource leaks, hangs, and crashes in NSS libraries. . It should mostly be a drop-in replacement for existing installs using nscd. I've been using it in production for months, and it's been in unstable for a while already; if worst comes to worst and there is a serious problem with it in testing, it can easily be removed. [But unless there are weird architecture-specific problems, I don't foresee this happening.] Don Armstrong -- I cannot find rest Because I am powerless To amend a broken world. -- Guy Gavriel Kay _Under Heaven_ p295 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101119022600.gl5...@rzlab.ucr.edu
Re: Bug#598929: bugs.debian.org: Bugs of severity = important on proposed-updates going to -release
On Sun, 03 Oct 2010, Philipp Kern wrote: It would be very helpful if the Release Team could get bug reports on bugs of severity = important on package versions in proposed-updates sent to debian-release@lists.debian.org as a Cc. Could this possibly be implemented in the BTS? That way we wouldn't miss regressions before they get possibly installed into stable. Currently, the BTS doesn't know anything about package versions which are in proposed-updates unless they're also in unstable. We'd need coordination with ftpmasters to get this information first. The other issue is that you all would only see mails from bugs which happened to fit that criteria at the instant that the message to the bug was sent; you'd still need to examine the bug listings for the packages anyway. Don Armstrong -- Mozart tells us what it's like to be human, Beethoven tells us what it's like to be Beethoven, and Bach tells us what it's like to be the universe. -- Douglas Adams http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101004013413.gc6...@teltox.donarmstrong.com
Re: runinit-run, releaseability thereof
On Thu, 08 Jul 2010, Ian Jackson wrote: * We decided to refer to the Release Team the question as to whether the package is releaseable in its current state. So, we would appreciate it if you would take a look at this situation and decide. When you've decided you should probably set the severity of #562945 so that it's release-critical iff you think runinit-run is not releaseable in its current state. For now I have set the bug to serious. I've reassigned this bug to runit-run, since it's no longer something that the ctte needs to deal with. Release team: if you think this bug makes runit-run unreleaseable, please indicate as such; otherwise I think it's reasonable for the maintainer to downgrade the severity of this bug if the maintainer feels that it is releasable. [If there's some disagreement as to whether it is releasable or not, that technical decision can of course be refered back to the ctte.] Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100728025412.go19...@teltox.donarmstrong.com
perl and perl-modules; reflexive dependencies vs. archive bloat
Currently there is a proposal[0] to combine perl-modules and perl into a single package. perl-modules currently contains architecture independent bits, and perl contains architecture dependent bits. FWICT, the primary argument[1] to do this is because perl and perl-modules both require the other to function properly (so a reflexive dependency or combining is reqeuired), and because circular dependencies make things complicated for dpkg and other frontends. Because this is a common situtation, where there is architecture independent data (of varying sizes) which is interdependent on architecture specific code of a particular version, reflexive dependencies are necessary.[2] Are there still tools which are in use which are unable to handle reflexive dependencies of this type?[3] If so, does the effort to fix them outweigh the effort to remove all of the circular dependencies and the resultant archive bloat?x Don Armstrong 0: http://lists.debian.org/debian-release/2009/10/msg00226.html (cc'ed to -release, but further discussion should not happen there because release isn't a discussion list.) 1: http://lists.alioth.debian.org/pipermail/perl-maintainers/2009-October/000799.html 2: The alternative is of course, archive bloat, where we have multiple copies of such data; the instant case will only contribute around 150M (3.1M*(13 archs-1)*4 releases) to the size of the archive, but I've no doubt that there are larger examples. 3: Specifically, where Package A Depends on (B=1), and Package B Depends on A; A and B are from the same source, B is architecture independent, and does not require configuration. -- The computer allows you to make mistakes faster than any other invention, with the possible exception of handguns and tequila -- Mitch Ratcliffe http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: unblock request: mdadm 2.6.9-3
On Tue, 14 Jul 2009, martin f krafft wrote: Hm, so the BTS pays attention to changelog stanza order (which is chronological) It's not necessarily chronological. without differentiating between experimental and unstable? Sort of. See http://wiki.debian.org/BugsVersionTracking part two. In short, every single version is a decendant of at most one version, which is the *penultimate* version listed in the changelog. If you're uploading experimental packages, the penultimate version should either be the preceeding experimental upload, or the unstable version which the experimental upload is based on. If you're uploading an unstable version, the experimental uploads should not show up in the changelog unless the unstable version is based upon a version which is in experimental. Don Armstrong -- Information wants to be free to kill again. -- Red Robot http://www.dieselsweeties.com/archive.php?s=1372 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installing Debian GNU/Linux 5.0.1
On Tue, 14 Apr 2009, Matt Kraai wrote: debian-cd or debian-release, is it OK to update the links? Is there some documentation of the release process that should be updated to include this step? Heh. I actually just read this after I noticed this and went ahead and fixed the links anyway. If there's something more that needs to be changed, let me (or someone else know.) James: the links will be fixed by the next time the pages are generated; thanks for reporting the problem. Don Armstrong -- Our days are precious, but we gladly see them going If in their place we find a thing more precious growing A rare, exotic plant, our gardener's heart delighting A child whom we are teaching, a booklet we are writing -- Frederick Rükert _Wisdom of the Brahmans_ [Hermann Hesse _Glass Bead Game_] http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Dealing better with CD releases
On Wed, 15 Apr 2009, Steve McIntyre wrote: b. Stop linking directly to the images, and go via redirects. Could maybe be a central cgi, maybe even with intelligence to redirect to good/close/fast/up-to-date mirrors. Could work, but needs implementing. :-) This sounds like a good idea, but there would still need to be logic to detect which mirrors had actually managed to get up to date... and that bit is probably a bit complicated. Don Armstrong -- It's not Hollywood. War is real, war is primarily not about defeat or victory, it is about death. I've seen thousands and thousands of dead bodies. Do you think I want to have an academic debate on this subject? -- Robert Fisk http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Unblock request for spamass-milter [Re: Preapproval of minor fix for #510665]
On Thu, 08 Jan 2009, Neil McGovern wrote: On Wed, Jan 07, 2009 at 06:23:07PM -0800, Don Armstrong wrote: See the attached patch which fixes #510665 (a normal bug) and along the way #496003 (documentation); I'd like to get these into lenny, but before uploading to unstable, pre-approval of the upload would be nice. [I've already tested the changes on stable and unstable, and Marco is (hopefully) double checking that they fix his problem.] Please upload and re-ping when it's hit unstable for an unblock. re-pinging. [It's uploaded to unstable.] Don Armstrong -- Certainly the game is rigged. Don't let that stop you. If you don't bet, you can't win. -- Robert Heinlein _Time Enough For Love_ p240 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Preapproval of minor fix for #510665 (receive header mockup for spamass-milter)
See the attached patch which fixes #510665 (a normal bug) and along
the way #496003 (documentation); I'd like to get these into lenny, but
before uploading to unstable, pre-approval of the upload would be
nice. [I've already tested the changes on stable and unstable, and
Marco is (hopefully) double checking that they fix his problem.]
The interdiff is attached.
Don Armstrong
--
Your village called.
They want their idiot back.
-- xkcd http://xkcd.com/c23.html
http://www.donarmstrong.com http://rzlab.ucr.edu
diff -u spamass-milter-0.3.1/spamass-milter.cpp spamass-milter-0.3.1/spamass-milter.cpp
--- spamass-milter-0.3.1/spamass-milter.cpp
+++ spamass-milter-0.3.1/spamass-milter.cpp
@@ -1024,9 +1024,9 @@
assassin-output((string)
Received: from +macro_s+ (+macro__+)\r\n\t+
- by +macro_j+(+macro_v+/+macro_Z+) with +macro_r+ id +macro_i+\r\n\t+
+ by +macro_j+ (+macro_v+/+macro_Z+) with +macro_r+ id +macro_i+\r\n\t+
macro_b+\r\n\t+
- (envelope-from +assassin-from()+\r\n);
+ (envelope-from +assassin-from()+)\r\n);
} else
assassin-output((string)X-Envelope-To: +envrcpt[0]+\r\n);
diff -u spamass-milter-0.3.1/debian/README.Debian spamass-milter-0.3.1/debian/README.Debian
--- spamass-milter-0.3.1/debian/README.Debian
+++ spamass-milter-0.3.1/debian/README.Debian
@@ -47,14 +47,23 @@
# spamass-milter configuration
smtpd_milters = unix:/var/spool/postfix/spamass/spamass.sock
-should work. See http://www.postfix.org/MILTER_README.html or
+should work. Note, however, if you're using a chrooted version of
+postfix, you'll need the local path to the socket inside of the
+chroot. In recent versions of Debian the following should work:
+
+ # spamass-milter configuration
+ smtpd_milters = unix:/spamass/spamass.sock
+ # milter macros usefull for spamass-milter
+ milter_connect_macros = j {daemon_name} v {if_name} _
+
+See http://www.postfix.org/MILTER_README.html or
/usr/share/doc/postfix/MILTER_README.gz (in postfix-doc) for
information on how to set tempfail and the various timeouts that the
sendmail configuration above uses.
-You'll also want to change /etc/default/spamass-milter to use the
-SOCKET above, and also enable RUNAS so that it runs as the same user
-that will be connecting to the socket.
+The defaults for spamass-milter adjust themselves so that no
+configuration in /etc/default/spamass-milter should be required.
+[However, if you are not doing so, see below.]
-
Adjusting how spamass-milter is started
@@ -62,7 +71,23 @@
You can adjust how spamass-milter starts, and the options it calls
spamc with by adjusting /etc/default/spamass-milter. OPTIONS is passed
-directly to spamass-milter by /etc/init.d/spamass-milter.
+directly to spamass-milter by /etc/init.d/spamass-milter. [Refer to
+spamass-milter(1) for details.]
+
+Other settings which may be of use:
+
+SOCKET sets the location of the socket; defaults to
+/var/run/spamass/spamass.sock unless you are running postfix, where it
+is set to /var/spool/postfix/spamass/spamass.sock.
+
+SOCKETOWNER is the owner of the socket, which defaults to root:root or
+postfix:postfix if you're running postfix.
+
+SOCKETMODE is the mode of the socket, which defaults to 0600 or 0660
+if you're running postfix.
+
+RUNAS controls the user which spamass-milter runs as; defaults to
+spamass-milter.
-
Debugging spamass-milter
@@ -96 +121 @@
- -- Don Armstrong d...@debian.org, Tue, 2 Jan 2007 08:22:46 -0800
+ -- Don Armstrong d...@debian.org, Mon, 5 Jan 2009 13:03:36 -0800
diff -u spamass-milter-0.3.1/debian/NEWS.Debian spamass-milter-0.3.1/debian/NEWS.Debian
--- spamass-milter-0.3.1/debian/NEWS.Debian
+++ spamass-milter-0.3.1/debian/NEWS.Debian
@@ -1,3 +1,11 @@
+spamass-milter (0.3.1-6) unstable; urgency=low
+
+ * Note that users of postfix may wish to add milter_connect_macros = j
+{daemon_name} v {if_name} _ to their main.cf if they haven't already
+done so. See README.Debian.
+
+ -- Don Armstrong d...@debian.org Mon, 05 Jan 2009 13:04:21 -0800
+
spamass-milter (0.3.1-5) unstable; urgency=low
* spamass-milter now tries to run as spamass-milter. This means that the
diff -u spamass-milter-0.3.1/debian/changelog spamass-milter-0.3.1/debian/changelog
--- spamass-milter-0.3.1/debian/changelog
+++ spamass-milter-0.3.1/debian/changelog
@@ -1,3 +1,14 @@
+spamass-milter (0.3.1-8) unstable; urgency=low
+
+ * Update the documentation in README.Debian to indicate that a different
+path to the postfix socket may be required in chrooted postfix
+installs (closes: #496003)
+ * Update milter_connect_macros_line (thanks to Marco d'Itri)
+ * Fix the code to generate a sendmail-compatible header (thanks to Marco
+d'Itri) (Closes: #510665).
+
+ -- Don Armstrong d...@debian.org Mon, 05 Jan 2009 18:40:16 -0800
+
spamass-milter (0.3.1-7) unstable; urgency=low
* Add LSB
Re: this week's Xorg freeze exceptions...
On Fri, 26 Sep 2008, Don Armstrong wrote:
On Fri, 26 Sep 2008, Philipp Kern wrote:
am Fri, Sep 26, 2008 at 11:24:02AM +0200 hast du folgendes geschrieben:
Looks like debbugs (or britney?) is broken, bug#211765 doesn't get
properly ignored. Can I get a force in addition to the unblock?
well, the bug is in BugsV for unstable. Technically it's correct but
currently britney cannot know that a bug is tagged lenny-ignore, I
think. So it's a regression over the buglist of the version in
testing.
[...]
In any event, for the purposes of britney counts, I have just ignored
all bugs tagged lenny-ignore for bugs in unstable. [Those bugs are
still present and buggy in unstable, but assuming I did everything
right, they should be ignored in the unstable-nr and unstable counts
in b.d.o/bugscan/britney/unstable{,-nr}.]
So, as promised:
xmovie 436173
xorp 500325,494223
xpdf-japanese 481134
xserver-xorg 500228
xserver-xorg-core 488669
xserver-xorg-input-magictouch 491204
xserver-xorg-input-wacom 482826
xserver-xorg-video-glint 493887
xserver-xorg-video-mach64 500358
xserver-xorg-video-vesa 488932
Don Armstrong
--
Of course, there are cases where only a rare individual will have the
vision to perceive a system which governs many people's lives; a
system which had never before even been recognized as a system; then
such people often devote their lives to convincing other people that
the system really is there and that it aught to be exited from.
-- Douglas R. Hofstadter _Gödel Escher Bach. Eternal Golden Braid_
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: this week's Xorg freeze exceptions...
On Fri, 26 Sep 2008, Philipp Kern wrote:
am Fri, Sep 26, 2008 at 11:24:02AM +0200 hast du folgendes geschrieben:
Looks like debbugs (or britney?) is broken, bug#211765 doesn't get
properly ignored. Can I get a force in addition to the unblock?
well, the bug is in BugsV for unstable. Technically it's correct but
currently britney cannot know that a bug is tagged lenny-ignore, I
think. So it's a regression over the buglist of the version in
testing.
Those bugs should just be ignored by britney entirely for the purpose
of testing propogation. [I did recently change the way that the
distribution tags were handled, but that shouldn't have any relevance
to this case.]
In any event, for the purposes of britney counts, I have just ignored
all bugs tagged lenny-ignore for bugs in unstable. [Those bugs are
still present and buggy in unstable, but assuming I did everything
right, they should be ignored in the unstable-nr and unstable counts
in b.d.o/bugscan/britney/unstable{,-nr}.]
So that could either be solved by appearing in BugsV for testing and
unstable (i.e. no regression) or suppressing it from unstable's
BugsV. I don't know if there are users of this files besides
britney...
Could it be a problem that this very bug is not properly versionned?
That shouldn't be a problem.
Don Armstrong
--
CNN/Reuters: News reports have filtered out early this morning that US
forces have swooped on an Iraqi Primary School and detained 6th Grade
teacher Mohammed Al-Hazar. Sources indicate that, when arrested,
Al-Hazar was in possession of a ruler, a protractor, a set square and
a calculator. US President George W Bush argued that this was clear
and overwhelming evidence that Iraq indeed possessed weapons of math
instruction.
http://www.donarmstrong.com http://rzlab.ucr.edu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suite tags (Re: Doing some stable QA work)
On Fri, 15 Aug 2008, Frank Lichtenheld wrote: On Thu, Aug 14, 2008 at 08:08:10PM -0700, Steve Langasek wrote: On Thu, Aug 14, 2008 at 11:01:46PM -0400, Filipus Klutiero wrote: Tagging lenny and sid does not imply that other suites are free from the bug, Yes, it does. It only implies that for britney; the BTS itself ignores it save for archiving. It's quite likely that we should change this, but it's not the way it works currently. [1] How to interpret those tags has always been problematic in my mind, but I suppose the following interpretation would resolve what the release managers are looking for, and would also work for the bts. *** proposal *** For the purposes of determining buginess, setting a distribution tag limits the bugginess of a package in distribtions to the intersection of the distributions and the version-based bugginness of a package. This means that a bug that would normally be buggy in etch and lenny (but fixed in sid) due to the versions present of that package would only be present in lenny if tagged lenny and tagged sid. For the purposes of archival, we just use the buginess state above instead, defaulting to (testing distribution), sid. *** end proposal *** Does that meet the needs of the RMs et al? Are there any objections? Don Armstrong 1: It's quite likely that we talked about the way it should work, and I totally forgot about what we decided that it should do after promising that I'd change it. My brain is at its base, a sieve. -- Miracles had become relative common-places since the advent of entheogens; it now took very unusual circumstances to attract public attention to sightings of supernatural entities. The latest miracle had raised the ante on the supernatural: the Virgin Mary had manifested herself to two children, a dog, and a Public Telepresence Point. -- Bruce Sterling, _Holy Fire_ p228 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suite tags (Re: Doing some stable QA work)
On Fri, 15 Aug 2008, Luk Claes wrote: Don Armstrong wrote: *** proposal *** For the purposes of determining buginess, setting a distribution tag limits the bugginess of a package in distribtions to the intersection of the distributions and the version-based bugginness of a package. This means that a bug that would normally be buggy in etch and lenny (but fixed in sid) due to the versions present of that package would only be present in lenny if tagged lenny and tagged sid. Does this also mean that the bug would not be present anywere when the intersection would be empty (tagged lenny with a version higher than the one in testing for instance)? Right. [I submit that in such a case, the lenny tag should be removed if it actually affects unstable; possibly it shouldn't have been applied in the first case.] We should probably look at all the possibilities and think about good defaults for them? We should think about them, but whatever decision we make needs to apply to all of the possible distribution tags in a similar manner. [That is, I really don't want to special case every single tag, because that's not maintainable.] Don Armstrong -- If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money it values more, it will lose that, too. -- W. Somerset Maugham http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: suite tags (Re: Doing some stable QA work)
On Fri, 15 Aug 2008, Filipus Klutiero wrote: Supposing your proposal is accepted, would the debbugs teams copy the state of the stable tag when creating a new testing tag? For example, would a bug tagged lenny get the tag for Debian 6 when adding that tag? Not automatically, but it's not like doing this manually in a single shot is hard. Don Armstrong -- Only one creature could have duplicated the expressions on their faces, and that would be a pigeon who has heard not only that Lord Nelson has got down off his column but has also been seen buying a 12-bore repeater and a box of cartridges. -- Terry Pratchet _Mort_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Original bug in gdc fixed; binary rebuilds probably need to be requested for broken powerpc packages
The original bug which caused all of these blocking bugs has been fixed; rebuilds probably need to be requested for all of these packages. Don Armstrong -- This can't be happening to me. I've got tenure. -- James Hynes _Publish and Perish_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
