Bug#1020336: Probably false warning for "read-foobar" as bashism
Package: devscripts Version: 2.21.3+deb11u1 Tags: patch I have a user-installed program called "read-foobar". When I use checkbashisms on a script that calls that, it consid- ers this a bashism: | root@26dda7136b02:/# checkbashisms < #!/bin/sh | > read-foobar | > EOF | possible bashism in (stdin) line 2 (read without variable): | read-foobar | root@26dda7136b02:/# (Is there some special semantics in bash for commands begin- ning with "read-" that I am missing?) The matching regular expression is: | $LEADIN | . qr'read\s*(?:-\w+\s*)*(?:\".*?\"|[\'].*?[\'])?\s*(?:;|$)' => | q, This appears to be intended to match "read" and then zero or more options followed by an optional string literal. So a quick and dirty fix would be: | $LEADIN | . qr'read(?:\s+(?:-\w+\s*)*(?:\".*?\"|[\'].*?[\'])?)?\s*(?:;|$)' => | q, to match only on "read", optional whitespace and end-of-com- mand, or "read", whitespace, the existing pattern and end- of-command. A test case would be: | read-foobar | read-foobar -r | read-foobar file.txt not being marked as bashisms.
Bug#737673: incorrect comment highlighting in package descriptions
David Bremner wrote: > […] > I tried the obvious-to-me fix of anchoring the regex comment-start-skip, > but it didn't work (like so many obvious things ;)). If anybody has a > better understanding of comments and font-lock, suggestions welcome. AFAIU https://stackoverflow.com/questions/25245469 and others, changing comment-start-skip is not enough. Instead, one must define one's own syntax-propertize-function (cf. perl-syntax-propertize-function & Co.). Tim
Bug#831435: www.debian.org: Link to the patch tracker broken - will fix it
The source code is in a Git repository at https://anonscm.debian.org/git/webwml/packages.git (https://packages.debian.org/stretch/python-pip, "Learn more about this site." => https://packages.debian.org/about/). The patch is already committed (5a638ca4744b3bb68db35a92b70c568223809afd), but it has not been deployed yet? Probably only the Debian Website Team can deploy it (or confirm that is has been deployed, but it is faulty).
Bug#805451: Bugs/Reporting: please document for each pseudo-header in which addr...@bugs.debian.org it can be used
Kind of related: I find the "Mail servers' reference card" at https://www.debian.org/Bugs/server-refcard not helpful at all. I expect a reference card to briefly describe each command that is used in day-to-day operations; instead, the Debian Bugs one just lists (all?) commands and their synop- sis, but /not/ what they do, neither does the list of "bug submission and followup addresses". I find myself constantly cycling through three or four pages on debian.org and browsing through source code to (in the end) /guess/ what I need to do to achieve something.
Bug#751808: forcemerge should not care about the order of blocking bugs
tag 751808 + patch
thanks
I wrote:
> […]
> I tried to come up with a test case (cf. attachment), but
> that does not trigger the bug.
> […]
… consistently. The order of "Blocked-By:" in *.summary is
non-deterministic, so often the test would succeed and only
occasionally fail. I therefore added some code to force
bug #9 to have "Blocked-By: 3 4" and bug #10
"Blocked-By: 4 3" and, et voilà, "merge" does not like it,
but sorting the "blockedby" list in
Debbugs::Status::readbug() fixes the issue.
The attached patch might need some prettification before
merging.
diff --git a/Debbugs/Status.pm b/Debbugs/Status.pm
index 4b8d82e..17c4578 100644
--- a/Debbugs/Status.pm
+++ b/Debbugs/Status.pm
@@ -282,6 +282,17 @@ sub read_bug{
$data{archived} = (defined($location) and ($location eq 'archive'))?1:0;
$data{bug_num} = $param{bug};
+# Sort blockedby numerically so that bugs with identical blockers
+# have identical lists.
+if (defined $data{blockedby} and
+ $data{blockedby}) {
+ $data{blockedby} =
+ join(' ',
+ sort { $a <=> $b }
+ split / /, $data{blockedby}
+ );
+}
+
# mergedwith occasionally is sorted badly. Fix it to always be sorted by <=>
# and not include this bug
if (defined $data{mergedwith} and
diff --git a/t/12_merge.t b/t/12_merge.t
index c654359..533bd2f 100644
--- a/t/12_merge.t
+++ b/t/12_merge.t
@@ -1,6 +1,6 @@
# -*- mode: cperl;-*-
-use Test::More tests => 35;
+use Test::More tests => 42;
use warnings;
use strict;
@@ -141,7 +141,7 @@ send_message(to => 'control@bugs.something',
],
body => <<'EOF') or fail 'message to control@bugs.something failed';
debug 10
-clone 2 -1 -2 -3 -4 -5 -6
+clone 2 -1 -2 -3 -4 -5 -6 -7 -8
retitle 2 foo
owner 2 b...@baz.com
submitter 2 f...@bleh.com
@@ -158,6 +158,10 @@ fixed -4 1.2-3
found -4 1.2-1
found -5 1.2-5
fixed -5 1.2-6
+block -7 by -1
+block -7 by -2
+block -8 by -2
+block -8 by -1
thanks
EOF
;
@@ -166,6 +170,13 @@ EOF
$sendmail_dir,
'control@bugs.something messages appear to have been sent out properly');
+# The order of "Blocked-By:" in *.summary is not deterministic, so
+# these tests assert that the blockers of bugs #9 and #10 are sorted
+# differently.
+ok(system('perl', '-i', '-pwe', 's/^Blocked-By: 4 3\n/Blocked-By: 3 4\n/;', $spool_dir . '/db-h/09/9.summary') == 0, 'Changed bug #9');
+ok(system('perl', '-i', '-pwe', 's/^Blocked-By: 3 4\n/Blocked-By: 4 3\n/;', $spool_dir . '/db-h/10/10.summary') == 0, 'Changed bug #10');
+is(`grep '^Blocked-By: ' $spool_dir/db-h/09/9.summary`, "Blocked-By: 3 4\n", 'Bug #9 has "Blocked-By: 3 4"');
+is(`grep '^Blocked-By: ' $spool_dir/db-h/10/10.summary`, "Blocked-By: 4 3\n", 'Bug #10 has "Blocked-By: 4 3"');
test_control_commands(forcemerge => {command => 'forcemerge',
value => '1 2',
@@ -193,6 +204,12 @@ test_control_commands(forcemerge => {command => 'forcemerge',
status_value => '8',
bug => '7',
},
+ merge=> {command => 'merge',
+ value => '9 10',
+ status_key => 'mergedwith',
+ status_value => '10',
+ bug => '9',
+ },
);
Bug#751808: forcemerge should not care about the order of blocking bugs
I ran into this today with:
| > forcemerge 861174 825980
| Bug #861174 [wnpp] ITP: elpa-elpy -- Emacs Python Development Environment
| Bug #825980 [wnpp] RFP: elpy -- Emacs Lisp Python environment
| 825980 was blocked by: 875906 870705
| 825980 was not blocking any bugs.
| Added blocking bug(s) of 825980: 861242
| Owner recorded as Nicholas D Steeves .
| Bug #825980 [wnpp] RFP: elpy -- Emacs Lisp Python environment
| Unable to complete merge on previous attempt; trying again (retry: 2)
| Bug #825980 [wnpp] RFP: elpy -- Emacs Lisp Python environment
| Unable to complete merge on previous attempt; trying again (retry: 3)
| Bug #825980 [wnpp] RFP: elpy -- Emacs Lisp Python environment
| After four attempts, the following changes were unable to be made:
| blockedby of #825980 is '861242 875906 870705' not '870705 875906 861242'
| Failed to forcibly merge 861174: Unable to modify bugs so they could be
merged.
and, with inspiration from Mattia's report, solved it by un-
blocking, then merging, then blocking again.
I tried to come up with a test case (cf. attachment), but
that does not trigger the bug.
Did-not-read-the-source-question: In bugs.debian.org, is the
authoritative "Blocked-By" information kept in something
like /tmp/*/db-h/*/*.summary as well? Looking at data from
bugs-mirror, there are lots of bugs where the list is not
sorted:
| […]
| ./09/646309.summary:Blocked-By: 671277 661665
| ./08/857108.summary:Blocked-By: 872286 872282
| ./08/805308.summary:Blocked-By: 694137 844009 780694 844079 805415 826560
844014 844075 805411 844072 805413 774567
| ./08/795208.summary:Blocked-By: 790690 767969
| ./08/646308.summary:Blocked-By: 671277 661665
| ./07/873407.summary:Blocked-By: 873428 873427
| […]
Debbugs::Status::read_bug() has code sorting mergedwith:
| […]
| # mergedwith occasionally is sorted badly. Fix it to always be sorted by
<=>
| # and not include this bug
| if (defined $data{mergedwith} and
|$data{mergedwith}) {
| $data{mergedwith} =
| join(' ',
| grep { $_ != $data{bug_num}}
| sort { $a <=> $b }
| split / /, $data{mergedwith}
| );
| }
| […]
If random order for "Blocked-By:" entries in *.summary files
could be the cause of this bug, I think adding similar code
for blockedby would fix it.
diff --git a/t/12_merge.t b/t/12_merge.t
index c654359..dd40db9 100644
--- a/t/12_merge.t
+++ b/t/12_merge.t
@@ -1,6 +1,6 @@
# -*- mode: cperl;-*-
-use Test::More tests => 35;
+use Test::More tests => 38;
use warnings;
use strict;
@@ -141,7 +141,7 @@ send_message(to => 'control@bugs.something',
],
body => <<'EOF') or fail 'message to control@bugs.something failed';
debug 10
-clone 2 -1 -2 -3 -4 -5 -6
+clone 2 -1 -2 -3 -4 -5 -6 -7 -8
retitle 2 foo
owner 2 b...@baz.com
submitter 2 f...@bleh.com
@@ -158,6 +158,10 @@ fixed -4 1.2-3
found -4 1.2-1
found -5 1.2-5
fixed -5 1.2-6
+block -7 by -1
+block -7 by -2
+block -8 by -2
+block -8 by -1
thanks
EOF
;
@@ -193,6 +197,12 @@ test_control_commands(forcemerge => {command => 'forcemerge',
status_value => '8',
bug => '7',
},
+ merge=> {command => 'merge',
+ value => '9 10',
+ status_key => 'mergedwith',
+ status_value => '10',
+ bug => '9',
+ },
);
Bug#831435: www.debian.org: Link to the patch tracker broken
AFAICT:
| diff --git a/templates/config.tmpl b/templates/config.tmpl
| index 3f64edf..f1f7c84 100644
| --- a/templates/config.tmpl
| +++ b/templates/config.tmpl
| @@ -22,7 +22,7 @@
| changelogs_url = 'http://ftp-master.metadata.debian.org/changelogs/'
| policy_url = 'https://www.debian.org/doc/debian-policy/'
| cn_help_url = project_homepage _ 'intro/cn'
| - patch_tracking_url = 'http://sources.debian.net/patches/summary'
| + patch_tracking_url = 'http://sources.debian.net/patches'
| screenshots_url = 'https://screenshots.debian.net/package/'
| screenshots_thumb_url =
'https://screenshots.debian.net/thumbnail-with-version/'
| logo = {
should fix it.
Tim
Bug#814784: ITP: diamond -- smart data producer for graphite graphing package
Ooops, sorry, I only saw the ITP and did not check how far you had already gotten.
Bug#814784: ITP: diamond -- smart data producer for graphite graphing package
Hi Sandro, at the Wikimedia Foundation, Filippo packaged diamond for Debian Jessie and Ubuntu Precise and Trusty, so that might be a useful inspiration/source. I can't find the Git repos- itory for the package, but you should be able to pull the source from http://apt.wikimedia.org/wikimedia/'s jessie-wikimedia repository; if not, I can mail you the files (MIT licensed). HTH, Tim
Bug#801328: crontab(5) has incorrect information about bash's $PATH handling
Package: cron Version: 3.0pl1-127+deb8u1 Severity: normal Change 876cc36d1e26f73391a79196dd6d591187049c9e in pkg-cron added the paragraph: | [...] |An alternative for setting up the commands path is using the |fact that many shells will treat the tilde(~) as substitution |of $HOME, so if you use bash for your tasks you can use this: | SHELL=/bin/bash | PATH=~/bin:/usr/bin/:/bin | [...] Specifically bash (and probably other shells as well) only treats the tilde in this way when expanding the command line that /sets/ the environment variable, not when /reading/ it for the path of an executable. I. e., in a shell session/script, the second line would cause $PATH to be set to (for example) "/home/tim/bin:/usr/bin/:/bin", while if it is set in this manner in a crontab, in the shell it is set to "~/bin:/usr/bin/:/bin" (and thus wouldn't find executables in /home/tim/bin, but only in the subdirectory "bin" of the subdirectory "~" of the current directory (and /usr/bin and /bin)). The paragraph should be removed completely.
Bug#786800: RFP: libmediawiki-bot-perl -- Perl high-level bot framework for interacting with MediaWiki wikis
Package: wnpp Severity: wishlist * Package name: libmediawiki-bot-perl Version : 5.006002 Upstream Author : Mike.lifeguard * URL : https://metacpan.org/module/MediaWiki::Bot * License : GPL Programming Lang: Perl Description : Perl high-level bot framework for interacting with MediaWiki wikis MediaWiki::Bot is a framework that can be used to write bots which interface with the MediaWiki API (http://en.wikipedia.org/w/api.php). We are using this module locally and would like to see this packaged properly (cf. https://phabricator.wikimedia.org/T91874). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#786796: RFP: python-oursql -- MySQL bindings for Python
Package: wnpp Severity: wishlist * Package name: python-oursql Version : 0.9.3 Upstream Author : Aaron Gallagher * URL : https://launchpad.net/oursql * License : BSD Programming Lang: Python Description : MySQL bindings for Python oursql is a set of MySQL bindings for python 2.4+ with a focus on provididing real parameterization and real server-side cursors. MySQL 4.1.2 or better is required. We are using this module locally and would like to see this packaged properly (cf. https://phabricator.wikimedia.org/T91874). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782501: "apt-get clean" deletes temporary files written by a running "apt-get update"
I wrote: > [...] > IMHO apt-get should not delete temporary files owned by another > process. > [...] That may unnecessarily narrow down potential fixes for this bug. Of course it would be possible as well (and maybe preferable) for "apt-get update" (and other commands?) to create their temporary files elsewhere or, depending on com- patibility and privilege considerations, use linkat(2) with AT_EMPTY_PATH. Tim -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#782501: "apt-get clean" deletes temporary files written by a running "apt-get update"
Package: apt Version: 1.0.9.7 Severity: normal Dear Maintainer, unattended-upgrades regularly complained about (cf. https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/1366708): | E:Problem renaming the file /var/cache/apt/pkgcache.bin.WfLyE7 to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory) | W:You may want to run apt-get update to correct these problems Googling brought up https://bugs.launchpad.net/landscape-client/+bug/1091137: | When the landscape-client runs apt-get update, it can return an error like this: | E: Problem renaming the file /var/cache/apt/pkgcache.bin.PGPOhV to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory) | W: You may want to run apt-get update to correct these problems | This can happen if someone is running apt-get clean, while the update is happening. apt-get clean | removes all pkgcache.bin files, including the temporary ones that apt-get update uses | to rebuild the cache. This error is harmless, since pkgcache.bin should also have been | removed, and thus the next time the cache will be opened the cache will be rebuilt. | I.e, we should ignore the error above as to not cause intermittent alerts in the Landscape | server, that the user can't do anything to resolve. And indeed the error is reproducable by: | scfc@toolsbeta-jessie3:~$ while sudo apt-get clean; do :; done & sudo apt-get update; kill -HUP %% | [1] 6241 | Hit http://apt.wikimedia.org jessie-wikimedia InRelease | Hit http://mirrors.wikimedia.org jessie InRelease | Hit http://mirrors.wikimedia.org jessie-updates InRelease | Hit http://apt.wikimedia.org jessie-wikimedia/main Sources | Hit http://apt.wikimedia.org jessie-wikimedia/backports Sources | Get:1 http://mirrors.wikimedia.org jessie/main Sources/DiffIndex [7,876 B] | Hit http://security.debian.org jessie/updates InRelease | Hit http://apt.wikimedia.org jessie-wikimedia/thirdparty Sources | Hit http://apt.wikimedia.org jessie-wikimedia/main amd64 Packages | Hit http://apt.wikimedia.org jessie-wikimedia/backports amd64 Packages | Hit http://apt.wikimedia.org jessie-wikimedia/thirdparty amd64 Packages | Get:2 http://mirrors.wikimedia.org jessie/main amd64 Packages/DiffIndex [7,876 B] | Get:3 http://mirrors.wikimedia.org jessie/main Translation-en/DiffIndex [7,876 B] | Hit http://mirrors.wikimedia.org jessie-updates/main Sources | Hit http://mirrors.wikimedia.org jessie-updates/main amd64 Packages | Hit http://mirrors.wikimedia.org jessie-updates/main Translation-en | Ign http://apt.wikimedia.org jessie-wikimedia/backports Translation-en_US | Ign http://apt.wikimedia.org jessie-wikimedia/backports Translation-en | Ign http://apt.wikimedia.org jessie-wikimedia/main Translation-en_US | Ign http://apt.wikimedia.org jessie-wikimedia/main Translation-en | Ign http://apt.wikimedia.org jessie-wikimedia/thirdparty Translation-en_US | Ign http://apt.wikimedia.org jessie-wikimedia/thirdparty Translation-en | Hit http://security.debian.org jessie/updates/main Sources | Hit http://security.debian.org jessie/updates/main amd64 Packages | Hit http://security.debian.org jessie/updates/main Translation-en | Fetched 23.6 kB in 1s (12.2 kB/s) | Problem renaming the file /var/cache/apt/srcpkgcache.bin.ZDdbP3 to /var/cache/apt/srcpkgcache.bin - rename (2: No such file or directory) | Problem renaming the file /var/cache/apt/pkgcache.bin.93xAUQ to /var/cache/apt/pkgcache.bin - rename (2: No such file or directory) | The package lists or status file could not be parsed or opened. | Can't call method "policy" on an undefined value at /usr/bin/apt-show-versions line 56. | E: Problem executing scripts APT::Update::Post-Invoke-Success 'test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i' | E: Sub-process returned an error code | scfc@toolsbeta-jessie3:~$ IMHO apt-get should not delete temporary files owned by another process. -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd6
Bug#677666: pbuilder: using BUILDUSERNAME does not change USER
Hi,
I encountered a similar problem with pbuilder 0.208ubuntu1,
and the attached patch fixed it for me.
Tim
--- /usr/lib/pbuilder/pbuilder-buildpackage~ 2012-03-14 15:03:46.0 +
+++ /usr/lib/pbuilder/pbuilder-buildpackage 2014-01-08 14:53:25.991992079 +
@@ -36,9 +36,9 @@
# LD_PRELOAD: Normal users don't have write access to build
# environment, so cowdancer shouldn't have to run, and fakeroot
# should be running later, so it shouldn't matter.
-# LOGNAME: set this to shut up some tools.
+# LOGNAME and USER: set this to shut up some tools.
# su -p : switch to user preserving env vars, we need most of them.
-SUTOUSER="env LD_PRELOAD= LOGNAME=$BUILDUSERNAME su -p $BUILDUSERNAME"
+SUTOUSER="env LD_PRELOAD= LOGNAME=$BUILDUSERNAME USER=$BUILDUSERNAME su -p $BUILDUSERNAME"
DEBBUILDOPTS="${DEBBUILDOPTS:+$DEBBUILDOPTS }-rfakeroot"
EXTRAPACKAGES="${EXTRAPACKAGES} fakeroot"
log "I: using fakeroot in build."
