Bug#850080: rescue/modules/a0_prep-root: line 32: debirf_info_sh: command not found

[Daniel Kahn Gillmor]

On Tue 2017-01-03 17:06:00 -0500, Jameson Graef Rollins wrote:
> On Tue, Jan 03 2017, Daniel Kahn Gillmor  wrote:
>> trying to build the rescue image on stretch/sid, i get:
>>
>> run-parts: executing rescue/modules/a0_motd
>> run-parts: executing rescue/modules/a0_prep-root
>> dpkg: warning: failed to open configuration file '/root/.dpkg.cfg' for 
>> reading: Permission denied
>> rescue/modules/a0_prep-root: line 32: debirf_info_sh: command not found
>> run-parts: rescue/modules/a0_prep-root exited with return code 127
>
> I can reproduce this.  It appears that the functions from
> /usr/share/debirf/common are no longer being executed to the modules,
> even though other environment variables are.  Why would the functions no
> longer be exported?  Is this due to a change in bash? run-parts?
> fakeroot?

This is a good question!  it looks to me like something is happening
between bash and fakeroot!  On a stretch/sid system:

0 dkg@alice:~$ unset -f foo
0 dkg@alice:~$ bash -c foo
bash: foo: command not found
127 dkg@alice:~$ foo() { echo bar; }
0 dkg@alice:~$ export -f foo
0 dkg@alice:~$ bash -c foo
bar
0 dkg@alice:~$ fakeroot bash -c foo
bash: foo: command not found
127 dkg@alice:~$ 


otoh, the same thing happens when i interject through other shells, but
not when i pass it through bash itself:

0 dkg@alice:~$ dash -c 'bash -c foo'
bash: foo: command not found
127 dkg@alice:~$ posh -c 'bash -c foo'
bash: foo: command not found
127 dkg@alice:~$ bash -c 'bash -c foo'
bar
0 dkg@alice:~$ 


bash caches these functions in the environment as BASH_FUNC_foo%%, but
somehow only transmits them to children:

0 dkg@alice:~$ printenv BASH_FUNC_foo%%
() {  echo bar
}
0 dkg@alice:~$ dash -c 'printenv BASH_FUNC_foo%%'
1 dkg@alice:~$ bash -c 'printenv BASH_FUNC_foo%%'
() {  echo bar
}
0 dkg@alice:~$ fakeroot printenv BASH_FUNC_foo%%
1 dkg@alice:~$ 


This is *not* the case on jessie systems:

[0 dkg@grunt ~]$ foo() { echo bar; }
[0 dkg@grunt ~]$ export -f foo
[0 dkg@grunt ~]$ bash -c foo
bar
[0 dkg@grunt ~]$ dash -c 'bash -c foo'
bar
[0 dkg@grunt ~]$ fakeroot bash -c foo
bar
[0 dkg@grunt ~]$ printenv BASH_FUNC_foo%%
() {  echo bar
}
[0 dkg@grunt ~]$ fakeroot printenv BASH_FUNC_foo%%
() {  echo bar
}
[0 dkg@grunt ~]$


So this definitely looks to me like we're running into a shellshock
countermeasure, but i don't understand the countermeasures well enough
to know how to proceed with a fix, other than explicitly sourcing the
predefined functions in each module.

any suggestions?

   --dkg


signature.asc
Description: PGP signature

Bug#844134: Request for help - scilab segfaults with TSX

[Gilles Filippini]

On 2017-01-04 19:51, Samuel Thibault wrote:

Hello,

Gilles Filippini, on Wed 04 Jan 2017 19:31:28 +0100, wrote:

On Wed, 28 Dec 2016 02:23:24 +0200 Adrian Bunk  wrote:
> This looks like a threading bug in Scilab exposed by TSX.

I've just noticed this RC bug [1] against scilab.


FYI, glibc is about to just disable TSX entirely in version 2.24-9,
which will just get rid of the issue for Stretch.


Thanks!

_g.

Bug#850183: stretch-ignore tag for RC bug #844134 against scilab

[Gilles Filippini]

Package: release.debian.org
Severity: normal

Hi Release Team,

Would you agree to tag #844134 (scilab segfaults with TSX) stretch-ignore since 
TSX is about to be disabled for stretch [1][2]?

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844134#32
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850182

Many thanks in advance,

_g.

Bug#850184: dirmngr: TLS verification fails with "hostname does not match"

[Tomasz Nitecki]

Package: dirmngr
Version: 2.1.17-2
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

After I tried to fetch keys through hkps, I was greeted with "General error"
message. When I retried with clear hkp, everything worked fine.

When I called dirmngr directly, I received the following error:
(...)
dirmngr[13694.0]: TLS verification of peer failed: hostname does not match
dirmngr[13694.0]: DBG: expected hostname: hkps.pool.sks-keyservers.net.
(...)

Full log is attached below.

Downgrading to 2.1.16-3 fixed this issue (log is also below).

This issue seems to be related to #771666 (it might be a regression),
it is also possible that it might be related to #849845 (just a guess).


Regards,
T.


- -- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (100, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dirmngr depends on:
ii  adduser3.115
ii  libassuan0 2.4.3-2
ii  libc6  2.24-8
ii  libgcrypt201.7.5-2
ii  libgnutls303.5.7-3
ii  libgpg-error0  1.25-2
ii  libksba8   1.3.5-2
ii  libldap-2.4-2  2.4.44+dfsg-2
ii  libnpth0   1.3-1
ii  lsb-base   9.20161125

Versions of packages dirmngr recommends:
ii  gnupg  2.1.17-2

Versions of packages dirmngr suggests:
ii  tor  0.2.9.8-2

- -- no debconf information

*** /home/tnnn/dev/storage/dirmngr-hostname-issue.log
## dirmngr 2.1.17-2 (hostname matching problem):

user@host:~$ echo -e "KEYSERVER hkps://hkps.pool.sks-keyservers.net\nKS_SEARCH 
2071B08A33BD3F06\n" | dirmngr
dirmngr[13694]: error opening '/home/user/.gnupg/dirmngr_ldapservers.conf': No 
such file or directory
dirmngr[13694.0]: permanently loaded certificates: 0
dirmngr[13694.0]: runtime cached certificates: 0
# Home: /home/user/.gnupg
# Config: /home/user/.gnupg/dirmngr.conf
OK Dirmngr 2.1.17 at your service
OK
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'sks.spodhuis.org'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'bone.digitalis.org'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'prod00.keyserver.dca.witopia.net'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gpg.NebrWesleyan.edu'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'[2001:bc8:4700:2300::10:f15]'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'hufu.ki.iif.hu'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gozer.rediris.es'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'[2001:470:1:116::6]'
S PROGRESS tick ? 0 0
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'zimmermann.mayfirst.org'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'bone.digitalis.org' [already known]
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'ip-209-135-211-141.ragingwire.net'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'hufu.ki.iif.hu' [already known]
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gpg.NebrWesleyan.edu' [already known]
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'gozer.rediris.es' [already known]
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'sks.spodhuis.org' [already known]
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'ams.sks.heypete.com'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'host-37-191-238-78.lynet.no'
dirmngr[13694.0]: resolve_dns_addr for 'hkps.pool.sks-keyservers.net': 
'cryptonomicon.mit.edu'
dirmngr[13694.0]: TLS verification of peer failed: hostname does not match
dirmngr[13694.0]: DBG: expected hostname: hkps.pool.sks-keyservers.net.
dirmngr[13694.0]: DBG: BEGIN Certificate 'server[0]':
dirmngr[13694.0]: DBG:  serial: 75
dirmngr[13694.0]: DBG:   notBefore: 2016-04-24 18:44:05
dirmngr[13694.0]: DBG:notAfter: 2017-04-24 18:44:05
dirmngr[13694.0]: DBG:  issuer: CN=sks-keyservers.net 
CA,O=sks-keyservers.net CA,ST=Oslo,C=NO
dirmngr[13694.0]: DBG: subject: CN=sks.spodhuis.org,OU=PGP 
Keyserver,O=GlobNIX Systems,C=NL
dirmngr[13694.0]: DBG:   hash algo: 1.2.840.113549.1.1.11
dirmngr[13694.0]: DBG:   SHA1 fingerprint: 
3B7F90096DBE8BCEC510652FB0485841A4F4062D
dirmngr[13694.0]: DBG: END Certificate
dirmngr[13694.0]: DBG: BEGIN Certificate 'server[1]':
dirmngr[13694.0]: DBG:  serial: 00AF73C8B4CF9F808F
dirmngr[13694.0]: DBG:   notBefore: 2012-10-09 00:33:37
dirmngr[13694.0]: DBG:notAfter: 2022-10-07 00:33:37
dirmngr[13694.0]: DBG:  issuer: CN=sks-keyservers.net 
CA,O=sks-keyservers.net CA,ST=Oslo,C=NO
dirmngr[13694.0]: DBG: subject: CN=sks-keyservers.

Bug#850077: duplicity: Backup fail since upgrade of python-crypto from 2.6-4+deb7u3 to 2.6-4+deb7u4

[Alexander Zangerl]

reassign 850077 python-paramiko
retitle 850077 python-paramiko doesn't work with python-crypto 2.6-4
thanks,

On Tue, 03 Jan 2017 21:49:21 +0100, Patrick Valsecchi writes:
>Since yesterday's update, backup to a SSH target is broken and leads to this st
>acktrace:
>
>ssh: Unknown exception: CTR mode needs counter parameter, not IV
>ssh: Traceback (most recent call last):
>ssh:   File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1542
>, in run
>ssh: self.kex_engine.parse_next(ptype, m)

this is a bug in python-paramiko, not duplicity. as far as i
can tell that particular problem seems to be known to paramiko's
upstream and tracked at https://github.com/paramiko/paramiko/issues/713
i've got no idea what paramiko releases do contain the fix.

the workarounds options for duplicity and for now include
your python-crypto downgrade, or falling back to the ssh/pexpect ssh backend.

regards
az





-- 
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Q. how many lightbulbs does it take to change a light bulb?
A. one, if it knows its own Goedel number.


signature.asc
Description: Digital Signature

Bug#850080: rescue/modules/a0_prep-root: line 32: debirf_info_sh: command not found

[Jameson Graef Rollins]

On Wed, Jan 04 2017, Daniel Kahn Gillmor  wrote:
> So this definitely looks to me like we're running into a shellshock
> countermeasure, but i don't understand the countermeasures well enough
> to know how to proceed with a fix, other than explicitly sourcing the
> predefined functions in each module.
>
> any suggestions?

I think we need to assume we can't export functions through fakeroot
going forward.  The only alternatives I see are to explicitly source the
common file in the modules, as you suggest, or to actually make scripts
for all the shell functions and put them in the path somewhere.  I don't
have any better suggestions than that.

jamie.


signature.asc
Description: PGP signature

Bug#838133: flex: FTBFS on hurd-i386

[Christoph Berg]

NMU diff attached.

Christoph

No differences were encountered between the control files

diff -Nru flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog	2017-01-04 20:24:42.0 +0100
+++ flex-2.6.1/debian/changelog	2017-01-04 20:24:42.0 +0100
@@ -1,3 +1,11 @@
+flex (2.6.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS on hurd (upstream 7975c43384d766ca12cb3f292754dbdc34168886).
+(Closes: 838133).
+
+ -- Christoph Berg   Wed, 04 Jan 2017 19:53:51 +0100
+
 flex (2.6.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru flex-2.6.1/src/main.c flex-2.6.1/src/main.c
--- flex-2.6.1/src/main.c	2016-03-01 01:06:56.0 +0100
+++ flex-2.6.1/src/main.c	2017-01-04 20:24:42.0 +0100
@@ -358,8 +358,8 @@
 			if (!path) {
 m4 = M4;
 			} else {
+int m4_length = strlen(m4);
 do {
-	char m4_path[PATH_MAX];
 	int length = strlen(path);
 	struct stat sbuf;
 
@@ -367,19 +367,17 @@
 	if (!endOfDir)
 		endOfDir = path+length;
 
-	if ((endOfDir-path+2) >= sizeof(m4_path)) {
-	path = endOfDir+1;
-		continue;
-	}
+	{
+		char m4_path[endOfDir-path + 1 + m4_length + 1];
 
-	strncpy(m4_path, path, sizeof(m4_path));
-	m4_path[endOfDir-path] = '/';
-	m4_path[endOfDir-path+1] = '\0';
-	strncat(m4_path, m4, sizeof(m4_path));
-	if (stat(m4_path, &sbuf) == 0 &&
-		(S_ISREG(sbuf.st_mode)) && sbuf.st_mode & S_IXUSR) {
-		m4 = strdup(m4_path);
-		break;
+		memcpy(m4_path, path, endOfDir-path);
+		m4_path[endOfDir-path] = '/';
+		memcpy(m4_path + (endOfDir-path) + 1, m4, m4_length + 1);
+		if (stat(m4_path, &sbuf) == 0 &&
+			(S_ISREG(sbuf.st_mode)) && sbuf.st_mode & S_IXUSR) {
+			m4 = strdup(m4_path);
+			break;
+		}
 	}
 	path = endOfDir+1;
 } while (path[0]);


signature.asc
Description: PGP signature

Bug#817551: libsigc++-1.2: Removal of debhelper compat 4

[Michael Biebl]

Control: clone -1 -2
Control: reassign -2 ftp.debian.org
Control: severity -2 normal
Control: retitle -2 RM: libsigc++-1.2 -- RoQA, RC buggy, unmaintained

On Wed, 09 Mar 2016 21:30:45 +0100 ni...@thykier.net wrote:
> Source: libsigc++-1.2
> Severity: important
> Usertags: compat-4-removal
> 
> Hi,
> 
> The package libsigc++-1.2 uses debhelper with a compat level of 4,
> which is deprecated and scheduled for removal.
> 
>  * Please bump the debhelper compat at your earliest convenience.
>on the 15th of June.
>- Compat 9 is recommended
>- Compat 5 is the bare minimum
>- If the package has been relying on dh_install being lenient about
>  missing files, please see "MIGRATING TO COMPAT 5 OR LATER" in [1].
> 
>  * Compat level 4 will be removed on the first debhelper upload after
>the 15th of June.

Let's remove this package completely. It's dead upstream, unmaintained
in Debian and superseded by libsigc++-2.0.
Please also remove the only remaining rdep along with it: freqtweak

It has been orphaned and is RC buggy since a while [1]. Judging from the
upstream activity, it's probably safe to conclude that freqtweak is also
dead upstream.

Regards,
Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672390
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#848859: FTBFS randomly (failing tests)

[Thibaut Paumard]

Le 04/01/2017 à 19:58, Anton Gladky a écrit :
> 2017-01-04 13:26 GMT+01:00 Santiago Vila :
>> No matter how much glitch-free is the autobuilder you use to build the
>> above package, it will fail to build 1 every 147 times on average,
>> mathematically, because the test is wrongly designed.
> 
> That is not always true. If you look in many tests from numerical
> simulation packages, there is usually a "threshold" for test result
> which should not be exceeded. And the test result varies in
> the limits, which are set by upstream authors. This result
> can be different even on the same machine, running the simulation
> several time. And it is normal.
> 
> The "fix" for such cases is the increasing of the threshold or disabling
> the test completely. Because you can do nothing with it due to the
> nature of numerical simulations.

I addition a build-time test is made to detect potential bugs, which may
themselves be of low severity. What makes the bug RC is that the test
causes FTBFS. Once such a bug has been identified, I tend to fill a bug
with appropriate severity against my own package and disable the test
until the real, low to normal severity bug is fixed.

>> Really, we need more people doing QA, and not stop doing it "because
>> we are near the freeze".
> 
> If you are maintaining the package several years, fixing most of its
> bugs, hoping to see it in release and trying to escape major changes
> several months before the freeze.. Sure, it will actively be defended
> from maintainers if some pseudo-reasons for its removal appear just
> before the freeze. This fact has to be considered as well.

I guess that's a case for a stretch-ignore tag. TBD with the release
team. Regards, Thibaut.

Regards, Thibaut.

Bug#850164: icedove: not possible to upgrade, dependency problem

[Carsten Schoenert]

Please use Reply All to reflect updates to the BTS as well.

Am 04.01.2017 um 20:36 schrieb Ďoďo:
> Was=is
> 
> ii  icedove   1:45.4.0-1  amd64

This is the current version for testing/stretch so no update within this
release is possible.
You can try to install the version from unstable/sid, but you would need
also all the dependencies from there.

-- 
Regards
Carsten Schoenert

Bug#848859: FTBFS randomly (failing tests)

[Santiago Vila]

On Wed, Jan 04, 2017 at 07:58:43PM +0100, Anton Gladky wrote:
> 2017-01-04 13:26 GMT+01:00 Santiago Vila :
> > No matter how much glitch-free is the autobuilder you use to build the
> > above package, it will fail to build 1 every 147 times on average,
> > mathematically, because the test is wrongly designed.
> 
> That is not always true. If you look in many tests from numerical
> simulation packages, there is usually a "threshold" for test result
> which should not be exceeded. And the test result varies in
> the limits, which are set by upstream authors. This result
> can be different even on the same machine, running the simulation
> several time. And it is normal.
> [...]

I know what you mean. I've seen it several times in statistical packages.

In my opinion, upstream authors may do as they wish, but Debian aims
at having reproducible builds (in some future). Reproducible builds
means each time you build the package, the same .deb is created.

This is of course not policy yet, but I see it as fundamentally
incompatible with packages which FTBFS from time to time. If we want
the end result to be always the same, then failing from time to time
(which is sometimes the end result) should never happen.

In other words, if we don't take deterministic builds seriously
(as in "every time I try to build the package, the build does not fail")
how can we expect to be reproducible in the future?

It is interesting, however, what you mention about thresholds,
statistical packages, and simulations, so here is the math
I do applied to Debian:

Let's say that we have 25000 source packages in stretch, and
I want to build all of them and not have a single failure.

Since, as you point out, there are quite a bunch of statistical
packages with tests based on random numbers, the mathematical
probability that there is some failure will always be > 0.

Ok, then. Let's suppose that I'm happy enough if the expected number
of packages that fail to build is closer to 0 than to 1.

So, let's make the probability of failure for each package to be half
of 1/25000. That would be 0.002%.

Not realistic enough? Let's assume additionally that 24950 source
packages build ok all the time, and only 50 of them have a probability
of failure > 0.

I still want to build all packages and have 0 or 1 failures,
so in this case the probability should be 1/50/2, i.e. 1%.

I think this is still feasible.

> The "fix" for such cases is the increasing of the threshold or disabling
> the test completely. Because you can do nothing with it due to the
> nature of numerical simulations.

I really wish it would always be as simple as that.

But as far as there are people in this project who consider that a
package which FTBFS on single-CPU machines more than 50% of the time
is ok "because it does not usually fail in buildd.debian.org",
we are doomed.

See the FTBFS-randomly bugs open against rygel, libsecret
or libsoup2.4, for example.

> > Really, we need more people doing QA, and not stop doing it "because
> > we are near the freeze".
> 
> If you are maintaining the package several years, fixing most of its
> bugs, hoping to see it in release and trying to escape major changes
> several months before the freeze.. Sure, it will actively be defended
> from maintainers if some pseudo-reasons for its removal appear just
> before the freeze. This fact has to be considered as well.

Well, you will see that I've downgraded all the bugs of this type to
important (btw: please do not call this "pseudo-reasons").

The problem I see with this threshold thing is that every maintainer
seems to have his own threshold, different from the others.

In case we decide about RC-ness depending on probability of failure:
What threshold do you think we should use for a single package and why?

[ I say that 1% of failure is the maximum we should allow, and I've
  explained why, but I would love to hear your opinion on this ].

Thanks a lot.

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

I've never been able to get the watch file to work right, and it is
mis-behaving like it always has. I think I've made all the other changes
requested except I'm still a total loss as to how to migrate to the short
debhelper format.

On Tue, Jan 3, 2017 at 7:28 AM, Tobias Frost  wrote:

> > Very much appreciate the feedback. Willing to learn, but overwhelmed by
> the
> > Debian machinery.
>
> You're welcome!
>
> Yes, indeed it can be overwhelming. But don't worry, we've all had to learn
> this ;-)
>
> > Stupid question at the top: If I dput another package, does it update
> this
> > one or do I need to delete the currently uploaded package from mentors
> > first?
>
> You can just dput it. It will overwrite the previous version.
>
> > - d/changelog. A lot has changed. Here are pointers to 'brief' change
> logs
> > for 2.7, 2.9, and 2.10:
> >
> > http://www.tinymux.org/changes27.txt
> > http://www.tinymux.org/changes29.txt
> > http://www.tinymux.org/changes.txt
> >
> > That's four years of why to retrace, and the actual check-in messages
> from
> > the repository would be much longer. Does Debian really want all of that?
>
> No, the debian changelog is only for changes done to the (Debian)
> packaging,
> not to the upstream source. See the Debian Policy §4.4
> You ship already an upstream changelog (though it seems only to be limited
> to
> the last version and more a NEWS file than a real changelog...)
>
> > - d/patches
> >
> >   - Not sure what a dep3 header is, yet. More to learn.
>
> http://dep.debian.net/deps/dep3/
> Hint: $ quilt header -e --dep3
>
> >   - All but one of the patches is checked-in upstream already.
>
> Ok. (Document that with the appropiate dep3-header "Applied-Upstream")
>
> >   - I don't know how to have config.guess be updated at build time? Did
> not
> > know about that one. Is this part of automake? TinyMUX is more autoconf
> > than it once was, but it still doesn't use automake or libtool.
>
> https://wiki.debian.org/Autoreconf
>
> NOTE: When you change to compat level 10 and short debhelper format it is
> even
> more easier, as compat level 10 default to use dh_autoreconf.
>
> >   - Dependency-created-noise.patch. The way users normally build
> TinyMUX is
> > untar the package, ./configure;make depend;make. The 'make depend' scans
> > all the include files and builds ".depend" which is then re-consumed by
> > Makefile. It must exist -- at least empty. The Debian build system would
> > see either way as a source change, but it isn't a change to taken
> upstream.
> > It always changes in different ways in every environment.
>
> Another reason to get rid of it to make it really portable ;-) But as said,
> patching it is wrong, especially if it can be reconstructed during the
> build.
>
> If it just needs to exists, why not
> - remove it e.g via (the file) debian/clean
> - after configure, touch it to be present
> - in build run make
>
> > - d/copyright dep5...OK, more to study. The copyright is the same as
> > previous 2.6 package except for the dates. That was hammered out between
> > the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and RhostMUSH). I'm
> > loath to change the substance of it, but if there is some Debian-friendly
> > form to call out that it is the Artistic license, that seems reasonable
> > enough.
>
> Well that happens when a package gets some care only after several years
> (btw, THANK YOU for this caring!) Policies / Procedures have been updated,
> so the "Machine-readable debian/copyright file" is now standard.
>
> > - silent rule. TinyMUX uses the other autoconf tools, but not libool or
> > automake. Silent rule seems to be a term from those things?
>
> When I compiled the package I saw that the gcc command line executed was
> not
> echoed to the console. That needs change. Several Debian tools analyzes the
> build logs to find certain problems.
>
> > - d/rules. I'm picking this up from the previous maintainer, Noltar, and
> > there should be simpler ways of doing this now. I'm just not up to speed
> on
> > them and haven't found examples I grok, yet. I want to use the simple
> > debhelper method. dh, done.
>
> man dh
> (you probably need to override dh_auto_configure and dh_auto_build and
> specify
> the source directory (the manpage above explains it); other tweaks is
> probably
> to fix the install file instead of listing them in the install target.
> Let me know when you're stuck, I'll help with hints
> (my policy is to make you learn and also to use google and e.g
> codesearch.debian.net ;-))
>
> Another point which I missed this morning*: You should provide a watch
> file.
> Hint: https://wiki.debian.org/debian/watch#GitHub
>
> * I was quite time constrained -- I apologize in advance if I find other
> points later :). But lets first tackle the above and then look for the
> missing
> pieces...
>
> --
> tobi
>
> > Stephen
> >
> > On Mon, Jan 2, 2017 at 11:41 PM, Tobias Frost  wrote:
> >
> >> control: tags -1 moreinfo
> >>
> >> Hallo Stephen,
> >>
> >> (

Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Stephen Kitt]

On Tue, 3 Jan 2017 09:06:21 -0500, Michael Gilbert 
wrote:
> On Tue, Jan 3, 2017 at 8:49 AM, Jens Reyer wrote:
> > This meets my personal preference. What do others think?  
> 
> In the long term, I think we'll end up needing to blacklist all
> extensions with this approach.
> 
> I'm ok with it as a temporary solution for stretch, but the ideal
> approach would only create the files when the user explicitly tells
> winemenubuilder to do it, rather than automatically during install,
> upgrade, etc when the user hasn't asked for it.

I've come across http://askubuntu.com/questions/323437 which suggests a
simpler solution: dropping the "-a" switch from the winemenubuilder.exe
command-line in wine.inf. I haven't tried this out (yet) so I don't know if
it affects file associations inside Wine.

Regards,

Stephen


pgpjrE9WQLqkV.pgp
Description: OpenPGP digital signature

Bug#845555: Time left not shown

[Evgeny Kapun]

On 04.01.2017 22:37, Andriy Grytsenko wrote:

Confirming, the fix is not complete. I wonder why it takes them so much time to 
implement such a simple calculation (they have the amount of energy remaining 
and the power consumption, dividing one by the other yields the remaining time).


Actually, I could fix it long ago if it was reproducible in my setup.
Could you provide more info, please, which meters are available and which
are not? Or even patch is more than welcome. Thank you.


Here is an example of what is shown in a tooltip:


Battery 0: 97% charged, 0:00 left
  Energy full design:   56160 mWh
  Energy full:  40930 mWh
  Energy now:   39900 mWh
  Power now:12804 mW
  Current voltage:  12.178 V


So, everything is correct except the "0:00 left" part. Also, if the remaining 
percentage, after rounding, is equal to 100%, remaining time is not shown at all, even if 
the battery is discharging (and the plugin is showing that it is discharging).

Here is the listing of /sys/class/power_supply/BAT0:


total 0
drwxr-xr-x 3 root root0 Jan  4 23:01 .
drwxr-xr-x 3 root root0 Jan  4 23:01 ..
-rw-r--r-- 1 root root 4096 Jan  4 23:01 alarm
-r--r--r-- 1 root root 4096 Jan  4 23:01 capacity
-r--r--r-- 1 root root 4096 Jan  4 23:01 capacity_level
-r--r--r-- 1 root root 4096 Jan  4 23:01 cycle_count
lrwxrwxrwx 1 root root0 Jan  4 23:01 device -> ../../../PNP0C0A:00
-r--r--r-- 1 root root 4096 Jan  4 23:01 energy_full
-r--r--r-- 1 root root 4096 Jan  4 23:01 energy_full_design
-r--r--r-- 1 root root 4096 Jan  4 23:01 energy_now
-r--r--r-- 1 root root 4096 Jan  4 23:01 manufacturer
-r--r--r-- 1 root root 4096 Jan  4 23:01 model_name
drwxr-xr-x 2 root root0 Jan  4 23:01 power
-r--r--r-- 1 root root 4096 Jan  4 23:01 power_now
-r--r--r-- 1 root root 4096 Jan  4 23:01 present
-r--r--r-- 1 root root 4096 Jan  4 23:01 serial_number
-r--r--r-- 1 root root 4096 Jan  4 23:01 status
lrwxrwxrwx 1 root root0 Jan  4 23:01 subsystem -> 
../../../../../../../../../class/power_supply
-r--r--r-- 1 root root 4096 Jan  4 23:01 technology
-r--r--r-- 1 root root 4096 Jan  4 23:01 type
-rw-r--r-- 1 root root 4096 Jan  4 23:01 uevent
-r--r--r-- 1 root root 4096 Jan  4 23:01 voltage_min_design
-r--r--r-- 1 root root 4096 Jan  4 23:01 voltage_now


From strace, I see that the plugin tries to access some files that are missing 
here.

Here is the contents of /sys/class/power_supply/BAT0/uevent:


POWER_SUPPLY_NAME=BAT0
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_TECHNOLOGY=Li-ion
POWER_SUPPLY_CYCLE_COUNT=0
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=1080
POWER_SUPPLY_VOLTAGE_NOW=12097000
POWER_SUPPLY_POWER_NOW=12677000
POWER_SUPPLY_ENERGY_FULL_DESIGN=5616
POWER_SUPPLY_ENERGY_FULL=4093
POWER_SUPPLY_ENERGY_NOW=3851
POWER_SUPPLY_CAPACITY=94
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_MODEL_NAME=42T4678
POWER_SUPPLY_MANUFACTURER=Panasonic
POWER_SUPPLY_SERIAL_NUMBER= 2210


Hope this helps.

Bug#828457: nodejs: FTBFS with openssl 1.1.0

[Jérémy Lal]

Package: nodejs
Version: 4.6.1~dfsg-1
Followup-For: Bug #828457
Control: reopen -1

This bug has been fixed in nodejs 6.9.2~dfsg-1,
which is in experimental, node in testing.

Reopening, then.

Jérémy

Bug#845818: flash-kernel: Add support for Hardkernel Odroid-C2

[Geert Stappers]

On Wed, Jan 04, 2017 at 12:33:30PM +0100, Heinrich Schuchardt wrote:
> The prerequisite patch fixing #845779 has been applied to the
> flash-kernel git.
> 

URL to that bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845779

Bug#845779: flash-kernel: flashkernel uses mkimage -A arm on arm64

[Geert Stappers]

On Mon, Jan 02, 2017 at 03:17:32PM -0800, Martin Michlmayr wrote:
> Thanks, I applied this patch.

Cross-reference to related bugreport
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=845818

Bug#850186: debsources: Patch view fails when there are too many patches

[Ben Hutchings]

Package: qa.debian.org
Severity: normal
User: qa.debian@packages.debian.org
Usertags: debsources

This URL results in an Internal Server Error:
https://sources.debian.net/patches/linux/3.2.78-1/

When I reported this outside the BTS, I got these replies:

On Wed, 2017-10-04 at 08:11 +0100, Orestis Ioannou wrote:
> I am not sure there are many packages with this kind of problem but
> maybe a solution would be to do a pagination on this view and parse only
> 100 patches at a time or so.

On Wed, 2017-01-04 at 14:29 +0100, Stefano Zacchiroli wrote:
> This sounds like a sensible workaround, at least as long as we're doing
> the patch parsing on the fly.
> 
> And it might end up being useful also later, when we will be doing the
> patch parsing at update time, because we probably don't want to show 1
> gazillion patches on a single page anyhow, even if they're coming from
> the DB.

Ben.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#848137: problem with the upgrade of tango-db

[Paul Gevers]

Hi Frederic-Emmanuel, Andreas,

@Andreas, am I correct in the assumption that jessie to stretch with
tango-db was fine until MariaDB became the default? Or was this
migration with tango-db just never tested before? Have you seen other
dbconfig-common dependent packages fail since MariaDB became default (or
maybe since dbconfig-common 2.0.5 (26-08-2016)?

In the former case, I believe that the issue at hand is that MariaDB is
stricter in permissions that MySQL and either MariaDB needs to mimic
MySQL more in this respect or dbconfig-common needs to cope with that
(not nice because dbc will need to get admin privileges just to dump the
database, even when it otherwise wouldn't need it. I propose we start
asking the MariaDB maintainers what they know/think.

On 04-01-17 19:00, PICCA Frederic-Emmanuel wrote:
>> I am suspecting that this commit may be related to the current behavior:
>> https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=acdb99d61abfff54630c4cfba6e4452357a83fb9
> 
>> I believe I implemented there that the drop of the database is performed
>> with the user privileges instead of the dbadmin privileges because I
>> believed one should always have the rights to drop the db. Apparently I
>> was wrong. We may need to clone or reassign this bug to dbconfig, but
>> I'm not sure yet if there aren't more things, or if tango-db should work
>> around the issue (which may be created by buggy dbconfig-common behavior
>> of the past).
> 
> I can not give an educated guess if the current logic of dbconfig-common is 
> good or not.
> I do not have enough knowledge of SQL/MySQL/Postsgresq etc...
> 
> This problem could affect other package using dbconfig-common.

Agree. Although I still don't understand why in jessie it was root that
owned the procedure. What I suspect is that the procedures are owned by
root because the database was created by root. Since the commit
referenced above, the database for MySQL is created with user
credentials, so maybe in new databases, procedures are owned by the
user. Once I have enough time, I'll try to figure out.

> I agreed also that I must fix the wrongly created procedure/tables
> due to the previous dbconfig-common behaviour.

Hmm, not so quick ;). I believe dbconfig-common should be robust against
the issue at hand. But indeed, once the dumping goes well, I expect the
upgrade to fail slightly later because I *expect* the tango user doesn't
have the privileges to delete the procedures owned by root (this is the
next step in the upgrade code of tango-db).. *If* this is a MariaDB
specific issue and the MariaDB maintainers are willing to mimic MySQL
behavior (assuming this is the issue) than both tango-db and
dbconfig-common don't need to do anything. However, if they don't want
this behavior (which I expect), or if it isn't MariaDB specific, then
depending on the real root cause of why root owns the procedures, both
dbconfig-common and tango-db need to fix something. dbconfig-common
needs to be robust against root owned procedures (and maybe other
things) in the dumping code, and tango-db needs to fix the ownership of
the procedures. For the latter, I can only advice once we have
established what determines who owns the procedures.

> Can you help me in this proces in order to produce the right snopset
> to put in my package (preinst ?) script.

I'll try to help, once we know the root of the ownership.

> I need to change the owner of the procedure from
> 
> root @ localhost -> tango @ locahost

Not sure.

> Which kind of script should I add in my debian scripts ?

Not sure yet. It depends on the answer to all my questions.

Paul

Side note: tango-db is buggy, in the sense that the MySQL code to create
the procedures and tables is assuming the database name is tango.
However, the system administrator has the freedom (with dbconfig-common)
to choose a different database name (and database user) if (s)he wishes.



signature.asc
Description: OpenPGP digital signature

Bug#672936: lsh-server: does not respect umask

[Niels Möller]

Sam Geeraerts  writes:

> The default umask on a Squeeze system is 0022. However, when I
> connect via ssh to lsh-server on my Squeeze system the umask
> in the session is . It would make more sense to also have
> 0022 there.

Hi,

I had totally forgotten about this problem, but I was recently bitten by
it myself. And it turned out that it really has nothing to do with PAM,
it was a bug in lshd's daemon setup code, which cleared the umask for no
good reason. Which didn't matter much as long as we had /etc/profile and
other environment setup scripts set umask explicitly.

I just committed a fix and a test case to the stable branch
("lsh-2.0.4").

See
https://git.lysator.liu.se/lsh/lsh/commit/99b8bf8cf29a8a5e6cb63edd5c46bfa337b5a1d2,
and the next commit with the test case,
https://git.lysator.liu.se/lsh/lsh/commit/7f667afab075cf7cb3983bffa627e0c9345b9e72

With this change, shells spawned by lshd will inherit the umask the lshd
process was started with.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.

Bug#850187: RFS: cid/8.0-1 [ITP]

[Eduardo Moraes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "cid"

* Package name: cid
  Version : 8.0-1
  Upstream Author : Eduardo Moraes 
* URL : https://c-i-d.sourceforge.net
* License : GPL-3
  Section : misc
  Programming Lang: Bash
  Description : Set of bash scripts to automate and optimize the
configuration of a Linux station in an AD domain

- The CID (Closed In Directory) project is a set of bash scripts
 to automate and optimize the configuration of a Linux station
 in an Active Directory domain through the samba(7) suite.
- I am the developer of the program and would like to take it to
 the Debian repositories, any help is appreciated.

It builds those binary packages:

cid - Simple tool to insert and manage Linux stations in a AD domain
cid-base - Base files for cid and cid-gtk packages
cid-gtk - Graphical tool to insert and manage Linux stations in a AD domain

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/cid


Alternatively, one can download the package with dget using this command:

dget -x https://mentors.debian.net/debian/pool/main/c/cid/cid_8.0-1.dsc

More information about CID can be obtained from https://c-i-d.sourceforge.net.

Regards,
Eduardo Santos de Moraes

Bug#850188: autoconf: Allow checking function with conflicting types

[Javier Serrano Polo]

Package: autoconf
Version: 2.69-10
Severity: wishlist
Tags: upstream

Running configure with CFLAGS=-Werror, generated using AC_CHECK_LIB or
AC_SEARCH_LIBS, reveals this error in config.log (e.g., checking sqrt):

error: conflicting types for built-in function 'sqrt'

Ït would be nice if this syntax worked:

AC_CHECK_LIB([m], [double sqrt(double)])

or perhaps invoke gcc with -fno-builtin .


smime.p7s
Description: S/MIME cryptographic signature

Bug#850189: process table format ugly when kernel.pid_max > 99999

[Sven Hartge]

Package: atop
Version: 2.2.6-2
Severity: minor

Hi!

I run atop on a system where kernel.pid_max = 4194303.
Since all PIDs can be longer than 5 characters this leads to
an ugly jagged look in the process table once this happens:

   PIDTID  THR  SYSCPU USRCPU  VGROW   RGROW  RDDSK  WRDSK  ST EXC S  CPUNR 
 CPU CMD 1/6
1818110  -1   0.12s  0.06s 0K  0K 0K 0K  --   - S  
2   2% apps.plugin
1023550  -   10   0.02s  0.05s 0K  0K 0K 0K  --   - S  
3   1% netdata
3885756  -   31   0.03s  0.01s 0K  0K 0K 0K  --   - S  
0   0% mysqld
1023566  -5   0.00s  0.04s 0K  0K 0K 0K  --   - S  
3   0% python
1934013  -1   0.03s  0.01s 0K  0K 0K 0K  --   - R  
2   0% atop  
3950051  -1   0.03s  0.01s 0K  0K 0K 0K  --   - S  
0   0% gkrellmd
1917616  -1   0.00s  0.02s 0K  0K 0K 0K  --   - S  
0   0% bash
966886  -1   0.00s  0.01s 0K  0K 0K 0K  --   - S  2 
  0% tor
303558  -   11   0.00s  0.01s 0K  0K 0K 0K  --   - S  1 
  0% syncthing
38  -1   0.01s  0.00s 0K  0K 0K 0K  --   - S  3 
  0% ksmd
1281656  -7   0.00s  0.00s 0K  0K 0K 0K  --   - S  
2   0% named
1167743  -1   0.00s  0.00s 0K  0K 0K 0K  --   - S  
2   0% php-fpm7.0
587618  -7   0.00s  0.00s 0K  0K 0K 0K  --   - S  1 
  0% fail2ban-serve

This of course is only a minor cosmetic bug.
(To be fair, this is quite common upon tools displaying
PIDs, glances for example has the same problem.)

Grüße,
Sven.

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (200, 'experimental'), (1, 'experimental-debug')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages atop depends on:
ii  init-system-helpers  1.46
ii  initscripts  2.88dsf-59.8
ii  libc62.24-8
ii  libncurses5  6.0+20161126-1
ii  libtinfo56.0+20161126-1
ii  lsb-base 9.20161125
ii  zlib1g   1:1.2.8.dfsg-4

Versions of packages atop recommends:
ii  cron [cron-daemon]  3.0pl1-128

atop suggests no packages.

-- debconf-show failed

Bug#850170: [Pkg-emacsen-addons] Bug#850170: elpa-with-editor: Alioth VCS repository is out of date

[Rémi Vanicat]

Free Ekanayaka  writes:

> Package: elpa-with-editor
> Severity: normal
>
> Hello,
>
> it seems that the git repository for the debian package is out of date:
>
> https://anonscm.debian.org/cgit/pkg-emacsen/pkg/with-editor.git/
>
> as it only has version 2.5.7-1 while the one in the archive is 2.5.8-1.
>
> Cheers

tags and branch has been pushed


-- 
Rémi Vanicat

Bug#847105: wok source updated

[Lucio Correia]

Hi Breno,

I've just uploaded a new package to fix that DTD warning. The linking I 
made did not work on latest patch I had submitted.


dget -x https://mentors.debian.net/debian/pool/main/w/wok/wok_2.3.1-1.dsc

Regards,
--
Lucio Correia

Bug#848893: nvidia-settings: When launching "nvidia-settings" -- "undefined symbol error"

[Philippe Waroquiers]

On Thu, 29 Dec 2016 13:18:12 +0100 Andreas Beckmann  wrote:
> Rebuilding nvidia-settings from sid with no further changes in a jessie
> environment results in these lost symbols. I don't have much time to
> investigate this further right now over the holidays.

I downloaded the version 375.26 from the nvidia site, and just extracted
the files from the archive, without installing.

The gtk3 library in this version has a lot more symbols than the debian
installed 367.57 version:

objdump -tT ./NVIDIA-Linux-x86_64-375.26/libnvidia-gtk3.so.375.26 |grep ctk|wc 
-l
259

objdump -tT /usr/lib/libnvidia-gtk3.so.367.57 |grep ctk|wc -l
21


A.o., the library downloaded from nvidia has the symbol ctk_init_check
objdump -tT ./NVIDIA-Linux-x86_64-375.26/libnvidia-gtk3.so.375.26 |grep 
ctk_init_check
0002fb20 gDF .text  000a  Basectk_init_check


Running the below works ok :
LD_LIBRARY_PATH=./NVIDIA-Linux-x86_64-375.26 
./NVIDIA-Linux-x86_64-375.26/nvidia-settings

Philippe

Bug#848137: problem with the upgrade of tango-db

[Paul Gevers]

Control: clone -1 -2
Control: reassign -2 dbconfig-common
Control: retitle -2 dbc: db-dump must use root credentials when needed

Hi all,

I think I found the issue. Since commit 95571e6¹ the postinst script of
dbconfig properly executes install code with user privileges as it has
always said it would. Therefore, before dbconfig-common 1.8.50, the
install code would be run with the administrator credentials. Indeed,
this results in the behavior as now observed.

Therefore, what I think what needs to be done is the following:
1) dbconfig-common needs to be fixed to cope with procedures not owned
by the user during database dumping
2) tango-db needs to change ownership of the procedures using dbadmin
privileges. As the order of execution of user sql vs dbadmin sql vs
scripts is undetermined, this probably means that for one version
tango-db needs to ship a script to do the actual actions it would
normally put in /usr/share/dbconfig-common/data/tango-db/upgrade/ (after
it first drops the procedures).

Of to bed now.

Paul

¹
https://anonscm.debian.org/cgit/collab-maint/dbconfig-common.git/commit/?id=95571e657e1d57e6b81a6a352b9cf49bcb5469d1



signature.asc
Description: OpenPGP digital signature

Bug#850164: icedove: not possible to upgrade, dependency problem

[Ďoďo]

Was=is

ii  icedove   1:45.4.0-1  amd64

Jozef

On Wed, Jan 4, 2017 at 5:18 PM, Carsten Schoenert
 wrote:
> On Wed, Jan 04, 2017 at 03:50:41PM +0100, Ďoďo wrote:
>>  apt-get install icedove since apt-get upgrade did not owrk.
>
> And this would be the interesting part.
> Which version was installed?
>
>>* What was the outcome of this action?
>>  Building dependency tree
>>  Reading state information... Done
>>  Some packages could not be installed. This may mean that you have
>>  requested an impossible situation or if you are using the
>>  unstable
>>  distribution that some required packages have not yet been
>>  created
>>  or been moved out of Incoming.
>>  The following information may help to resolve the situation:
>>
>>  The following packages have unmet dependencies:
>>   icedove : Depends: libhunspell-1.3-0 (>= 1.3.3) but it is not
>>   installable
>>   E: Unable to correct problems, you have held broken packages.
>
> hunspell has made a transition to version 1.4 recently so it's obviously
> a unresolvable dependency on version libhunspell-1.3-0.
>
> But we are currently on the transmission to the de-branded Thunderbird
> packages back. The upload of 45.6.0-1 was made to experimental and was
> going to NEW.
>
> It will take some time we can provide a fix.
>
> Regards
> Carsten

Bug#692754: how to get the username in the plugin?

[martin f krafft]

also sprach Johannes Berg  [2017-01-05 01:11 +1100]:
> I'm not even sure how to get the username? Is it even generally
> possible, if e.g. the plugin is running out of a process that's not
> invoked through the imapd?

Well, the plugin certainly does seem to be run as the target user,
or else how could it be used for user-specific training?

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#850191: Can not cross compile to arm from x86

[Jussi Pakkanen]

Package: gcc-6-arm-linux-gnueabihf
Version: 6.2.1-5cross1

Trying to cross compile a simple helloworld application on 32 bit x86
with this command:

arm-linux-gnueabihf-gcc-6 hello.c -o hello

fails with the following error message:

/usr/lib/gcc-cross/arm-linux-gnueabihf/6/libgcc.a: file not
recognized: File format not recognized
collect2: error: ld returned 1 exit status

Thanks,

Bug#849971: node-sprintf-js: FTBFS randomly (AssertionError)

[Santiago Vila]

severity 849971 important
thanks

Hello.

I'm setting the severity of this bug to "important" not because
I don't think it is not RC (as Release Policy still says that
packages must autobuild *without* failure), but because the
Release Managers are considering to decide about RC-ness
of this kind of bugs based on the probability of failure.

We don't know what kind of threshold there will be for stretch, so I
strongly recommend that you act as if this bug was serious and RC,
especially if the failures happen very often on any kind of
autobuilder which is not misconfigured.

Thanks.

Bug#850168: lintian should have checks for manual pages to see if they have an EXAMPlES section

[anarcat]

Control: severity -1 wishlist

I agree!

I often find myself frustrated by more obscure bits of software where I
would love to see some EXAMPLES sections to help me get started.

Maybe this could be a "Informative" or "Pedantic" level instead of
"Warning"? It certainly shouldn't be at the "Error" level, or at least
not worse than the current "manpage missing" message.

Thanks!

-- 
If it's important for you, you'll find a way.
If it's not, you'll find an excuse.
- Unknown


signature.asc
Description: Digital signature

Bug#849041: dgit: psuedomerge commits have no author.

[Ian Jackson]

Control: severity -1 critical

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):
> Unfortunately I ran into a problem. It seems that the psuedomerge 
> commits generated by dgit have no author: field and this makes it 
> impossible to push them to github.

I have discovered that there are problems only with the import-dsc
pseudomerges, but also of the ones made by --overwrite.

Because nothing on the server notices (and afaict there is no way with
the git version currently on the Debian server to stop this), these
commits have become part of public history.

This is terrible and must be stopped at once.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850192: kcov: new upstream release v32 available

[Michael Prokop]

Package: kcov
Version: 25+dfsg-1
Severity: wishlist

Hi,

upstream released v32 on 22nd of November 2016 (see
https://github.com/SimonKagstrom/kcov/releases), would be nice to
have a more recent version available in Debian.
(Except for i386 with its v25+dfsg-1 in unstable we're stuck at
v11-1 for stable, testing and unstable :-/)

regards,
-mika-

Bug#814218: lua-ldap: Add support for Lua 5.2

[Luca Capello]

tags 814218  + moreinfo
thanks

Hi there,

sorry for the delay, mostly due to real life and the fact that the
servers (with Prosody + lua-ldap) I administer are still on wheezy.

On Tue, 09 Feb 2016 14:33:53 +0530, Avinash Sultanpur wrote:
> The pdns-recursor is compiled with liblua5.2-0 and this package does
> not have support for Lua 5.2 which makes it unusable with Power DNS.
> 
> There are a couple of open pull requests on Github which add support
> for Lua 5.2. Please merge them in order to support Lua 5.2.
> 
> https://github.com/luaforge/lualdap/pulls

I am sorry, but after having tried for 2 weeks now I have given up
trying to understand where the lualdap sources reside, here some
comments:

- 

  AFAIK still the "official" repository, but development has never
  started on it, except for the 2 pulls requests.

  Yet, there are 13 forks on GitHub only!

- 
  
   


  If I read history correctly, some of the more prominent forks, now all
  stalled.

- 
   

  I do not understand why 2 different repositories from the same author
  and no indications that they are the same :-(

- 

  This should be the official follow-up, but as far as I could see
  nothing from the other forks (nor even the "official" one by
  bdellegrazie) has been integrated:


 

  Indeed, on LuaRocks the bdellegrazie's fork is listed:


  
- 
   

  A very recent fork, wait, not even a Git fork but history rewritten...
  
I am aware of the poor maintenance in Debian, entirely due to my fault,
at least in term of all-the-upstream-sources following.

IMHO the best thing should be to ask for removal, especially given the
various upstream sources and to not give a false idea of what is being
installed.

Thx, bye,
Gismo / Luca


signature.asc
Description: Digital signature

Bug#849602: not a bug

[Mike Hommey]

On Wed, Jan 04, 2017 at 10:24:06PM +0530, shirish शिरीष wrote:
> at bottom :-
> 
> On 04/01/2017, Patrick Mutwiri  wrote:
> > thats how fonts are installed.
> >
> >
> > this is not a bug.
> >
> >
> >
> >
> > *Kind Regards,*
> >
> >
> > Patrick Mutwiri / _dev
> >
> > +254 727 542 899
> >
> > Nairobi, Kenya
> >
> > http://patric.xyz
> >
> > [image: Twitter]  [image: Facebook]
> >  [image: Google +]
> >  [image: LinkedIn]
> >  [image: Instagram]
> >  [image: Github]
> >  [image: Stack Overflow]
> > 
> >
> 
> It is a bug exactly because of the way Jonas has described. If there
> has to be a font which needs to be installed, it should be installed
> system-wide where other packages could also use the font if they
> wanted/needed.
> 
> Having it installed it system-wide with a symlink to a custom location
> is how it has been done for a long time and do not need see a need to
> have it special-cased just because it's mozilla.
> 
> The font should be installed and be available .
> 
> I just tried -
> 
> └─[$] fc-list | grep emoji
>  [$]
> 
> and as can be seen it didn't give any output.
> 
> This has also been shared in debian-policy
> https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.8.5
> 
> Hope the above gives a bit more insight why we think it's an issue.

I'll gladly symlink to a system font if it exists, but I'm not going to
have firefox provide an EmojiOne font package, because it's a separate
project and there's no reason one of the things that uses it provides it.

I'm also not interested in maintaining one more package.

So please feel free to file a RFP.

Mike

Bug#814218: lua-ldap: Add support for Lua 5.2

[Jason A. Donenfeld]

If anybody would like to take over my lualdap fork, I'd be happy to
transfer commit access.

https://git.zx2c4.com/lualdap

Bug#850171: forgot to add it should be in section 12.1 https://www.debian.org/doc/debian-policy/ch-docs.html#s12.1

[shirish शिरीष]

Hi all,

Though I thought I had added it, the change will need to be in section 12.1

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#850193: RFS: forge/0.9.2-2

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "forge"

* Package name: forge
  Version : 0.9.2-2
  Upstream Author : ArrayFire
* URL : https://github.com/arrayfire/forge
* License : BSD
  Section : libs

It builds those binary packages:

  forge-doc  - documentation for forge
  libforge-dev - development files for forge
  libforge0  - high-performance OpenGL visualization

To access further information about this package, please visit the 
following URL:

  https://mentors.debian.net/package/forge

Alternatively, one can download the package with dget using this
command:

  dget -x https://mentors.debian.net/debian/pool/main/f/forge/forge_0.9.2-2.dsc

Successful build on debomatic:

  http://debomatic-amd64.debian.net/distribution#unstable/forge/0.9.2-2/buildlog

Changes since the last upload:

  * Cherry-pick upstream patch facilitating builds with system
libraries.
New patch 0003-Consistent-definition-of-USE_SYSTEM-flags-
for-glbind.patch
  * Force use of system dependencies via the USE_SYSTEM
flags.
Reason: fixes FTBFS during reproducible builds
  * Add missing
build dependency on OpenGL.
Reason: fixes FTBFS on sparc64
  * Add
support for the nodoc build profile.
  * Add patch fixing spelling
errors reported by Lintian.
New patch 0004-Fix-spelling-errors.patch

Regards,
Ghislain Vaillant

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Ondrej Novy]

Hi,

2017-01-04 16:31 GMT+01:00 Thomas Goirand :

> Please file a bug against ftp.debian.org to get the package removed.
>

Maybe orphan it first?

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Bug#850104: ncl FTBFS on the hppa/parisc architecture

[Helge Deller]

Confirmed, the attached patch fixes build of ncl package on the hppa/parisc 
architecture.
Can you please apply the attached patch to the next upload of ncl?

Thanks,
Helge
diff -up ./config/ymake.org ./config/ymake
--- ./config/ymake.org	2017-01-04 16:46:23.259282723 +0100
+++ ./config/ymake	2017-01-04 16:46:40.611281478 +0100
@@ -385,6 +385,7 @@ caseLinux:
 casemip*:
 casesparc*:
 casearm*:
+caseparisc*:
 caseppc*:
 caseaarch64*:
 casealpha:

Bug#849041: dgit: psuedomerge commits have no author.

[peter green]

On 04/01/17 22:03, Ian Jackson wrote:

Control: severity -1 critical

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):

Unfortunately I ran into a problem. It seems that the psuedomerge
commits generated by dgit have no author: field and this makes it
impossible to push them to github.

I have discovered that there are problems only with the import-dsc
pseudomerges, but also of the ones made by --overwrite.

Because nothing on the server notices (and afaict there is no way with
the git version currently on the Debian server to stop this), these
commits have become part of public history.

I have a script that can be used to fix the commits but of course the only way 
to fix them is to change history and that has obvious downsides.

http://stackoverflow.com/a/41275543/5083516

Bug#850060: 2.0.874-2~exp1 issues

[Andrew Patterson]

I have been testing 2.0.874-2~exp1 and found the following issues:

1. In debian/extra/initramfs.local-top and
debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
in /run/iscsiuio.pid. You cannot override it on the command-line. The
--pidfile option for start-stop-daemon should point to this location
instead of /run/initramfs/iscsiuio.pid.

2. The /sbin/iscsiuio deamon is trying to create a logfile in
/var/log/iscsiuio.log. The /var/log directory does not exist in the
initramfs. I do not know if this is causing a problem (perhaps related
to #1).

3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
investigating why. It works fine when run after boot.

4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
will cause the interface to be configured in both iscsistart -N and in
iscsistart -b for cards with iscsi hardware offload. I suspect we
instead need a flag in iscsistart to bring up the NIC in iscsistart
regardless if the NIC uses an offloadable driver. The local-top script
can use this flag if /sbin/iscsiuio is not present, e.g.,

ISCSISTART_FLAGS=""
if [ ! -x /sbin/iscsiuio ] ; then
   ISCSISTART_FLAGS="-S"
fi
.
.
.
modprobe iscsi_ibft
iscsistart -N $ISCSISTART_FLAGS

The iscsistart code would have to be modified to add support for this
flag. Alternatively, iscsistart could check for the presence of
/sbin/iscsiuio and "do the right thing".

-- 
Andrew Patterson
Hewlett-Packard Enterprise

Bug#850194: evolution cant's start (dist jessie armhf)

[Winfried Kybelka]

Package: evolution
Version: 3.12.9~git20141130.241663-1+b1
Severity: normal
Tags: d-i

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.39+ (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages evolution depends on:
ii  dbus   1.8.20-0+deb8u1
ii  debconf [debconf-2.0]  1.5.56
ii  evolution-common   3.12.9~git20141130.241663-1
ii  evolution-data-server  3.12.9~git20141128.5242b0-2+deb8u2
ii  gnome-icon-theme   3.12.0-1
ii  libatk1.0-02.14.0-1
ii  libc6  2.19-18+deb8u6
ii  libcamel-1.2-493.12.9~git20141128.5242b0-2+deb8u2
ii  libclutter-gtk-1.0-0   1.6.0-1
ii  libecal-1.2-16 3.12.9~git20141128.5242b0-2+deb8u2
ii  libedataserver-1.2-18  3.12.9~git20141128.5242b0-2+deb8u2
ii  libevolution   3.12.9~git20141130.241663-1+b1
ii  libglib2.0-0   2.42.1-1+b1
ii  libgtk-3-0 3.14.5-1+deb8u1
ii  libical1a  1.0-1.3
ii  libnotify4 0.7.6-2
ii  libsoup2.4-1   2.48.0-1
ii  libwebkitgtk-3.0-0 2.4.9-1~deb8u1
ii  libxml22.9.1+dfsg1-5+deb8u4
ii  psmisc 22.21-2

Versions of packages evolution recommends:
ii  bogofilter 1.2.4+dfsg1-3+deb8u1
ii  evolution-plugins  3.12.9~git20141130.241663-1+b1
ii  spamassassin   3.4.0-6
ii  yelp   3.14.1-1

Versions of packages evolution suggests:
ii  evolution-ews   3.12.9~git20141130.278fe7-1+b1
ii  evolution-plugins-experimental  3.12.9~git20141130.241663-1+b1
ii  gnupg   1.4.18-7+deb8u3
pn  network-manager 

-- debconf information:
  evolution/kill_processes:
  evolution/needs_shutdown:
winfried@jessie-A80:~$ evolution
libEGL warning: DRI2: failed to authenticate
Unable to eglMakeCurrent with no surface

Bug#849119: playonlinux: Buttons fail to appear in most or all pop up dialog boxes

[Bertrand Marc]

Dear Ray,

Thank you for taking the time to investigate. I forwarded the issue upstream, 
and hopefully they will come up with a solution soon enough.

In the meantime, I will downgrade the severity of this bug, as playonlinux is 
still usable by most people.

Best regards,
Bertrand

PS Could you please put the bug email address in copy?


Le 30/12/2016 à 19:45, Raymond F. Anthracite a écrit :
> Dear Bertrand,
> 
> Upon further investigation, I think I have a better idea where the problem 
> lies.
> 
> It appears to be an issue with the size of the window decoration at the top 
> in 
> pixels not being compensated for by the program.  It happens in all window 
> managers.  My computer is running through a 4k 55" television, and I run at 
> font sizes around 22 or so.  Bigger fonts make the window decoration title 
> bar 
> bigger, which displace the buttons at the bottom, and the window isn't 
> expandable so it doesn't make room for it.
> 
> I suspect you could reproduce the problem on a system with normal specs (not 
> a 
> 4k 55 inch TV) by using a really big titlebar font size, and restarting your 
> window manager (the window managers sometimes seem to pick a titlebar size on 
> startup and then not change much it even if you change the font size), and 
> then you will notice the buttons on the bottom start to get cut off.
> 
> The problem happens in a brand new gnome session for me with a new user, with 
> a new home directory, with the default font sizes, but instead of being 
> entirely cut off the buttons are only partially cut off, so the program is 
> still usable to a degree.  I believe that this is because the gnome titlebars 
> are smaller by default, not for any other reason.
> 
> It also seems to work somewhat in kde if i start up with normal font sizes 
> and 
> then make them bigger, as that makes the title bar less big than it does if I 
> start up with them big for some reason.  The buttons are still mostly cut off 
> but I can click them, barely.
> 
> I included a pic where they aren't entirely cut off, but just mostly cut off 
> so that you can see what is happening.   It's from a time when I started up 
> kde with small fonts, then increased the font size of the titlebar to make 
> the 
> problem more noticable.  Normally all my fonts are about as big as the one in 
> the titlebar.  It seems to depend only on the size of the titlebar.  I don't 
> think the font size matters except in so far as that causes the title bar 
> size 
> to change, which it often does.
> 
> Best wishes,
> 
> Ray
> 
> $ xrandr -q
> Screen 0: minimum 8 x 8, current 3840 x 2160, maximum 32767 x 32767
> DVI-D-0 disconnected (normal left inverted right x axis y axis)
> HDMI-0 disconnected (normal left inverted right x axis y axis)
> HDMI-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y 
> axis) 1210mm x 680mm
>3840x2160 30.00 +  59.94*   50.0029.9725.0023.98  
>4096x2160 59.9450.0029.9725.0024.0023.98  
>1920x1080 60.0059.9450.0029.9725.0023.9760.00  
>   
> 50.04  
>1680x1050 59.95  
>1600x900  60.00  
>1440x900  59.89  
>1366x768  59.79  
>1280x1024 75.0260.02  
>1280x800  59.81  
>1280x720  60.0059.9450.00  
>1152x864  75.00  
>1024x768  75.0370.0760.00  
>800x600   75.0072.1960.32  
>720x576   50.00  
>720x480   59.94  
>640x480   75.0072.8159.94  
> DP-0 disconnected (normal left inverted right x axis y axis)
> DP-1 disconnected (normal left inverted right x axis y axis)
> DP-2 disconnected (normal left inverted right x axis y axis)
> DP-3 disconnected (normal left inverted right x axis y axis)
> 
> 
> 




signature.asc
Description: OpenPGP digital signature

Bug#850126: ITP: node-aproba -- A rediculously light-weight argument validator

[Philip Hands]

Tushar Agey  writes:

> Package: wnpp
> Severity: wishlist
> Owner: Tushar Agey 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-aproba
>   Version : 1.0.4
>   Upstream Author : Rebecca Turner 
> * URL : https://github.com/iarna/aproba
> * License : ISC
>   Programming Lang: JavaScript
>   Description : A rediculously light-weight argument validator
>

That should be spelt 'ridiculously'

Also, where is the long description?  There should at the very least be
some indication that these node-* packages are related to node.js, and
what that might be (for people that don't already know).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#849020: jessie-pu: package systemd/215-17+deb8u6

[Cyril Brulebois]

Adam D. Barratt  (2017-01-04):
> Control: tags -1 + moreinfo
> 
> On Wed, 2016-12-21 at 22:07 +0100, Michael Biebl wrote:
> > I'd like to make a stable upload for systemd with the following changes.
> > All the changes are cherry-picks/backports from fixes which have already
> > been applied to systemd in unstable.
> > 
> > The full debdiff is attached. For better readability I will provide an
> > annotated debian/changelog which links to the invidual commits
> 
> I think this looks okay (although ordering changes always make me a
> little paranoid), and while it doesn't look like any of the changes
> should affect the udebs or d-i, I'd still appreciate a kibi-ack.

Looks good to me indeed.


KiBi.


signature.asc
Description: Digital signature

Bug#850141: ITP: node-jsbn -- The jsbn library is a fast, portable implementation of large-number math in pure JavaScript, enabling public-key crypto and other applications on desktop and mobile brows

[Philip Hands]

abhi.kuvale...@yahoo.com writes:

> Package: jsbn
> Severity: wishlist
> Owner: Abhishek Kuvalekar 
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name    : node-jsbn
>   Version : 0.1.0

The github version claims to currently be 1.0.0 -- is this just a typo,
or are you packaging an old version on purpose for some reason?

>   Upstream Author : Tom Wu
> * URL : https://github.com/andyperlitch/jsbn
> * License : BSD
>   Programming Lang: JavaScript
>   Description : The jsbn library is a fast, portable implementation of 
> large-number math in pure JavaScript, enabling public-key crypto an$

The short description is too long, and is truncated.

The long decription is missing.

There should at least be an indication that this relates to node.js, and
what that might mean (for people that are not already aware of node.js)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#849845: got hit as well

[shirish शिरीष]

Hi all,
Got hit on one of my machines which upgraded before the serious bug
was invoked -

└─[$] apt-cache policy gnupg dirmngr

gnupg:
  Installed: 2.1.17-2
  Candidate: 2.1.17-2
  Version table:
 *** 2.1.17-2 600
600 http://httpredir.debian.org/debian stretch/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
dirmngr:
  Installed: 2.1.17-2
  Candidate: 2.1.17-2
  Version table:
 *** 2.1.17-2 600
600 http://httpredir.debian.org/debian stretch/main amd64 Packages
  1 http://httpredir.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


─[$] gpg --keyserver pgp.mit.edu --recv-keys DAD95197

gpg: keyserver receive failed: No keyserver available

Tried multiple times and failed :(

Look forward to getting it fixed.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#849041: dgit: psuedomerge commits have no author.

[Ian Jackson]

peter green writes ("Bug#849041: dgit: psuedomerge commits have no author."):
> I have a script that can be used to fix the commits but of course the only 
> way to fix them is to change history and that has obvious downsides.

Thanks.  I'm going to write a better script.  I think the
history-rewriting is inevitable :-(.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#850195: ITP: extinction -- Fast interstellar dust extinction laws

[Florian Rothmaier]

Package: wnpp
Severity: wishlist

* Package name: Extinction
  Version : 0.3.0
  Upstream Author : Kyle Barbary 
* URL : https://github.com/kbarbary/extinction
* License : MIT
  Programming Lang: Python/Cython
  Description : Fast interstellar dust extinction laws

Extinction provides a library with Cython-optimised implementations of
empirical dust extinction laws found in the astronomical literature.

This library is a dependency of the sncosmo software. Hence packaging
Extinction is a prerequisite of packaging sncosmo.

It will be maintained within the Debian Astronomy Working Group. A git
repository will be created on alioth [1].

Best regards,

Florian

[1] https://anonscm.debian.org/cgit/debian-astro/packages/extinction.git

Bug#738897: RM libsigc++-1.2

[Michael Biebl]

Control: tags -1 - moreinfo

On Mon, 26 Sep 2016 09:16:09 -0400 Scott Kitterman
 wrote:
> On Sunday, September 18, 2016 11:22:51 PM Adrian Bunk wrote:
> > Control: reassign 738897 ftp.debian.org
> > Control: retitle 738897 RM: libsigc++-1.2 -- RoQA; orphaned, obsolete
> > version Control: block 738897 by 672390
> > 
> > 
> > libsigc++-1.2 (last upstream release in 2005) is an old version
> > of libsigc++-2.0.
> > 
> > The only rdep left is freqtweak (marked as blocking this bug),
> > whose maintainer has promised to fix this issue soon.
> 
> This still needs fixing.  Please remove the moreinfo tag once that's done.

At this point it's probably safe to assume that freqtweak won't be fixed.

The package is orphaned [1] and dead upstream (last upstream activity is
over 7 years ago [2]).
Please remove it along with libsigc++-1.2.

Removing the moreinfo tag.

Michael

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846810
[2] https://sourceforge.net/projects/freqtweak/files/
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#850196: unblock: dgit/2.14

[Ian Jackson]

Package: release.debian.org
Severity: grave
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package dgit

dgit 2.13 has a HIDEOUS bug which causes it to generate malformed git
commits.  (#849041) To my surprise, extreme disappointment, and soon
everyone's annoyance, nothing in git (not even the usual git server
code) detected this.

Everyone who is using dgit 2.x must upgrade to 2.14 immediately.

The changes from 2.13 to 2.14 are:

 * The changelog.

 * The fixes for the two occurrences of this bug.

 * Changes to the test suite which I think will avoid any further
   bugs of this kind.

The test suite changes are textually large and hard to review, but:
This is a DEP-8 test suite and it is not run during build, so it
cannot cause a FTBFS bug.  Furthermore, I have (of course) run it:
both in its ad-hoc mode on stretch and done a formal full-on adt-run
in a sid schroot.  It passes (provided I work around the existing bug
#840673 in dput).

I will attach the output of
  debdiff dgit_2.{13,14}.dsc >dgit_2.13-2.14.debdiff
  debdiff --exclude=test dgit_2.{13,14}.dsc >dgit_2.13-2.14.exclude-test.debdiff

Under the circumstances I hope you agree I have chosen the right
severity for this bug.

unblock dgit/2.14

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
diff -Nru dgit-2.13/debian/changelog dgit-2.14/debian/changelog
--- dgit-2.13/debian/changelog	2016-12-21 01:32:41.0 +
+++ dgit-2.14/debian/changelog	2017-01-04 22:52:55.0 +
@@ -1,3 +1,14 @@
+dgit (2.14) unstable; urgency=critical
+
+  CRITICAL BUGFIX:
+  * Do not generate bogus commits with --overwrite or import-dsc.
+Closes:#849041.
+
+  Test suite:
+  * Run a lot of git-fsck.
+
+ -- Ian Jackson   Wed, 04 Jan 2017 22:52:55 +
+
 dgit (2.13) unstable; urgency=high
 
   Changed behaviour:
diff -Nru dgit-2.13/dgit dgit-2.14/dgit
--- dgit-2.13/dgit	2016-12-20 21:34:21.0 +
+++ dgit-2.14/dgit	2017-01-04 22:11:08.0 +
@@ -3538,7 +3538,7 @@
 parent $dgitview
 parent $archive_hash
 author $authline
-commiter $authline
+committer $authline
 
 $msg_msg
 
@@ -5944,10 +5944,14 @@
 	progress "Import, merging.";
 	my $tree = cmdoutput @git, qw(rev-parse), "$newhash:";
 	my $version = getfield $dsc, 'Version';
+	my $clogp = commit_getclogp $newhash;
+	my $authline = clogp_authline $clogp;
 	$newhash = make_commit_text <$tmp/control-expected
 diff debian/tests/control $tmp/control-expected
+
+t-ok
diff -Nru dgit-2.13/tests/tests/trustingpolicy-replay dgit-2.14/tests/tests/trustingpolicy-replay
--- dgit-2.13/tests/tests/trustingpolicy-replay	2016-12-19 17:32:37.0 +
+++ dgit-2.14/tests/tests/trustingpolicy-replay	2017-01-04 22:11:07.0 +
@@ -82,4 +82,4 @@
 attempt-replay "does not declare previously tags/$tagpfx/$v"
 
 
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/unrepresentable dgit-2.14/tests/tests/unrepresentable
--- dgit-2.13/tests/tests/unrepresentable	2016-12-20 21:36:58.0 +
+++ dgit-2.14/tests/tests/unrepresentable	2017-01-04 22:11:07.0 +
@@ -49,4 +49,4 @@
 start
 attempt
 
-echo ok.
+t-ok
diff -Nru dgit-2.13/tests/tests/version-opt dgit-2.14/tests/tests/version-opt
--- dgit-2.13/tests/tests/version-opt	2016-10-30 21:20:28.0 +
+++ dgit-2.14/tests/tests/version-opt	2017-01-04 22:11:07.0 +
@@ -29,4 +29,4 @@
 
 fgrep 'Update to version 1.1' ../${p}_${v}_source.changes
 
-echo ok.
+t-ok
Binary files /tmp/eWrXGWK9In/dgit-2.13/tests/worktrees/example_1.0.tar and /tmp/KlXJ3qcyMj/dgit-2.14/tests/worktrees/example_1.0.tar differ
diff -Nru --exclude test dgit-2.13/debian/changelog dgit-2.14/debian/changelog
--- dgit-2.13/debian/changelog	2016-12-21 01:32:41.0 +
+++ dgit-2.14/debian/changelog	2017-01-04 22:52:55.0 +
@@ -1,3 +1,14 @@
+dgit (2.14) unstable; urgency=critical
+
+  CRITICAL BUGFIX:
+  * Do not generate bogus commits with --overwrite or import-dsc.
+Closes:#849041.
+
+  Test suite:
+  * Run a lot of git-fsck.
+
+ -- Ian Jackson   Wed, 04 Jan 2017 22:52:55 +
+
 dgit (2.13) unstable; urgency=high
 
   Changed behaviour:
diff -Nru --exclude test dgit-2.13/dgit dgit-2.14/dgit
--- dgit-2.13/dgit	2016-12-20 21:34:21.0 +
+++ dgit-2.14/dgit	2017-01-04 22:11:08.0 +
@@ -3538,7 +3538,7 @@
 parent $dgitview
 parent $archive_hash
 author $authline
-commiter $authline
+committer $authline
 
 $msg_msg
 
@@ -5944,10 +5944,14 @@
 	progress "Import, merging.";
 	my $tree = cmdoutput @git, qw(rev-parse), "$newhash:";
 	my $version = getfield $dsc, 'Version';
+	my $clogp = commit_getclogp $newhash;
+	my $authline = clogp_authline $clogp;
 	$newhash =

Bug#850070: Processed: reassign 850070 to pylint

[Sandro Tosi]

I'm not convinced we should change anything in pylint to support
emacs21, which has been removed from debian since 2009

On Wed, Jan 4, 2017 at 9:21 AM, Debian Bug Tracking System
 wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> reassign 850070 pylint 1.5.6-1
> Bug #850070 [pyli] pyli: Fail to install if emacs21 is installed.
> Warning: Unknown package 'pyli'
> Bug reassigned from package 'pyli' to 'pylint'.
> Ignoring request to alter found versions of bug #850070 to the same values 
> previously set
> Ignoring request to alter fixed versions of bug #850070 to the same values 
> previously set
> Bug #850070 [pylint] pyli: Fail to install if emacs21 is installed.
> Marked as found in versions pylint/1.5.6-1.
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 850070: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850070
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems



-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850060: 2.0.874-2~exp1 issues

[Christian Seiler]

Control: reopen -1

Hi,
(reopening the bug report since iscsiuio doesn't actually work
according to what you're telling me)

On 01/04/2017 11:30 PM, Andrew Patterson wrote:
> 1. In debian/extra/initramfs.local-top and
> debian/extra/initramfs.local-bottom /sbin/iscsuio creates a pid file
> in /run/iscsiuio.pid. You cannot override it on the command-line. The
> --pidfile option for start-stop-daemon should point to this location
> instead of /run/initramfs/iscsiuio.pid.

Gah. I thought I had fixed that before the upload. :-(
A good thing there's experimental...

OTOH, initramfs should write to /run/initramfs only, so maybe
we should pass -p /run/initramfs/iscsiuio.pid to iscsiuio
instead as well.

> 2. The /sbin/iscsiuio deamon is trying to create a logfile in
> /var/log/iscsiuio.log. The /var/log directory does not exist in the
> initramfs.

Unfortunately that's hardcoded. OTOH from reading the code
this shouldn't be an issue.

> 3. The iscsiuio daemon is dieing before or during iscsistart -b. I am
> investigating why. It works fine when run after boot.

This is weird, on my test VM (no offloading NIC though) it
does start (and shut down again).

Question: does the network card require firmware for offloading
to work? If that's the case we might need to add the firmware
to the initramfs or this to work properly...

> 4. The commit 02c3051 "Don't ignore offloading NICs in iscsistart"
> will cause the interface to be configured in both iscsistart -N and in
> iscsistart -b for cards with iscsi hardware offload. I suspect we
> instead need a flag in iscsistart to bring up the NIC in iscsistart
> regardless if the NIC uses an offloadable driver. The local-top script
> can use this flag if /sbin/iscsiuio is not present, e.g.,
> 
> ISCSISTART_FLAGS=""
> if [ ! -x /sbin/iscsiuio ] ; then
>ISCSISTART_FLAGS="-S"
> fi

Hmm, now I see what you mean. I also dug up this commit which
gives a little insight.

https://github.com/open-iscsi/open-iscsi/commit/ee115be828362653478e6fe7cd4c6ee3318223ff

However, I think the solution is different from what you suggest: the
"fix" for #850057 is wrong I believe.

Debian sid package (w/o -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i (any mode): iscsistart -N ignores interface
 iscsistart -b doesn't configure offloading
   => won't work

Current upstream situation (w/ -DOFFLOAD_BOOT_SUPPORTED):

 - cxgb*i: iscsistart -N ignores interface
   iscsistart -b configures offloading 
   => should work
  (but don't have hardware)
  (also: remind me to check whether we copy the
  module into the initramfs)

 - bnx2i non-hba: iscsistart -N ignores it
  iscsistart -b doesn't configure offloading
   => won't work

 - bnx2i hba: iscsistart -N ignores it
  iscsistart -b configures offloading
   => should work (once iscsiuio is running)

"Fix" for 850057 (in experimental):

 - cxgb*i: iscsistart -N configures interface on host
   iscsistart -b configures offloading
 => no idea what happens thereafter
(since MAC address is the same on these cards: is
this a problem if they have the same IP?)

 - bnx2i non-hba: iscsistart -N configures interface
  iscsistart -b doesn't configure offloading,
but enables software iSCSI
  => should work

 - bnx2i hba: iscsistart -N configures interface
  iscsistart -b configures offloading
  => same IP, different MAC addresses
  => will cause trouble

The ideal solution would be to mirror the check that is done
for -b in -N. In that case we'd either configure the host
interface (and use software iSCSI), or configure offloading
(and use hardware iSCSI), but never both, and never neither.
So instead of the current patch for #850057 I would suggest
to do that instead. That should then also be upstream-able. I
can prepare a patch for that tomorrow.

That still leaves us with the question why iscsiuio doesn't
appear to work in the initramfs on your system. You could
just add strace to your initramfs and call iscsiuio in a
detached strace, a la

old:
start-stop-daemon ... /sbin/iscsiuio

new:
start-stop-daemon ... /bin/strace -- -D -f \
   -o /run/initramfs/iscsiuio.trace  -- /sbin/iscsiuio

(The first -- is for start-stop-daemon, the second one for
strace itself.)

Regards,
Christian

Bug#519590: Greeting ! I Am Mrs Monat Adama From Aleppo- Syria

[info...@bigpond.com]

Greeting !
How are you? My name is Mrs Monat Adama, a Citizen of Syria lived
in Aleppo- Syria., I'm one of the former senior inspector for Syria
National Petroleum Company(Kawkab Oil Company). I have Business
investment transaction worth $8.2 Million.  I will like to relocate
out from Syria, Because here in Syria is serious war here. I wait to
hear from you as soon as you see this message
regards,
Mrs Monat Adama

Bug#7330: Greeting ! I Am Mrs Monat Adama From Aleppo- Syria

[info...@bigpond.com]

Greeting !
How are you? My name is Mrs Monat Adama, a Citizen of Syria lived
in Aleppo- Syria., I'm one of the former senior inspector for Syria
National Petroleum Company(Kawkab Oil Company). I have Business
investment transaction worth $8.2 Million.  I will like to relocate
out from Syria, Because here in Syria is serious war here. I wait to
hear from you as soon as you see this message
regards,
Mrs Monat Adama

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

Am Mittwoch, den 04.01.2017, 13:06 -0700 schrieb Stephen Dennis:
> I've never been able to get the watch file to work right, and it is
> mis-behaving like it always has. 

Admitted watchfiles are not easy :) And your directory layout makes it
even more difficult...
However, you can use this as starting point:

version=4
ftp://ftp.tinymux.org/tinymux-2.10/([\d\.]+)/mux-@ANY_VERSION@.unix@ARC
HIVE_EXT@

Though this will not the alpha version as this'd canonically be the
newest version. 

(please add signature checking yourself)

> I think I've made all the other changes
> requested except I'm still a total loss as to how to migrate to the
> short
> debhelper format.

I wrote you a rule file as starting point. Attached. It is thought to
get you started. 
(Some parts are missing, like the hardening; also stuff and you need to
do outside of the rules, like to create the file d/clean with all files
listed and d/install to to put the files actually in place

Recommended readings:
- https://www.debian.org/doc/manuals/maint-guide -- especially the §5:
5.11 and 5.5 (in other words: d/dirs is probably not needed)
- dh_clean(1)

> On Tue, Jan 3, 2017 at 7:28 AM, Tobias Frost  wrote:
> 
> > > Very much appreciate the feedback. Willing to learn, but
> > > overwhelmed by
> > 
> > the
> > > Debian machinery.
> > 
> > You're welcome!
> > 
> > Yes, indeed it can be overwhelming. But don't worry, we've all had
> > to learn
> > this ;-)
> > 
> > > Stupid question at the top: If I dput another package, does it
> > > update
> > 
> > this
> > > one or do I need to delete the currently uploaded package from
> > > mentors
> > > first?
> > 
> > You can just dput it. It will overwrite the previous version.
> > 
> > > - d/changelog. A lot has changed. Here are pointers to 'brief'
> > > change
> > 
> > logs
> > > for 2.7, 2.9, and 2.10:
> > > 
> > > http://www.tinymux.org/changes27.txt
> > > http://www.tinymux.org/changes29.txt
> > > http://www.tinymux.org/changes.txt
> > > 
> > > That's four years of why to retrace, and the actual check-in
> > > messages
> > 
> > from
> > > the repository would be much longer. Does Debian really want all
> > > of that?
> > 
> > No, the debian changelog is only for changes done to the (Debian)
> > packaging,
> > not to the upstream source. See the Debian Policy §4.4
> > You ship already an upstream changelog (though it seems only to be
> > limited
> > to
> > the last version and more a NEWS file than a real changelog...)
> > 
> > > - d/patches
> > > 
> > >   - Not sure what a dep3 header is, yet. More to learn.
> > 
> > http://dep.debian.net/deps/dep3/
> > Hint: $ quilt header -e --dep3
> > 
> > >   - All but one of the patches is checked-in upstream already.
> > 
> > Ok. (Document that with the appropiate dep3-header "Applied-
> > Upstream")
> > 
> > >   - I don't know how to have config.guess be updated at build
> > > time? Did
> > 
> > not
> > > know about that one. Is this part of automake? TinyMUX is more
> > > autoconf
> > > than it once was, but it still doesn't use automake or libtool.
> > 
> > https://wiki.debian.org/Autoreconf
> > 
> > NOTE: When you change to compat level 10 and short debhelper format
> > it is
> > even
> > more easier, as compat level 10 default to use dh_autoreconf.
> > 
> > >   - Dependency-created-noise.patch. The way users normally build
> > 
> > TinyMUX is
> > > untar the package, ./configure;make depend;make. The 'make
> > > depend' scans
> > > all the include files and builds ".depend" which is then re-
> > > consumed by
> > > Makefile. It must exist -- at least empty. The Debian build
> > > system would
> > > see either way as a source change, but it isn't a change to taken
> > 
> > upstream.
> > > It always changes in different ways in every environment.
> > 
> > Another reason to get rid of it to make it really portable ;-) But
> > as said,
> > patching it is wrong, especially if it can be reconstructed during
> > the
> > build.
> > 
> > If it just needs to exists, why not
> > - remove it e.g via (the file) debian/clean
> > - after configure, touch it to be present
> > - in build run make
> > 
> > > - d/copyright dep5...OK, more to study. The copyright is the same
> > > as
> > > previous 2.6 package except for the dates. That was hammered out
> > > between
> > > the four MUSH flavors (PennMUSH, TInyMUSH, TinyMUX, and
> > > RhostMUSH). I'm
> > > loath to change the substance of it, but if there is some Debian-
> > > friendly
> > > form to call out that it is the Artistic license, that seems
> > > reasonable
> > > enough.
> > 
> > Well that happens when a package gets some care only after several
> > years
> > (btw, THANK YOU for this caring!) Policies / Procedures have been
> > updated,
> > so the "Machine-readable debian/copyright file" is now standard.
> > 
> > > - silent rule. TinyMUX uses the other autoconf tools, but not
> > > libool or
> > > automake. Silent rule seems to be a term from those things?
> > 
> > When I compiled the package I saw that the gcc co

Bug#849918: RFS: tinymux/2.10.1.13-1

[Tobias Frost]

Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> 
> I wrote you a rule file as starting point. Attached. It is thought to
> get you started. 
> (Some parts are missing, like the hardening; also stuff and you need
> to
> do outside of the rules, like to create the file d/clean with all
> files
> listed and d/install to to put the files actually in place
> 
PS: I needed to add --no-parallel because parallel build is broken
here. This is also bug in your Makefile...

To trigger
#debuild -j1
(works)

#debuild -j4
(...)
g++ -g -O2 -fdebug-prefix-
map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o -L.
-lm -lcrypt   -lmux 
/usr/bin/ld: cannot find -lmux
collect2: error: ld returned 1 exit status
Makefile:189: recipe for target 'stubslave' failed
make[1]: *** [stubslave] Error 1
make[1]: *** Waiting for unfinished jobs
( if [ -f netmux ]; then mv -f netmux netmux~ ; fi )
g++ -g -O2 -fdebug-prefix-
map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o netmux _build.o alarm.o
alloc.o attrcache.o boolexp.o bsd.o command.o comsys.o conf.o cque.o
create.o db.o db_rw.o eval.o file_c.o flags.o funceval.o funceval2.o
functions.o funmath.o game.o help.o htab.o local.o log.o look.o mail.o
match.o mathutil.o mguests.o modules.o move.o muxcli.o netcommon.o
object.o predicates.o player.o player_c.o plusemail.o powers.o quota.o
rob.o pcre.o set.o sha1.o speech.o stringutil.o strtod.o svdrand.o
svdhash.o timer.o timeabsolute.o timedelta.o timeparser.o timeutil.o
timezone.o unparse.o utf8tables.o vattr.o walkdb.o wild.o
wiz.o  version.o -L. -lm -lcrypt -lmux
/usr/bin/ld: cannot find -lmux
collect2: error: ld returned 1 exit status
Makefile:198: recipe for target 'netmux' failed
make[1]: *** [netmux] Error 1
make[1]: Leaving directory
'/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13/src'

Bug#645828: your search.cpan.org/metacpan.org commit / Bug#645828: Fold libdatetime-astro-sunrise-perl into libdatetime-event-sunrise-perl

[gregor herrmann]

On Mon, 25 May 2015 19:48:10 +0200, Axel Beckert wrote:

> I also wonder if #645828 is fixed with libdatetime-event-sunrise-perl
> being in Debian or if #645828 is only fixed when
> libdatetime-astro-sunrise-perl has been removed from the archive.

There's more background information in Ubuntu's launchpad from
upstream:

https://bugs.launchpad.net/bugs/1654056

I guess we should just remove libdatetime-astro-sunrise-perl …


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Die Quote: Kali Spera Mamatschi


signature.asc
Description: Digital Signature

Bug#850199: golang-github-gogits-cron: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-gogits-cron
Version: 0.0~git20160810.32.7f3990a-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/gogits/cron
github.com/gogits/cron
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/gogits/cron
=== RUN   TestConstantDelayNext
--- PASS: TestConstantDelayNext (0.00s)
=== RUN   TestFuncPanicRecovery

[... snipped ...]

--- PASS: TestAddWhileRunning (1.00s)
=== RUN   TestAddWhileRunningWithDelay
--- PASS: TestAddWhileRunningWithDelay (6.01s)
=== RUN   TestSnapshotEntries
--- PASS: TestSnapshotEntries (1.99s)
=== RUN   TestMultipleEntries
--- PASS: TestMultipleEntries (1.00s)
=== RUN   TestRunningJobTwice
--- PASS: TestRunningJobTwice (2.00s)
=== RUN   TestRunningMultipleSchedules
--- PASS: TestRunningMultipleSchedules (1.00s)
=== RUN   TestLocalTimezone
2017/01/02 21:06:59 End of range (60) above maximum (59): 60
--- FAIL: TestLocalTimezone (1.01s)
=== RUN   TestStopWithoutStart
--- PASS: TestStopWithoutStart (0.00s)
=== RUN   TestJob
--- PASS: TestJob (0.99s)
=== RUN   TestRange
--- PASS: TestRange (0.00s)
=== RUN   TestField
--- PASS: TestField (0.00s)
=== RUN   TestBits
--- PASS: TestBits (0.00s)
=== RUN   TestSpecSchedule
--- PASS: TestSpecSchedule (0.00s)
=== RUN   TestActivation
--- PASS: TestActivation (0.00s)
=== RUN   TestNext
--- PASS: TestNext (0.00s)
=== RUN   TestErrors
2017/01/02 21:07:01 Expected 5 or 6 fields, found 1: xyz
2017/01/02 21:07:01 End of range (60) above maximum (59): 60
2017/01/02 21:07:01 End of range (60) above maximum (59): 60
2017/01/02 21:07:01 Failed to parse int from XYZ: strconv.ParseInt: parsing 
"XYZ": invalid syntax
--- PASS: TestErrors (0.00s)
=== RUN   TestNextWithTz
--- PASS: TestNextWithTz (0.00s)
FAIL
exit status 1
FAILgithub.com/gogits/cron  18.062s
dh_auto_test: go test -v -p 1 github.com/gogits/cron returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-gogits-cron/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 1.5%.

Thanks.

Bug#850197: golang-github-dgryski-go-bits: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-dgryski-go-bits
Version: 0.0~git20151205.0.86c69b3-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/dgryski/go-bits
github.com/dgryski/go-bits
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/dgryski/go-bits
=== RUN   TestQuickCtz
--- PASS: TestQuickCtz (0.00s)
=== RUN   TestQuickClz

[... snipped ...]

/usr/lib/go-1.7/src/runtime/asm_amd64.s:2086 +0x1 fp=0xc420044fa8 
sp=0xc420044fa0
created by testing.(*T).Run
/usr/lib/go-1.7/src/testing/testing.go:646 +0x2ec

goroutine 1 [chan receive]:
testing.(*T).Run(0xc420018180, 0x53cf14, 0xf, 0x54be38, 0xc42003fd01)
/usr/lib/go-1.7/src/testing/testing.go:647 +0x316
testing.RunTests.func1(0xc420018180)
/usr/lib/go-1.7/src/testing/testing.go:793 +0x6d
testing.tRunner(0xc420018180, 0xc42003fe20)
/usr/lib/go-1.7/src/testing/testing.go:610 +0x81
testing.RunTests(0x54be58, 0x5dd7c0, 0x3, 0x3, 0x53c471)
/usr/lib/go-1.7/src/testing/testing.go:799 +0x2f5
testing.(*M).Run(0xc42003fee8, 0xc42000e510)
/usr/lib/go-1.7/src/testing/testing.go:743 +0x85
main.main()
github.com/dgryski/go-bits/_test/_testmain.go:58 +0xc6

rax0x54be20
rbx0x38fc2ffac2fd9401
rcx0x54be50
rdx0x38fc2ffac2fd9401
rdi0xc4200449b8
rsi0x479100
rbp0xc420044998
rsp0xc420044970
r8 0x18b
r9 0xc42000ff48
r100x50e6a0
r110x0
r120x10
r130x1f50
r140x1f6
r150x582480
rip0x479105
rflags 0x10216
cs 0x33
fs 0x0
gs 0x0
exit status 2
FAILgithub.com/dgryski/go-bits  0.022s
dh_auto_test: go test -v -p 1 github.com/dgryski/go-bits returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-dgryski-go-bits/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 17%.

Thanks.

Bug#850198: golang-github-dvsekhvalnov-jose2go: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-dvsekhvalnov-jose2go
Version: 1.2-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/dvsekhvalnov/jose2go 
github.com/dvsekhvalnov/jose2go/aes github.com/dvsekhvalnov/jose2go/arrays 
github.com/dvsekhvalnov/jose2go/base64url 
github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf 
github.com/dvsekhvalnov/jose2go/keys/ecc 
github.com/dvsekhvalnov/jose2go/keys/rsa github.com/dvsekhvalnov/jose2go/padding
github.com/dvsekhvalnov/jose2go/base64url
github.com/dvsekhvalnov/jose2go/arrays
github.com/dvsekhvalnov/jose2go/aes
github.com/dvsekhvalnov/jose2go/compact
github.com/dvsekhvalnov/jose2go/kdf
github.com/dvsekhvalnov/jose2go/keys/ecc

[... snipped ...]

--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/aes 0.004s
=== RUN   Test
OK: 6 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/arrays  0.003s
=== RUN   Test
err = illegal base64 data at input byte 32
OK: 3 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/base64url   0.003s
=== RUN   Test

err=illegal base64 data at input byte 4
OK: 8 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/compact 0.003s
=== RUN   Test
OK: 16 passed
--- PASS: Test (0.15s)
PASS
ok  github.com/dvsekhvalnov/jose2go/kdf 0.151s
=== RUN   Test
OK: 6 passed
--- PASS: Test (0.04s)
PASS
ok  github.com/dvsekhvalnov/jose2go/keys/ecc0.040s
=== RUN   Test
OK: 4 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/keys/rsa0.005s
=== RUN   Test
OK: 13 passed
--- PASS: Test (0.00s)
PASS
ok  github.com/dvsekhvalnov/jose2go/padding 0.003s
dh_auto_test: go test -v -p 1 github.com/dvsekhvalnov/jose2go 
github.com/dvsekhvalnov/jose2go/aes github.com/dvsekhvalnov/jose2go/arrays 
github.com/dvsekhvalnov/jose2go/base64url 
github.com/dvsekhvalnov/jose2go/compact github.com/dvsekhvalnov/jose2go/kdf 
github.com/dvsekhvalnov/jose2go/keys/ecc 
github.com/dvsekhvalnov/jose2go/keys/rsa 
github.com/dvsekhvalnov/jose2go/padding returned exit code 1
debian/rules:7: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-dvsekhvalnov-jose2go/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 6%.

Thanks.

Bug#850200: golang-github-google-gofuzz: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:golang-github-google-gofuzz
Version: 0.0~git20150903.0.e4af62d-2
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/google/gofuzz
github.com/google/gofuzz
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/google/gofuzz
=== RUN   TestFuzz_basic
--- PASS: TestFuzz_basic (0.00s)
=== RUN   TestFuzz_structptr
--- FAIL: TestFuzz_structptr (0.00s)
fuzz_test.go:96: a not nil seems to not be getting set, was zero value 
10 times
fuzz_test.go:96: as seems to not be getting set, was zero value 10 times
=== RUN   TestFuzz_structmap
--- PASS: TestFuzz_structmap (0.00s)
=== RUN   TestFuzz_structslice
--- PASS: TestFuzz_structslice (0.00s)
=== RUN   TestFuzz_custom
--- PASS: TestFuzz_custom (0.00s)
=== RUN   TestFuzz_interface
--- PASS: TestFuzz_interface (0.00s)
=== RUN   TestFuzz_interfaceAndFunc
--- PASS: TestFuzz_interfaceAndFunc (0.00s)
=== RUN   TestFuzz_noCustom
--- PASS: TestFuzz_noCustom (0.00s)
=== RUN   ExampleSimple
--- PASS: ExampleSimple (0.00s)
=== RUN   ExampleCustom
--- PASS: ExampleCustom (0.00s)
=== RUN   ExampleComplex
--- PASS: ExampleComplex (0.00s)
=== RUN   ExampleMap
--- PASS: ExampleMap (0.00s)
=== RUN   ExampleSingle
--- PASS: ExampleSingle (0.00s)
=== RUN   ExampleEnum
--- PASS: ExampleEnum (0.00s)
FAIL
exit status 1
FAILgithub.com/google/gofuzz0.008s
dh_auto_test: go test -v -p 1 github.com/google/gofuzz returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/golang-github-google-gofuzz/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 6%.

Thanks.

Bug#850201: tendermint-go-flowrate: FTBFS randomly (failing tests)

[Santiago Vila]

Package: src:tendermint-go-flowrate
Version: 0.0~git20161104.0.a20c98e-1
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_testdir -i -O--buildsystem=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/tendermint/go-flowrate/flowrate
github.com/tendermint/go-flowrate/flowrate
   dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/tendermint/go-flowrate/flowrate
=== RUN   TestReader
--- PASS: TestReader (0.45s)
=== RUN   TestWriter
--- FAIL: TestWriter (0.51s)
io_test.go:140: w.Status(0) expected {true 2017-01-02 20:57:40.72 + 
UTC 400ms 0s 80 4 200 200 200 200 20 100ms 80.000%}; got {true 2017-01-02 
20:57:40.72 + UTC 420ms 0s 80 4 200 197 190 200 20 100ms 80.000%}
io_test.go:140: w.Status(1) expected {true 2017-01-02 20:57:40.72 + 
UTC 500ms 100ms 100 5 200 200 200 200 0 0s 100.000%}; got {true 2017-01-02 
20:57:40.72 + UTC 520ms 100ms 100 5 200 197 192 200 0 0s 100.000%}
FAIL
exit status 1
FAILgithub.com/tendermint/go-flowrate/flowrate  0.962s
dh_auto_test: go test -v -p 1 github.com/tendermint/go-flowrate/flowrate 
returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/tendermint-go-flowrate/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).

After building 200 times, the failure rate observed here is about 10%.

Thanks.

Bug#850202: dash: test with multiple conditions cannot handle variable whose expanded value is same as an operator

[J G Miller]

Package: dash
Version: 0.5.7-4+b1
Severity: normal

In Bourne shell script with dash, using either [ ] or test,

   test -n "${variable}" && echo "variable is set to -->${variable}<--"

works as expected even if the value of variable is to a value the same
as a test operator eg -ne or -nt

   variable="-ne" ; test -n "${variable}" && echo "variable is set to 
-->${variable}<--"
   variable is set to -->-ne<--

However the addition of another test condition with -a or -o results in an
unexpected behavior in that the expanded variable is now treated as an operator
and not just as the string as should be the case.

variable="-ne" ; test -n "${variable}" -a -n "${DISPLAY}" && echo "variable 
is set to -->${variable}<--"
dash: 1: test: Illegal number: -n

Applying quoted parentheses makes no difference.

variable="-ne" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
echo "variable is set to -->${variable}<--"
dash: 2: test: Illegal number: -n

Similarly bad behavior is seen with a variable set to "-nt", which is how I 
stumbled upon this problem.

variable="-nt" ; test \( -n "${variable}" \) -a \( -n "${DISPLAY}" \) && 
echo "variable is set to -->${variable}<--"
dash: 3: test: closing paren expected

So if the test is consists of a single condtion, the expanded variable does not 
cause
problems with the test, and should not affect the test if it is part of a 
multiple condition test.

Incidentally bash also has this problem.

So the short term kludge in a shell script is to do

 if [ -n "${variable_with_problem_value}" ]
 then
  if [ \( other_condition1 \) -a \( other_condition2 \) ]
  then
   ...



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) 
(ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dash depends on:
ii  debianutils  4.4+b1
ii  dpkg 1.17.27
ii  libc62.19-18+deb8u6

dash recommends no packages.

dash suggests no packages.

-- debconf information:
* dash/sh: true

Bug#850203: scidavis: Upgrade to v.1.14

[Vladimir]

Package: scidavis
Version: 1.14-local1
Severity: normal
Tags: patch

Dear Maintainer,

  I prepared the files necessary to build the DEB package for SciDaVis
v.1.14 (the latest so far) and suggest them for your consideration.

  I downloaded the 'debian' catalog for SciDaVis version 1.D9-2 from
here: https://tracker.debian.org/pkg/scidavis and then made the
following changes:

1. Refreshed the 'changelog' file
2. Switched from compatibility level 7 to 9 in the 'compat' file
3. Replaced the 'libgsl-dev' with 'libgsl0-dev' in the 'control' file
4. Added the installation of the icons and desktop files in the
'install' file
5. Refreshed the 'qwtplot3d-headers.patch' file
6. Added the 'remove-unnecessary-doc-files.patch' to fix the
corresponding lintian warning about unneeded files (duplicates)
7. Added the 'scidavis-desktop-mime.patch' to fix the lintian warning
about the Exec string
8. Added the 'icon' tag to the 'scidavis.xml' file with MIME type description
9. Turned off the 'gcc6.patch' in 'patches/serial', since the upstream
sources are fixed already
10. Refreshed the 'without-3rdparty-liborigin.patch' for new source
files
11. Fixed the 'rules' file to use the native 'qmake_qt4' build system
with the necessary hardening (also fixes a number of lintial warnings).

A complete list of Lintian warnings I tried to fix is here:
https://lintian.debian.org/maintainer/georg...@debian.org.html#scidavis

After all these changes I managed to build the scidavis_1.14 package on
my Jessie AMD64 system successfully. So I hope my files may be used to
put the SciDaVis into Debian repository.

Here are the corresponding links:
https://ftp.wombat.org.ua/Debian/scidavis_1.14-local1.debian.tar.bz2
https://ftp.wombat.org.ua/Debian/scidavis_1.14-local1.debdiff

Regards,
   Vladimir




-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-0.bpo.2-amd64 (SMP w/2 CPU cores)
Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages scidavis depends on:
ii  libc6 2.19-18+deb8u6
ii  libgcc1   1:4.9.2-10
ii  libgl1-mesa-glx [libgl1]  12.0.4-2~bpo8+1
ii  libglu1-mesa [libglu1]9.0.0-2
ii  libgsl0ldbl   1.16+dfsg-2
ii  libmuparser2  2.2.3-4
ii  libqt4-network4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-opengl 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-qt3support 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-svg4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqt4-xml4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtcore44:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-3+deb8u1
ii  libqwt5-qt4   5.2.3-1
ii  libqwtplot3d-qt4-00.2.7+svn191-7
ii  libstdc++64.9.2-10
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages scidavis recommends:
pn  qt-assistant-compat  

scidavis suggests no packages.

-- no debconf information

Bug#845499: Clarification...

[Alec Leamas]

On Mon, 26 Dec 2016 17:38:47 +0100 Samuel Thibault 
 wrote:

> Hello,
>
> Mails sent to n...@bugs.debian.org are NOT sent to the submitter, so I
> actually never got this answer...

Oops, debian still has a few surprises in her sleeves... thanks for 
heads-up!


>
> Alec Leamas, on Fri 09 Dec 2016 15:13:12 +0100, wrote:
> > However, I would be happy to accept patches to make it build also on
> > hurd
>
> Here is the part of the originally submitted patch which is still
> needed.

Thanks. This is actually messier than it should be. A bad mentors build 
host + some misunderstandings between me and Gianfranco boiled down to 
that although the changelog in the -6  release mentions your patch it 
was actually not included.


Anyway, a new -7 update is already under way, this time With Patch 
Included (tm)


> > (atltough without USB and major desktop support, the hurd usecase
> > seems, well, far fetched).
>
> It's mostly meant to make reverse build-depends build, without having to
> explicitly drop lirc support.

Makes sense. And for me as upstream I have the overall feeling that 
compiling on other architectures sometimes reveals otherwise unnoticed 
bugs. So, thanks for your input.


I have also patched upstream according to 
https://paste.fedoraproject.org/520046/83574167, more or less your 
patch. Actually, it is your patch, it's your name on it :)


Cheers!

--alec

Bug#849649: Pending fixes for bugs in the commons-daemon package

[pkg-java-maintainers]

tag 849649 + pending
thanks

Some bugs in the commons-daemon package are closed in revision
ccb7f63f4fb6388f671e8d4a354095319b698247 in branch 'master' by Markus
Koschany

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/commons-daemon.git/commit/?id=ccb7f63

Commit message:

Fix build failure on arm architectures by appending the ${jvm_includes}

variable to CPPFLAGS.

Closes: #849649

Bug#848692: [Reportbug-maint] Bug#848692: reportbug fails with punctuation in name

[Sandro Tosi]

> A possible patch is to rename 'email' to 'emailaddr' in get_user_id, see
> attached patch.

Thanks Didier, i'm going to apply your patch soon!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#848692: reportbug fails with punctuation in name

[Sandro Tosi]

On Wed, Dec 21, 2016 at 9:24 PM, brian m. carlson
 wrote:
> The issue is this code:
>
> if re.match(r'[\w\s]+
> , realname):
> return '%s <%s>' % (realname, email)
>
> addr = email.utils.formataddr((realname, email))
>
> We don't take the branch since “.” (and “'”, etc.) are not in [\w\s],
> and then we throw an exception as email is not the module imported at
> the top, but the local variable.


I just removed that first if, as email.utils.formataddr() is more than
able to deal with all the special cases, we dont need to do that too,
thx!

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Ondrej Novy  writes:

> Maybe orphan it first?

Is this package used in Debian?

I tried to fix this issue, but the package has a FTBFS error:

ImportError: The ``fake-factory`` package is now called ``Faker``.

So I updated it to the latest version of python-factory-boy from Pypi
(referenced from debian/watch) but now it appears that this version is
missing the tests.

I guess I probably need to get the github sources instead of the Pypi
sources.

Not sure if I can git push to the openstack git repository, so I haven't
done so (and I might have to redo it anyway). If I can get this working,
I might move it to DPMT.
-- 
Brian May 

Bug#849586: reportbug incorrectly short-circuits From address escaping with non-ASCII characters

[Sandro Tosi]

control: forcemerge 848692 -1


On Wed, Dec 28, 2016 at 5:53 PM, Russ Allbery  wrote:
>
> if re.match(r'[\w\s]+$', realname):
> return '%s <%s>' % (realname, email)
>
> addr = email.utils.formataddr((realname, email))
>
> I suspect this worked fine in Python 2, since this regex doesn't use
> the UNICODE flag.  However, in Python 3, I believe regexes are str
> types by default and therefore Unicode by default, so this will match
> non-ASCII characters, short-circuit this logic, and never call
> formataddr.
>
> I'm not sure the original motivation for the short-circuit here, but
> I suspect just removing the re.match conditional and unconditionally
> calling email.utils.formataddr will produce the correct behavior.

i just did exactly that as part of 848692 (hence the merge)


-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#850157: Please deprecate all ad-hoc patch systems

[Russ Allbery]

Ian Jackson  writes:

> The policy section "Source package handling: debian/README.source"
> should be entirely replaced with a requirement that

>   Running dpkg-source -x on a source package MUST produce the source
>   of the package, ready for editing, and allow one to make changes,
>   and run dpkg-buildpackage to produce a modified package, without
>   taking any additional steps.

>   If the upstream or Debian source code maintenance practices applying
>   to the package are nontrivial (for example, if the uploaded source
>   package is itself generated from a metarepository), this should be
>   documented in debian/README.source.

> And one could probably add

>   Previously, packages which had ad-hoc patch systems would document
>   their source code management practices in debian/README.source.
>   Source packages now MUST NOT use in-source-package patch systems
>   other than `3.0 (quilt)'.

How many packages in the archive would we make buggy by adding this
requirement?  I think it's probably the right thing to do anyway, but I'd
like to understand the scope of the disruption.

-- 
Russ Allbery (r...@debian.org)   

Bug#850204: java-gnome: FTBFS randomly (Fatal IO error 0 (Success) on X server)

[Santiago Vila]

Package: src:java-gnome
Version: 4.1.3-4
Severity: important

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
test -x debian/rules
mkdir -p "."
touch debian/stamp-autotools-files
chmod a+x /<>/./configure
mkdir -p .
cd . && CFLAGS="-g -O2 -fdebug-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security" CXXFLAGS="-g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security" CPPFLAGS="-Wdate-time -D_FORTIFY_SOURCE=2" 
LDFLAGS="-Wl,-z,relro" /<>/./configure --build=x86_64-linux-gnu 
--prefix=/usr --includedir="\${prefix}/include" --mandir="\${prefix}/share/man" 
--infodir="\${prefix}/share/info" --sysconfdir=/etc --localstatedir=/var 
--libexecdir="\${prefix}/lib/java-gnome" --srcdir=. --disable-maintainer-mode 
--disable-dependency-tracking --disable-silent-rules --libdir=/usr/lib/jni 
jdk=/usr/lib/jvm/default-java

equivalence, v0.2
...configuring Java projects to build and run on Linux & Unix

Identify operating system: Debian


[... snipped ...]

SNAPdoc/api/org/gnome/gtk/RadioButton.png
SNAPdoc/api/org/gnome/gtk/ComboBox.png
SNAPdoc/api/org/gnome/gtk/Arrow.png
SNAPdoc/api/org/gnome/gtk/Notebook.png
SNAPdoc/api/org/gnome/gtk/Calendar.png
SNAPdoc/api/org/gnome/gtk/ComboBoxText.png
SNAPdoc/api/org/gnome/gtk/ComboBoxText--Entry.png
SNAPdoc/api/org/freedesktop/cairo/Context-line.png
SNAPdoc/api/org/gnome/gtk/TextView.png
SNAPdoc/api/org/gnome/gtk/TextView-BorderWindows.png
SNAPdoc/api/org/freedesktop/cairo/Context-arc.png
SNAPdoc/api/org/freedesktop/cairo/Context-arcNegative.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-rotate.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-scale.png
SNAPdoc/api/org/freedesktop/cairo/Matrix-translate.png
SNAPdoc/api/org/freedesktop/cairo/Context-rectangle.png
SNAPdoc/api/org/gnome/gtk/EntryCompletion.png
SNAPdoc/api/org/gnome/gtk/Entry.png
SNAPdoc/api/org/gnome/gtk/LinkButton.png
SNAPdoc/api/org/gnome/gtk/InfoBar.png
SNAPdoc/api/org/gnome/gtk/Switch.png
WRITE   doc/api/org/freedesktop/cairo/Operator-in.png
WRITE   doc/api/org/freedesktop/cairo/Operator-clear.png
WRITE   doc/api/org/freedesktop/cairo/Operator-source.png
WRITE   doc/api/org/freedesktop/cairo/Operator-over.png
WRITE   doc/api/org/freedesktop/cairo/Operator-out.png
WRITE   doc/api/org/freedesktop/cairo/Operator-atop.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_over.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_in.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_out.png
WRITE   doc/api/org/freedesktop/cairo/Operator-dest_atop.png
WRITE   doc/api/org/freedesktop/cairo/Operator-xor.png
WRITE   doc/api/org/freedesktop/cairo/Operator-add.png
WRITE   doc/api/org/freedesktop/cairo/Operator-saturate.png
KILLXvfb

(.:12544): Gdk-WARNING **: .: Fatal IO error 0 (Success) on X server :99.

Makefile:87: recipe for target 'doc' failed
make[1]: *** [doc] Error 1
make[1]: Leaving directory '/<>'
/usr/share/cdbs/1/class/makefile.mk:77: recipe for target 
'debian/stamp-makefile-build' failed
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is just how the build ends, not necessarily the relevant part.

I've put several build logs here:

https://people.debian.org/~sanvila/java-gnome/

If this is really a bug in one of the build-depends, please use reassign and 
affects,
so that this is still visible in the page for this package.

The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).


Note 1: It seems that the build is creating snapshots for the documentation,
and there is another bug (#836100) requesting a slightly different way to
take snapshots. Would fixing #836100 help to fix this one?

(X-Debbugs-Cc for Simon in case he knows the answer).

Note 2: The failure rate is very small, I have not tried to measure it.
I guess it is well below 10%, so if you try to reproduce it, please
try really really a *lot* of times.

Note 3: I would not really recommend trying a lot of times to reproduce it.
Instead, it could be more productive to look at the build logs and
try to guess *how* it may happen, but I don't really know the internals
of this package, so this is really up to you.

Thanks.

Bug#850106: guile-2.0-dev: Uninstallable due to unmeetable dependencies

[Rob Browning]

Michael Vehrs  writes:

> Aptitude says:
>
> The following packages have unmet dependencies:
>libtinfo-dev : Depends: libtinfo5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.
>libncurses5-dev : Depends: libtinfo5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.
>  Depends: libncurses5 (= 5.9+20140913-1+b1) but 
> 6.0+20151024-2 is installed.

I'm not sure why you're seeing this.  I just set up a vagrant jessie box
with jessie-updates and security updates, and an "apt get install
guile-2.0-dev" worked fine.

I started the test system like this:

  mkdir tmp-test-guile-install
  cd tmp-test-guile-install
  vagrant init debian/jessie64
  vagrant up
  vagrant ssh
  sudo su -

and then adjusted the /etc/apt/sources.list to read:

  deb http://httpredir.debian.org/debian jessie main
  deb http://httpredir.debian.org/debian jessie-updates main
  deb http://security.debian.org/ jessie/updates main

and I had no /etc/apt/preferences.  After that:

  apt update
  apt install guile-2.0-dev

worked fine.

Perhaps that config isn't similar enough to yours?

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#848655: [reportbug/master] use integer division when computing the max length for a name; suggestion by Ben Longbons; Closes: #848655

[Sandro Tosi]

tag 848655 pending
tag 848655 pending
thanks

Date:   Wed Jan 4 19:40:33 2017 -0500
Author: Sandro Tosi 
Commit ID: ca3f62a98591d24c2b1600a88fed692c3f6b4317
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=ca3f62a98591d24c2b1600a88fed692c3f6b4317
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=ca3f62a98591d24c2b1600a88fed692c3f6b4317

use integer division when computing the max length for a name; suggestion 
by Ben Longbons; Closes: #848655

  

Bug#848692: [reportbug/master] fix the 'email' name clash in reportbug.utils functions by renaming their arguments to 'emailaddr', this fixes names with special characters in the address; patch by Did

[Sandro Tosi]

tag 848692 pending
tag 848692 pending
thanks

Date:   Wed Jan 4 19:18:56 2017 -0500
Author: Sandro Tosi 
Commit ID: e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=e5dc19b88f1e2a5e99a507fbc21505b44af2ff7e

fix the 'email' name clash in reportbug.utils functions by renaming their 
arguments to 'emailaddr', this fixes names with special characters in the 
address; patch by Didier 'OdyX' Raboud; Closes: #848692

  

Bug#849677: [reportbug/master] capitalize, not uppercase, ampersend user replacement; patch by Nis Martensen; Closes: #849677

[Sandro Tosi]

tag 849677 pending
tag 849677 pending
thanks

Date:   Wed Jan 4 19:51:57 2017 -0500
Author: Sandro Tosi 
Commit ID: 6869191bb7a1e518f86ee05a56f8f2f39ade6e57
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=6869191bb7a1e518f86ee05a56f8f2f39ade6e57
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=6869191bb7a1e518f86ee05a56f8f2f39ade6e57

capitalize, not uppercase, ampersend user replacement; patch by Nis 
Martensen; Closes: #849677

  

Bug#849749: [reportbug/master] port bug script and control file to py3k; patch by Nis Martensen; Closes: #849749

[Sandro Tosi]

tag 849749 pending
tag 849749 pending
thanks

Date:   Wed Jan 4 19:46:54 2017 -0500
Author: Sandro Tosi 
Commit ID: 42181e036d0efe54d73e92ec9f90dec00fea297e
Commit URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff;h=42181e036d0efe54d73e92ec9f90dec00fea297e
Patch URL: 
http://anonscm.debian.org/gitweb/?p=reportbug/reportbug.git;a=commitdiff_plain;h=42181e036d0efe54d73e92ec9f90dec00fea297e

port bug script and control file to py3k; patch by Nis Martensen; Closes: 
#849749

  

Bug#850205: automatic serial console configuration for jessie and above

[Antoine Beaupré]

Package: vmdebootstrap
Version: 1.7-1
Severity: wishlist

I see that in #800910 the --serial-console flag has been basically
disabled for platforms other than wheezy. That's fine to resolve the
bug described there (although I agree the fix should be sysvinit
specific), but it actually removes an interesting feature for newer
platforms.

I think vmdebootstrap should remove the --serial-console flag or make
it work in newer releases. In systemd, the way to configure the serial
console is to pass the serial port on the kernel commandline, as such:

GRUB_CMDLINE_LINUX="console=ttyS0"

Then systemd automatically picks it up and configures a getty on the
right port. More details here:

https://wiki.debian.org/systemd#Virtual_and_serial_console_changes

I am not sure how to do it myself in the vmdebootstrap
environment. Maybe it is trivial to add grub flags, but I didn't find
an easy way to do this. I feel hesitant in making a script that
will just overwrite the kernel commandline directly, as vmdebootstrap
may already deal with this file in its own ways...

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.67
ii  kpartx  0.5.0-6+deb8u2
ii  libjs-sphinxdoc 1.4.6-1~bpo8+1
ii  parted  3.2-7
ii  python-cliapp   1.20150829-1~bpo8+1
ii  python-distro-info  0.14
ii  python2.7   2.7.9-2+deb8u1
pn  python:any  
ii  qemu-utils  1:2.1+dfsg-12+deb8u6

Versions of packages vmdebootstrap recommends:
ii  dosfstools3.0.27-1
ii  extlinux  3:6.03+dfsg-5+deb8u1
ii  grub2-common  2.02~beta2-22+deb8u1
ii  python-guestfs1:1.28.1-1
ii  qemu-system   1:2.1+dfsg-12+deb8u6
ii  qemu-user-static  1:2.1+dfsg-12+deb8u6
ii  squashfs-tools1:4.2+20130409-2

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  mbr   1.1.11-5+b1
ii  pandoc1.12.4.2~dfsg-1+b14
pn  u-boot:armhf  

-- no debconf information

Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

Thanks everyone for the feedback! I've been digging through this today.

On 04.01.2017 21:11, Stephen Kitt wrote:
> On Tue, 3 Jan 2017 09:06:21 -0500, Michael Gilbert 
> wrote:
>> On Tue, Jan 3, 2017 at 8:49 AM, Jens Reyer wrote:
>>> This meets my personal preference. What do others think?  
>>
>> In the long term, I think we'll end up needing to blacklist all
>> extensions with this approach.
>>
>> I'm ok with it as a temporary solution for stretch, but the ideal
>> approach would only create the files when the user explicitly tells
>> winemenubuilder to do it, rather than automatically during install,
>> upgrade, etc when the user hasn't asked for it.
> 
> I've come across http://askubuntu.com/questions/323437 which suggests a
> simpler solution: dropping the "-a" switch from the winemenubuilder.exe
> command-line in wine.inf. I haven't tried this out (yet) so I don't know if
> it affects file associations inside Wine.

I just tested this in a clean environment[1], but unfortunately it
doesn't work as required:

I created a fresh prefix and installed an application. This used to
cause the generation of the unwanted native associations, but didn't
happen now - good. And the Windows application still opened pdf's with
evince (native default for pdf).

But then I installed Foxit Reader and suddenly had the whole bunch of
native associations (pdf, htm, txt, ...).

I have verified in the code that the code which generates those is
indeed only called from "winemenubuilder -a"[2].
So it looks as if something calls "winemenubuilder -a" explicitly
(wine.inf probably only changes the default). Or is that a bug in Wine
(I'll ask upstream/file a bug)?




Then I tested to force this behavior, by making the -a switch a no-op[3]:

CAVEAT 1: This removes the option to run "winemenubuilder -a" manually
(or ignores the -a switch when doing so)! - Bad, but acceptable?

Besides that I think only the functions described in [2] are affected (=
not called), so I assume there are no side effects.

The unwanted native general purpose .desktop entries are not created.

Installing an app creates as usual its launchers on the desktop and some
specific ones in ~/.local/share/applications/wine/Programs.  Further
icons and menus/desktop-directories in ~/.local/share and ~/config.

The installed app correctly used evince for opening a pdf.

Installing Foxit Reader this time didn't generate all the unwanted
native associations (neither for pdf nor for anything else). Good.

The other app then used Foxit Reader for opening a pdf. But native apps
didn't. Good.

CAVEAT 2: Of course this also means that a file type association that is
not available natively, will still not be created if you install a
Windows applications which provides it. This would also be a problem if
changing wine.inf worked. - On the other side, many (me including) will
prefer this behavior, because they don't want Wine to touch their system
at all.

I will probably commit this tomorrow. We may add some information to the
README about this, and how to create an association manually.



Otherwise: I had missed to place the full list of extensions in my
previous patch. But basically I planned to blacklist nearly all
extensions for which Wine always creates associations (except a few ones
which seem to be Windows specific and don't have a native association
(on my system)).




[1]
Warning, this might also remove unrelated content:
rm -rf ~/.wine ~/.local/share/applications/
~/.local/share/desktop-directories/ ~/.local/share/icons/
~/.local/share/mime/ ~/.config/menus/applications-merged/


[2]
The function
 write_freedesktop_association_entry
and (not sure if it really affects my system)
 write_freedesktop_mime_type_entry
create the problematic entries.

They are *only* called from
 generate_associations
which is the only place where
 is_extension_blacklisted
(which I used in my previous patch) is used. generate_associations has
no other function.

generate_associations is *only* called from
 RefreshFileTypeAssociations (line 3332)
which is *only* called from
 wWinMain (line 3641)
and only if the "-a" switch is used.


[3]
+--- a/programs/winemenubuilder/winemenubuilder.c
 b/programs/winemenubuilder/winemenubuilder.c
+@@ -3638,7 +3638,6 @@ int PASCAL wWinMain (HINSTANCE hInstance
+   break;
+ if( !strcmpW( token, dash_aW ) )
+ {
+-RefreshFileTypeAssociations();
+ continue;
+ }
+ if( !strcmpW( token, dash_rW ) )

Bug#850206: debootstrap output not available

[Antoine Beaupré]

Package: vmdebootstrap
Version: 1.7-1
Severity: minor

In newer vmdeboostrap versions, I am not sure since when, debootstrap
output is hidden from view when launched. This makes it frustratingly
hard to figure out what is going on when an image is built.

For example, while building a stretch image here, I got this:

Creating disk image
Creating partitions
Creating filesystem ext4
Mounting /dev/mapper/loop2p1 on /tmp/tmpo5F5FJ
Debootstrapping stretch [amd64]
[...]

The "[...]" happened to hang because of a custom package I added to
the build, but I had no way to tell. It's only after 10+ minutes that
I started to wonder if something was wrong, and I had to dig through
piles of ps axfwu, strace -p and lsof -p to try and understand what
was happening.

It would be nice if the output was logged somewhere. I expected it to
be on stderr or somewhere visible, or at least in the logfile (which I
enabled with --log and --log-level debug).

-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (1, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.7.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages vmdebootstrap depends on:
ii  debootstrap 1.0.67
ii  kpartx  0.5.0-6+deb8u2
ii  libjs-sphinxdoc 1.4.6-1~bpo8+1
ii  parted  3.2-7
ii  python-cliapp   1.20150829-1~bpo8+1
ii  python-distro-info  0.14
ii  python2.7   2.7.9-2+deb8u1
pn  python:any  
ii  qemu-utils  1:2.1+dfsg-12+deb8u6

Versions of packages vmdebootstrap recommends:
ii  dosfstools3.0.27-1
ii  extlinux  3:6.03+dfsg-5+deb8u1
ii  grub2-common  2.02~beta2-22+deb8u1
ii  python-guestfs1:1.28.1-1
ii  qemu-system   1:2.1+dfsg-12+deb8u6
ii  qemu-user-static  1:2.1+dfsg-12+deb8u6
ii  squashfs-tools1:4.2+20130409-2

Versions of packages vmdebootstrap suggests:
pn  cmdtest   
ii  mbr   1.1.11-5+b1
ii  pandoc1.12.4.2~dfsg-1+b14
pn  u-boot:armhf  

-- no debconf information

Bug#833037: [PKG-Openstack-devel] Bug#833037: Bug#833037: python-factory-boy: missing depends on ipaddress

[Brian May]

Brian May  writes:

> Not sure if I can git push to the openstack git repository, so I haven't
> done so (and I might have to redo it anyway). If I can get this working,
> I might move it to DPMT.

Ok, just building and uploading.

Note that this isn't going to really help, there are 2 RC bugs against
faker, which this package depends on.
-- 
Brian May 

Bug#850207: flightgear: Fresh install of 2016.4.3 does not work with dependent packages

[Daren Beattie]

Package: flightgear
Version: 1:2016.4.3+dfsg-2
Severity: important

Dear Maintainer,

I installed a fresh copy of flightgear a day or two ago, along with its 
dependencies. The version on the main flightgear package is 2016.4.3, but all 
dependencies are version 2016.4.2. The flightgear startup dialog asked for the 
path to the data files. After a bit of googling and checking my system, I 
pointed it to /usr/share/games/flightgear. The dialog then complained "The 
chosen location (/usr/share/games/flightgear) contains files for version 
2016.4.2, but this is FlightGear 2016.4.3. Please update or try another 
location".
I have not tried downloading a copy of the 2016.4.3 data from upstream. 
Presumably that would work, but I would prefer that the flightgear package 
dependencies be as strict as the game itself is, so that the installed game 
works as-is.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-1-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)

Versions of packages flightgear depends on:
ii  flightgear-data-all   1:2016.4.2+dfsg-1
ii  freeglut3 2.8.1-3
ii  libc6 2.24-8
ii  libcurl3-gnutls   7.51.0-1
ii  libdbus-1-3   1.10.14-1
ii  libexpat1 2.2.0-1
ii  libflite1 2.0.0-release-3
ii  libgcc1   1:6.2.1-5
ii  libgl1-mesa-glx [libgl1]  13.0.2-3
ii  libglu1-mesa [libglu1]9.0.0-2.1
ii  libgsm1   1.0.13-4
ii  libhtsengine1 1.08-1
ii  libice6   2:1.0.9-1+b1
ii  libopenal11:1.17.2-4
ii  libopenscenegraph100v53.2.3+dfsg1-2+b2
ii  libopenthreads20  3.2.3+dfsg1-2+b2
ii  libplib1  1.8.5-7
ii  libpng16-16   1.6.26-6
ii  libqt5core5a  5.7.1+dfsg-1
ii  libqt5gui55.7.1+dfsg-1
ii  libqt5widgets55.7.1+dfsg-1
ii  libsm62:1.2.2-1+b1
ii  libspeex1 1.2~rc1.2-1
ii  libspeexdsp1  1.2~rc1.2-1
ii  libsqlite3-0  3.15.2-2
ii  libstdc++66.2.1-5
ii  libudev1  232-8
ii  libudns0  0.4-1
ii  libx11-6  2:1.6.4-2
ii  libxext6  2:1.3.3-1
ii  libxi62:1.7.8-1
ii  libxmu6   2:1.1.2-2
ii  zlib1g1:1.2.8.dfsg-4

Versions of packages flightgear recommends:
ii  flightgear-phi  2016.4.2+dfsg1-1

flightgear suggests no packages.

-- no debconf information

Bug#845334: [pkg-wine-party] Bug#845334: Bug#845334: wine32: breaks xdg-open, which wants to start wine and crashes

[Jens Reyer]

On 05.01.2017 02:03, Jens Reyer wrote:
> I will probably commit this tomorrow. We may add some information to the
> README about this, and how to create an association manually.

Alternatively we may change wine.inf (drop "-a") which should help
normally (?) to prevent native associations, *and* do the blacklisting
for file types so that if this is still triggered by e.g. installing
Foxit Reader at least not too many associations are created.

This way anybody preferring the old behavior could just manually run
"winemenubuilder -a" to create all not-blacklisted associations.

I'd blacklist all extensions for which Wine always creates associations,
presumably:
pdf
rtf
xml
gif
jfif
jpe
jpeg
png
htm
html
txt
url
wri - application/x-mswrite=libreoffice-writer.desktop
msp - Microsoft Paint Image (in Windows 2.0), or
  application/mspowerpoint=libreoffice-impress.desktop
vbs - Visual Basic Script
vbs - Visual Basic Script
ini - open with notepad or with native editor?


Except maybe these:
chm - Compiled HTML Help is the standard help system for Windows.
hlp - Microsoft Windows Help file.

Bug#850208: Missing category in Netsurfs desktop file

[Joerg Schiermeier, Bielefeld/Germany]

Package: netsurf-gtk
Version: 3.2+dfsg-2+b1
Severity: normal

Hello!

Netsurfs desktop file "netsurf-gtk.desktop" is missing one category which evry 
browsers desktop file has: WebBroser.
To illustrate this I copy an example from actual package 
"netsurf-gtk_3.6-3_amd64.deb" into this report.

>From "netsurf-gtk.desktop", please look at this:
Icon=netsurf.png
Categories=Network;
^^
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;image/gif;image/jpeg;image/png

The categories should be like:
Categories=Network;WebBrowser;

Thanks for your attention!

-- 

Kindly regards
Joerg Schiermeier
Bielefeld/Germany




-- System Information:
LSB Version:
core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: SolydXK
Description:SolydK 8 64-bit
Release:8
Codename:   solydxk
Architecture: x86_64

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages netsurf-gtk depends on:
ii  libc62.23-4
ii  libcairo21.14.0-2.1+deb8u1
ii  libcurl3 7.38.0-4+deb8u5
ii  libexpat12.1.0-6+deb8u3
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libjpeg62-turbo  1:1.3.1-12
ii  libmozjs185-1.0  1.8.5-1.0.0+dfsg-4.3
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpng12-0   1.2.50-2+deb8u2
ii  librsvg2-2   2.40.5-1+deb8u2
ii  libssl1.0.0  1.0.1t-1+deb8u5
ii  netsurf-common   3.2+dfsg-2
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages netsurf-gtk recommends:
ii  mime-support  3.58

netsurf-gtk suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/applications/netsurf-gtk.desktop (from 
netsurf-gtk package)

Bug#738897: RM libsigc++-1.2

[Scott Kitterman]

>At this point it's probably safe to assume that freqtweak won't be
>fixed.
>
>The package is orphaned [1] and dead upstream (last upstream activity
>is
>over 7 years ago [2]).
>Please remove it along with libsigc++-1.2.

Please file a separate rm bug for it.

Scott K

Bug#692754: how to get the username in the plugin?

[Ron]

On Thu, Jan 05, 2017 at 08:34:04AM +1100, martin f krafft wrote:
> also sprach Johannes Berg  [2017-01-05 01:11 
> +1100]:
> > I'm not even sure how to get the username? Is it even generally
> > possible, if e.g. the plugin is running out of a process that's not
> > invoked through the imapd?
> 
> Well, the plugin certainly does seem to be run as the target user,
> or else how could it be used for user-specific training?

There's probably a lot of things we _could_ do ...

In the most general case getpwuid_r(geteuid(),...) should tell us who we
are running as, no matter how we are run - but that has potential icky,
since getting that name could involve a network access to LDAP or worse.

I'm not sure offhand if dovecot already (reliably) exposes it to us in
the environment we get from it - docs on that didn't pop out at me ...

Or worst case, we could make one, and let people do something like:

 antispam_log_prefix = %u

in their config, since dovecot will expand the %u for us ...
That has the advantage of letting them customise it if they have some
really crazy setup with multiple dovecot instances all logging to the
same place ...


But all of this kind of sets my XY problem overkill alarm off in a
variety of ways, so I think we ought to actually start at the top:

Martin, what _actual_ problem did you have to make you want this?
That might be something we can (also?) fix better and simpler?

  Ron

Bug#850209: Recommends needed to be re-thinked

[Alf Gaida]

Package: lxqt
Version: 9
Severity: normal

Recommends: cmst, connman | network-manager is not the best of all ideas,
especially if connman and cmst don't make it into stable. Second cmst depends
on connman - so the connman dependency is super-fluous. Same for
network-manager - networkmanager-gnome depends on network-manager, so 
cmst | network-manager-gnome | ifupdown is much cleaner.

 In case connman shouldn't make it into stretch it should be:

Recommends: network-manager-gnome | cmst | ifupdown, ...

in case connman goes in it should be:

Recommends: cmst | network-manager-gnome | ifupdown, ...

Sounds like a crazy idea at first glance, but the nm-applet and and the config
editor just work fine with LXQt and esp. lxqt-panel. 

-- System Information:
Debian Release: stretch/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-towo.2-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt depends on:
ii  lxqt-about0.11.1-1
ii  lxqt-admin0.11.1-1
ii  lxqt-config   0.11.1-1
ii  lxqt-core 9
ii  lxqt-globalkeys   0.11.1-1
ii  lxqt-notificationd0.11.1-1
ii  lxqt-openssh-askpass  0.11.1-1
ii  lxqt-policykit0.11.1-1
ii  lxqt-powermanagement  0.11.1-1
ii  lxqt-qtplugin 0.11.2~1-g63da0ff-2
ii  lxqt-runner   0.11.1-1

Versions of packages lxqt recommends:
ii  audacious   3.7.2-2
ii  cmst2016.10.03-20-g390231f-4
ii  connman 1.34~692-gf07aea37-2
ii  firefox [www-browser]   50.1.0-1
ii  gksu2.0.2-9
ii  google-chrome-stable [www-browser]  54.0.2840.59-1
ii  gucharmap   1:9.0.2-1
ii  links [www-browser] 2.14-1
ii  lximage-qt  0.5.1-1
ii  lxqt-sudo   0.11.1-1
ii  pavucontrol-qt  0.2.1~1-gd188fa9-1
ii  qlipper 1:5.0.1~13-g14bfc66-1
ii  qpdfview0.4.15-1
ii  qps 1.10.16-29-g7e679db-2
ii  qterminal   0.7.1-2
ii  sddm [x-display-manager]0.14.1~25-g38ce346-1
ii  smplayer16.11.0~ds0-1
ii  smtube  15.5.10-1
ii  xarchiver   1:0.5.4-6

Versions of packages lxqt suggests:
pn  calibre 
ii  claws-mail  3.14.1-2
pn  compton 
pn  compton-conf
ii  juffed  0.10-85-g5ba17f9-10
ii  nomacs  3.4.1-38-g60c8281-1
pn  obconf-qt   
pn  openbox 
pn  qtpass  
pn  quassel | quassel-client | hexchat  
ii  screengrab  1.96-1
ii  vokoscreen  2.5.2~9-gd9b9b33-1
ii  zim 0.65-4

-- no debconf information

Bug#850210: RM: freqtweak -- RoQA; unmaintained, RC buggy, dead upstream

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

Please remove the freqtweak package. It is orphaned (#846810), upstream
is not active anymore and it blocks the removal of libsigc++-1.2 See
#672390 and #738897 for further details.

Thanks,
Michael

Bug#692754: how to get the username in the plugin?

[Ron]

On Thu, Jan 05, 2017 at 12:47:07PM +1030, Ron wrote:
> On Thu, Jan 05, 2017 at 08:34:04AM +1100, martin f krafft wrote:
> > also sprach Johannes Berg  [2017-01-05 01:11 
> > +1100]:
> > > I'm not even sure how to get the username? Is it even generally
> > > possible, if e.g. the plugin is running out of a process that's not
> > > invoked through the imapd?
> > 
> > Well, the plugin certainly does seem to be run as the target user,
> > or else how could it be used for user-specific training?
> 
> There's probably a lot of things we _could_ do ...
> 
> In the most general case getpwuid_r(geteuid(),...) should tell us who we
> are running as, no matter how we are run - but that has potential icky,
> since getting that name could involve a network access to LDAP or worse.
> 
> I'm not sure offhand if dovecot already (reliably) exposes it to us in
> the environment we get from it - docs on that didn't pop out at me ...
> 
> Or worst case, we could make one, and let people do something like:
> 
>  antispam_log_prefix = %u
> 
> in their config, since dovecot will expand the %u for us ...
> That has the advantage of letting them customise it if they have some
> really crazy setup with multiple dovecot instances all logging to the
> same place ...
> 
> 
> But all of this kind of sets my XY problem overkill alarm off in a
> variety of ways, so I think we ought to actually start at the top:
> 
> Martin, what _actual_ problem did you have to make you want this?
> That might be something we can (also?) fix better and simpler?

Just to be clear, there's a lot of permutations here about what
backend might be run (and you didn't say which you are using),
and usually the only case where the user might actually matter,
we're passing that user to an external program (and don't have
any control over what it outputs) ...

So in most of what -antispam might log, any failure isn't going
to be due to something "user specific" - which means it would be
good to know exactly what problem you hit that (you thought?) was.

Otherwise, this could just turn into lots of intrusive busywork
that doesn't actually solve it, if we don't know what "it" was.

  Ron

Bug#849918: RFS: tinymux/2.10.1.13-1

[Stephen Dennis]

Thanks for the starting point. I had worked out the d/watch file enough
that it works locally (mentors.debian.net still complains), but I like your
wildcards better, so I'm using that one (mentors.debian.net still
complains). The simple short d/rules is very much appreciated. I only just
begin to discover the override_* stuff before you sent it. You saved me two
days there. That and writing d/install and d/clean exposed some
embarrassing stray symbolic links. I actually prefer enumerating the exact
placement of all the files. So, what remains:

 - I think the fortify complaint about slave and stubslave is probably
because they are so minimal. I don't think they use any libc functions
actually.
 - There's no obvious override for the duplicate changelog warning.
 - Revisit d/changelog to make sure the package changes are fully captured.
 - It would be nice to get make -j2 working. They did work once upon a
time. Might be better to fix that upstream.
 - Test. The prettiest package in the world doesn't necessarily install
anything that works.

On Wed, Jan 4, 2017 at 4:32 PM, Tobias Frost  wrote:

> Am Donnerstag, den 05.01.2017, 00:24 +0100 schrieb Tobias Frost:
> >
> > I wrote you a rule file as starting point. Attached. It is thought to
> > get you started.
> > (Some parts are missing, like the hardening; also stuff and you need
> > to
> > do outside of the rules, like to create the file d/clean with all
> > files
> > listed and d/install to to put the files actually in place
> >
> PS: I needed to add --no-parallel because parallel build is broken
> here. This is also bug in your Makefile...
>
> To trigger
> #debuild -j1
> (works)
>
> #debuild -j4
> (...)
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o stubslave stubslave.o -L.
> -lm -lcrypt   -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:189: recipe for target 'stubslave' failed
> make[1]: *** [stubslave] Error 1
> make[1]: *** Waiting for unfinished jobs
> ( if [ -f netmux ]; then mv -f netmux netmux~ ; fi )
> g++ -g -O2 -fdebug-prefix-
> map=/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13=. -fstack-
> protector-strong -Wformat -Werror=format-security -Wall -O3 -fomit-
> frame-pointer -Wdate-time -D_FORTIFY_SOURCE=2 -g -O -
> DSTUB_SLAVE   -Wl,-z,relro -Wl,-z,now -o netmux _build.o alarm.o
> alloc.o attrcache.o boolexp.o bsd.o command.o comsys.o conf.o cque.o
> create.o db.o db_rw.o eval.o file_c.o flags.o funceval.o funceval2.o
> functions.o funmath.o game.o help.o htab.o local.o log.o look.o mail.o
> match.o mathutil.o mguests.o modules.o move.o muxcli.o netcommon.o
> object.o predicates.o player.o player_c.o plusemail.o powers.o quota.o
> rob.o pcre.o set.o sha1.o speech.o stringutil.o strtod.o svdrand.o
> svdhash.o timer.o timeabsolute.o timedelta.o timeparser.o timeutil.o
> timezone.o unparse.o utf8tables.o vattr.o walkdb.o wild.o
> wiz.o  version.o -L. -lm -lcrypt -lmux
> /usr/bin/ld: cannot find -lmux
> collect2: error: ld returned 1 exit status
> Makefile:198: recipe for target 'netmux' failed
> make[1]: *** [netmux] Error 1
> make[1]: Leaving directory
> '/home/tobi/workspace/deb/mentors/Jan03/tinymux-2.10.1.13/src'
>

Bug#850211: open-iscsi: Boot with systemd hangs for iSCSI+LUKS+LVM volume

[Abhijit Menon-Sen]

Package: open-iscsi
Version: 2.0.874-1~bpo8+1
Severity: normal

Dear Maintainer,

I have a NAS that exports an iSCSI target. I have created a LUKS volume
on a partition on this target, used that volume as a PV, and created an
LVM VG/LV on top of it. On boot, systemd waits for 90s for the iSCSI
device and its subsidiary devices to appear before bringing up the
network. This is similar to bug #775778.

I am not sure that this is a bug in open-iscsi, but I'm filing it here
on the basis of the strong similarity with #775778. (I'm running jessie
with updates from jessie-backports, so I have the patches from that bug
already.)

This is how I setup my volume:

# The iSCSI part works fine.
iscsiadm … --login

# Device shows up as /dev/sdb; I create a /dev/sdb1 partition using
# fdisk, of type 8e.

# Create encrypted LUKS volume on /dev/sdb1, open and map as
# /dev/mapper/sdb1_crypt.
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 sdb1_crypt \
--key-file /root/blackbird-ullu

# Set up LVM PV, VG, and LV mapped to /dev/mapper/blackbird-ullu,
# with an ext4 filesystem on top.
pvcreate /dev/mapper/sdb1_crypt
vgcreate blackbird /dev/mapper/sdb1_crypt
lvcreate -n ullu -l 100%VG blackbird
mkfs.ext4 /dev/mapper/blackbird-ullu

mount /dev/mapper/blackbird-ullu /media/nas

I have an entry in /etc/crypttab like this:

sdb1_crypt UUID=ae6b9263-d63c-4515-b7ce-51e5cc4caa9f /root/blackbird-ullu 
luks

And an entry in /etc/fstab like this (I've tried various variants here,
see below):

/dev/mapper/blackbird-ullu /media/nas ext4 defaults,nofail,_netdev 0 6

There are three devices involved:

- /dev/disk/by-uuid/: is the iSCSI target (/dev/sdb)
- /dev/mapper/sdb1_crypt: result of cryptsetup luksOpen /dev/sdb1 
- /dev/mapper/blackbird-ullu: LV built on top of sdb1_crypt

Now I suffer from the 90s wait on startup (before network-online), where
systemd waits for the dev-mapper-blackbird\x2dullu.device to become
available, along with dev-disk-by\x2duuid-.device and
dev-mapper-sdb1_crypt.device.

After the timeout, the boot proceeds, brings up the network, starts
iscsid, and runs /lib/open-iscsi/activate-storage.sh once /dev/sdb is
available, but the "vgchange -aay" command fails because the PV is not
yet mapped with cryptsetup:

activate-storage.sh[2618]:   Volume group "blackbird" not found
activate-storage.sh[2618]:   Skipping volume group blackbird
activate-storage.sh[2618]: Warning: could not activate all LVM groups.

This is the first time I have used iSCSI or systemd, so my attempts to
resolve this are pretty amateurish, but here's an overview:

(a) I shortened the 90s timeout for all three devices by creating
drop-in overrides for the corresponding .device units under
/etc/systemd/system:


dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device.d/nowait.conf
dev-mapper-sdb1_crypt.device.d/nowait.conf
dev-mapper-blackbird\x2dullu.device.d/nowait.conf

[Unit]
JobTimeoutSec=1

(I later removed the third file and instead added the
x-systemd.device-timeout=1s mount flag in /etc/fstab for the
/dev/mapper/blackbird-ullu volume, but this is functionally equivalent
to the above.)

After this, the boot proceeded with only a 1s wait, with messages like this:

systemd[1]: dev-mapper-sdb1_crypt.device: Job 
dev-mapper-sdb1_crypt.device/start timed out.
systemd[1]: Timed out waiting for device dev-mapper-sdb1_crypt.device.
systemd[1]: Dependency failed for Cryptography Setup for sdb1_crypt.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with 
result 'dependency'.
systemd[1]: systemd-cryptsetup@sdb1_crypt.service: Job 
systemd-cryptsetup@sdb1_crypt.service/start failed with result 'dependency'.
systemd[1]: dev-mapper-sdb1_crypt.device: Job 
dev-mapper-sdb1_crypt.device/start failed with result 'timeout'.
systemd[1]: 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device: 
Job dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa
systemd[1]: Timed out waiting for device 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device.
systemd[1]: 
dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa9f.device: 
Job dev-disk-by\x2duuid-ae6b9263\x2dd63c\x2d4515\x2db7ce\x2d51e5cc4caa
systemd[1]: dev-mapper-blackbird\x2dullu.device: Job 
dev-mapper-blackbird\x2dullu.device/start timed out.
systemd[1]: Timed out waiting for device 
dev-mapper-blackbird\x2dullu.device.
systemd[1]: Dependency failed for /media/nas.
systemd[1]: media-nas.mount: Job media-nas.mount/start failed with result 
'dependency'.
systemd[1]: Dependency failed for File System Check on 
/dev/mapper/blackbird-ullu.
systemd[1]: systemd-fsck@dev-mapper-blackbird\x2dullu.service: Job 
systemd-fsck@dev-mapper-blackbird\x2dullu.service/st

Bug#847570: linux-image-4.9.0-rc8-amd64-unsigned: AMDGPU not build with support for GCN1.0 and GCN1.1 VGAs

[Ben Hutchings]

On Fri, 2016-12-09 at 16:06 +0100, Ferdinand Pöll wrote:
> Package: linux-image-4.9.0-rc8-amd64-unsigned
> Version: 4.9~rc8-1~exp1
> Severity: wishlist
> Tags: patch
> 
> Dear Maintainer,
> 
> I have an AMD Radeon R9 270X and I'd like to use the new amdgpu driver with 
> it.
> Since 4.9, linux includes experimental support for GCN 1.0 VGAs, but it's not
> enabled in the debian builds as well as the support for GCN 1.1 cards (which
> isn't new in the kernel anymore). In the kernel build config, you just need to
> set CONFIG_DRM_AMDGPU_SI=Y (for GCN1.0-based cards) and 
> CONFIG_DRM_AMDGPU_CIK=Y
> (for GCN1.1-based cards). To use amdgpu if it is built into the kernel with 
> the
> old gpus users just need to blacklist radeon and upon the next reboot linux
> will load amdgpu and users can install amdgpu-pro if they want to or just 
> stick
> with the newest free graphics driver.

I don't think this will work the way you expect.  kmod will load both
modules unless one of them is blacklisted, and it's not documented
which one will be tried first.  So we could end up loading amdgpu on
systems that should still be using radeon by default.

We could perhaps patch amdgpu so that it isn't auto-loaded for the GCN
1.0 GPUs.  But I'm not yet convinced this is worth doing.

Ben.

> The kernel in my system info below is built from source with the options
> mentioned above enabled.


-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



signature.asc
Description: This is a digitally signed message part

Bug#850212: lxc: lxc init script should depend on cgroupfs-mount

[Benda Xu]

Package: lxc
Version: 1:2.0.6-1~bpo8+1
Severity: important

Dear Maintainer,

lxc requires cgroupfs to be properly mounted.  This task is either done by
cgroupfs-mount init script or systemd.  The former does nothing if started
by systemd:

  # Test for systemd and bail (we have to test before sourcing init-functions, 
or systemd hijacks us)
  # We bail because systemd already mounts cgroups sanely, so we just silently 
pretend we were successful in mounting them here
  if [ -d /run/systemd/system ]; then
  exit 0
  fi

Therefore adding cgroupfs-mount to the service dependency of lxc fix startup
issue on non-systemd systems.

  ### BEGIN INIT INFO
  # Provides: lxc
  # Required-Start: $syslog $remote_fs cgroupfs-mount
  # Required-Stop: $syslog $remote_fs cgroupfs-mount

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lxc depends on:
ii  init-system-helpers  1.29
ii  libapparmor1 2.9.0-3
ii  libc62.24-4
ii  libcap2  1:2.24-8
ii  liblxc1  1:2.0.6-1~bpo8+1
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  lsb-base 4.1+Debian13+nmu1
ii  python3-lxc  1:2.0.6-1~bpo8+1
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
ii  debootstrap   1.0.67
ii  dirmngr   2.1.16-3
ii  dnsmasq-base  2.72-3+deb8u1
ii  gnupg 2.1.16-3
ii  iptables  1.4.21-2+b1
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.0.1t-1+deb8u5
ii  rsync 3.1.1-3
pn  uidmap

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-tools  4.7.3-1~bpo8+1
ii  lvm2 2.02.111-2.2+deb8u1

-- Configuration Files:
/etc/apparmor.d/lxc/lxc-default [Errno 2] No such file or directory: 
u'/etc/apparmor.d/lxc/lxc-default'
/etc/apparmor.d/lxc/lxc-default-with-mounting [Errno 2] No such file or 
directory: u'/etc/apparmor.d/lxc/lxc-default-with-mounting'
/etc/init.d/lxc changed:
log_daemon_msg () {
echo $@
}
test ! -r /lib/lsb/init-functions ||
. /lib/lsb/init-functions
start() {
# Setup host /dev for autodev containers.
log_daemon_msg "Starting LXC autoboot containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers start
}
stop() {
log_daemon_msg "Stopping LXC containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers stop
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload|force-reload)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart|reload|force-reload}"
exit 2
;;
esac
exit $?

/etc/lxc/default.conf [Errno 2] No such file or directory: 
u'/etc/lxc/default.conf'

-- no debconf information
diff --git a/init.d/lxc b/init.d/lxc
index 1205d8c..e2e620a 100755
--- a/init.d/lxc
+++ b/init.d/lxc
@@ -7,8 +7,8 @@
 #
 ### BEGIN INIT INFO
 # Provides: lxc
-# Required-Start: $syslog $remote_fs
-# Required-Stop: $syslog $remote_fs
+# Required-Start: $syslog $remote_fs cgroupfs-mount
+# Required-Stop: $syslog $remote_fs cgroupfs-mount
 # Should-Start:
 # Should-Stop:
 # Default-Start: 2 3 4 5

Bug#845422: [PATCH] Please add BCM2835 MMC driver for Raspberry Pi 3

[Ben Hutchings]

Control: tag -1 upstream

On Wed, 2016-11-23 at 09:43 +0100, Michael Stapelberg wrote:
[...]
> However, when trying to boot linux-image-4.8.0-1-arm64 version 4.8.5-1, I
> noticed that the kernel can’t find any block devices (and hence no root file
> system). This is because the bcm2835-sdhost MMC driver has not actually made 
> it
> into Linux 4.8; it is still under review:
> https://www.spinics.net/lists/arm-kernel/msg513433.html
[...]

As this is still the case, we won't add the driver yet.  Please let us
know when it is accepted upstream, and we can consider backporting that
version for stretch.

Besides which, we already enable the sdhci-iproc driver which should
also work on the RPi 3.

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



signature.asc
Description: This is a digitally signed message part

Bug#845075: kernel-image-4.8.0-1-armmp-di: Lamobo R1 cannot access network

[Ben Hutchings]

Control: tag -1 moreinfo

On Sun, 2016-11-20 at 09:20 +0100, Heinrich Schuchardt wrote:
> Package: kernel-image-4.8.0-1-armmp-di
> Version: 4.8.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> I want to install Debian Stretch on my Lamobo R1 using the network
> installer.
> 
> It is unable to connect to the DHCP server.
> 
> Please, add the b53 module to the kernel.
> 
> CONFIG_B53=y
> CONFIG_B53_SPI_DRIVER=y

I think we already enabled the necessary options:

  * [armhf] dsa: Enable drivers for Lamobo R1 (aka BPi-R1): B53,
B53_MDIO_DRIVER as modules (Closes: #836231, thanks to Vagrant Cascadian)

From the device tree, it seems pretty clear that we do want
B53_MDIO_DRIVER and not B53_SPI_DRIVER.  Are you sure the installer
version you used had a verison 4.8 kernel, not 4.7?

Ben.

-- 
Ben Hutchings
In a hierarchy, every employee tends to rise to his level of
incompetence.



signature.asc
Description: This is a digitally signed message part

Bug#850157: Please deprecate all ad-hoc patch systems

[Stuart Prescott]

>   Running dpkg-source -x on a source package MUST produce the source
>   of the package, ready for editing, and allow one to make changes,

The "ready for editing" language is a bit too sloppy for Policy. Ultimately 
all packages are 'ready for editing' once unpacked, it's just that you might 
be surprised by what you have to edit. 

Does 'ready for editing' mean it has to be patches-applied when unpacked? 
Does that accidentally forbid tarball-within-tarball packages? (Do we have 
any of them still or have they finally all disappeared?) 

>   and run dpkg-buildpackage to produce a modified package, without
>   taking any additional steps.

"run dpkg-buildpackage to produce a modified package" is also too loose. 
Does that mean source package or binary package? If it means binary package, 
then almost every package is non-compliant with that as a local change would 
cause dpkg-buildpackage to fail with:

dpkg-source: info: local changes detected

... of the 3.0 (quilt) source format packages, the only compliant ones would 
have "auto-commit" in debian/source/options of which there are a total of 5 
in the archive.


>>   Previously, packages which had ad-hoc patch systems would document
>>   their source code management practices in debian/README.source.
>>   Source packages now MUST NOT use in-source-package patch systems
>>   other than `3.0 (quilt)'.
> 
> How many packages in the archive would we make buggy by adding this
> requirement?  

A starting point would be "every package that build-depends on quilt or 
dpatch" of which there are 868.¹ There are 155 packages that are using some 
other patch system such as provided by CDBS.²

Since the 'patch' package is within the build-essential set, it's not easy 
to know what packages are using patch(1). There are 1159 packages that talk 
about patching things in debian/rules³ some of which are build-time commands 
and some of which are only helpers for the maintainer or comments. There are 
quite a few cases where arch-specific patches exist -- 3.0 (quilt) doesn't 
provide for arch-specific patches. I'm assuming that the proposal is not to 
drop all archs that need arch-specific patches ;) There are also build-
stage-specific patches for bootstrapping.

There are also plenty of packages that do a little sed magic in d/rules to 
alter some source prior to building. Sometimes that could be expressed as a 
patch but that patch can be very fragile (needing to be re-made on every 
single new upstream release) while the sed is not. Fiddling thing with sed 
sounds a lot like an ad hoc patch system to me and is certainly not 
something that should be forbidden.

There are a lot of packages in these lists that are maintained by 
experienced maintainers who selected these approaches for sensible technical 
reasons. Some (like simple-patchsys.mk) are relics but most are not. I think 
we're a long way from a "MUST NOT" on this sort of thing. Given the way 
packages like gcc-*, pythonX.Y and linux are operating (and many others 
besides) are operating, there needs to be an alternative that the 
maintainers consider viable first, and then a migration to that alternative.

A couple of additional points:

* Deprecating patch systems should also deprecate the 'patch' target in 
debian/rules from §4.9.

* There are still other useful roles for d/README.source documented within 
policy and in associated documents; the python modules team refer to 
README.source as the place to document that a package is not using their 
standardised tool (git-dpm) and why, for instance.

cheers
Stuart


¹ build-rdeps quilt = 760; build-rdeps dpatch = 108
² https://lintian.debian.org/tags/debian-rules-uses-deprecated-makefile.html
³ https://codesearch.debian.net/search?q=path%3Adebian%2Frules+patch


-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#818926: perl6-panda: panda doesn't start up / find needed libraries

[gregor herrmann]

On Wed, 04 Jan 2017 08:22:46 +0100, Dominique Dumont wrote:

> > I'm just reading 
> > http://blogs.perl.org/users/steve_mynott/2017/01/rakudo-star-past-present-and-future.html
> > which mentions that Rakudo Star is moving from panda to zef.
> Thanks for the link. I'm currently trying to figure out what can be done with 
> zef:
> https://github.com/ugexe/zef/issues/117

Interesting, thanks.
 
> As for perl6-panda, I guess this package should be completely removed from 
> Debian.

Yeah, probably.
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Kante: Im ersten Licht


signature.asc
Description: Digital Signature