Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Wed, Oct 5, 2016 at 12:04 AM, Pa irate Praveen 
wrote:

> On 2016, ഒക്‌ടോബർ 4 7:49:28 PM IST, Sam Hartman 
> wrote:
>


> >You're asking questions that don't make sense from a p.process
> >standpoint, doing things that have a very low probability of making
> >anyone happy,
>
> A quick update, I have asked ftp masters to make a ruling on the issue.
> #839801.
>

I saw that.  I look forward to any response they (or others) care to make
concerning that bug.

FWIW, I for one was under the impression (in part based on what you
originally wrote when you opened this bug, and looking at the bugs you
referenced in that message) that there had already been a decision by them
to declare browserified Javascript as failing to be DFSG-free on the
grounds of failing source code availability (because grunt is not currently
available in the Debian main archive).  If this was not the case, then I'll
agree with others it's important you get an explicit ruling from them one
way or another, so that if the ruling goes against you you can go to the TC
and say "This is what was decided, and this is why I disagree", and you
actually *have* something to point to in terms of what was decided!

Based on what Mr. Hartman has written, I would encourage you to explain for
everyone involved just exactly what you mean by "browserified Javascript",
what sort of processes and transformations are included by that term and
what are not.  Try to be as specific and precise as possible, not just
handwavy.  I've seen some stuff that makes it sound like it's merely
concatenation of files, but then I've seen other stuff that makes it sound
like it's *not* just that.  So I'm confused.  Remember, the people on the
TC are generally technically adept, but they're *not* specialists in
Javascript as you apparently are!  You need to teach them some stuff, so
they can make an educated and informed decision.

I would also suggest you explain exactly how the issue raised in bugs
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830986 and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830987 (the bugs related
to the generated lexer/parser code issue) relate to the concept of
browserified Javascript in general?  Is part of what's described in these
bugs routinely considered to be part of what it means to browserify
Javascript, so that if browserified Javascript is (temporarily) declared to
not be RC-buggy for Stretch, that means this stuff is not RC-buggy for
Stretch?  Or, is what's described by these bugs entirely separate and apart
from the process of browserification, such that even if browserification is
not RC-buggy for the moment, software with these bugs is still RC-buggy and
needs to have the bug resolved or else have the software go to the non-free
archive?





> I feel these responses make TC more like a bureaucracy, where focus is
> given on process and having people to go around asking many people.
>

>From what I understand of Mr. Hartman, he is particularly interested in
process.

But, for your purposes, that is not a *bad* thing!  He's not necessarily
interested in simply denying your request (tho, he *is* interested in
making sure your request is seen by him only after the people who should
see and decide on your request first have had a chance to do so).

That doesn't mean he'll necessarily agree with your position.  But, I think
it's important to him that you get a fair hearing and be treated as fairly
as possible.

It's important however for *you*, if you are to get what you want (which as
far as I can tell is a temporary variance for the duration of Stretch for
browserified Javascript files from being considered RC-buggy while you work
to package grunt for Stretch+1), to explain *why* this variance should be
granted.  And what you're going to do to permanently resolved this issue
for Stretch+1, so it doesn't come up again as a problem.  You have to
convince the TC to take your side; it's not enough for you to say "Well,
you should do what I want because ... Just because."

I'm sorry if you feel like this is a bureaucracy.  For what it's worth, I
think people are just trying to make sure they're doing what's right or
what's best, not just what's convenient or expedient at the moment.



Hope this is of some use, interest.  Thanks for your time.



Joseph

Bug#831873: xrdp created dir ${HOME}/.thinclient_drives which has permissions 000 belongs to root

[Andreas Tille]

Hi Dominik,

On Mon, Oct 03, 2016 at 07:29:07PM +0200, Dominik George wrote:
> did you find any way to reproduce the issue?
> 
> Did you check whether it might have something to do with pam_mount?

No, just back from vacation, no chance to test for the next week.
 
> Did any of the GNOME maintainers reply and maybe have some idea?

Not that I'm aware of but I have some mail backlog.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

Hi,

On Wed, Oct 5, 2016 at 9:23 PM, Lennart Sorensen
 wrote:
> On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
>> Will do ASAP. For reference:
>>
>> https://bugs.debian.org/825840#92
>>
>> and
>>
>> devalias tells me that  'screen' points to
>> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'
>
> Not sure how that maps to the dev syntax I found.
>
> I guess you would want '22 set-mode' for 1680x1050 then.
>
> Of course based on that alias, maybe it would work to just do:
>
> dev screen
> 22 set-mode
> 32 set-depth
> boot

That's precisely what I tried yesterday.

Anytime I press 'Enter' after '22 set-mode' or '32 set-depth' I loose
display (either black or corrupted). when I then type 'boot' it goes
back to normal 8 bits. I have access to another Mac Mini G4 and even a
Gigabit Ethernet to test.

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

On Wed, Oct 05, 2016 at 09:59:00PM -0400, Michael Gilbert wrote:
> On Wed, Oct 5, 2016 at 2:56 PM, Riku Voipio wrote:
> > I understand if you feel the arm builds are a burden of extra work for
> > you. The churn of code in chromium and the rapidly rolling security
> > updates certainly made it challenge for me to keep building up-to-date
> > arm packages manually. So I'm certainly ready to stay around to watch
> > and fix any arm-related issues the chromium debian packages might
> > encounter.
 
> Are you willing to become comaintainer?

Just requested on the alioth project and subscribed to the list.

Riku

Bug#839884: Update hangs

[Jörg Frings-Fürst]

Hi,

more info:

apt-get can't interrupted with STRG-C.

After reboot I get:

$ sudo apt-get dist-upgrade
[sudo] Passwort für jff: 
E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »sudo dpkg 
--configure -a« ausführen, um das Problem zu beheben.



CU
Jörg
-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#832112: xrdp: Listening socket is in wrong state we terminate listener

[Andreas Tille]

Hi Dominik,

On Mon, Oct 03, 2016 at 07:31:34PM +0200, Dominik George wrote:
> I am currently packaging the newest upstream version because it seems to
> have major fixes, including a fix for this or at least more informative
> logging.

Thanks for working on this.
 
> Once I got it building correctly (the upstream build system changed,
> gnaaah ☹…) and uploaded, please make another test with the new version.

Just let me know if you managed to deal with the build system and there
is a package to sponsor.

Kind regards

   Andreas.

-- 
http://fam-tille.de

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

For the record, I wish the message I am now responding to, and other
subsequent responses and discussion, were being sent to the bug mail
address *in addition to* all the other addresses they're being sent to.  I
am choosing to send my response here to the bug mail address, at least in
part so there is a record there that not all the discussion related to this
bug is available at the bug itself, but instead is only found in the
debian-ctte list archives.



On Tue, Oct 4, 2016 at 11:31 AM, Adrian Bunk  wrote:

> On Tue, Oct 04, 2016 at 10:30:01AM -0400, Sam Hartman wrote:
>


> > Here are some factors to consider:
>

[...]


> In other words, the best way forward for getting any decision would be
> an RC bug against perl claiming that the Configure script is not DFSG-free.
>

For the record, having read Mr. Hartman's draft analysis at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978#217 , and some
other things related to the perl Configure script source code availability
issue, I admit that I would be ... "amused", for a suitable definition of
the word amused, if this issue were brought up.  (*cough*).




> If anyone thinks that this hardball approach would not be necessary,
> please describe to Pirate Praveen a better way for getting an explicit
> decision in time for stretch.
>

Get a variance from RC-buggyness for browserified Javascript for Stretch,
and package grunt and/or alternative for Stretch+1.  That's what he's asked
for, anyway.

Admittedly, if grunt et al fails to be successfully packaged for Stretch+1,
and/or if packaging grunt et al proves to be insufficient for the
browserified Javascript source code availability issue, then the RC-bug
issue reappears for Stretch+1, with an even more tangled thicket around it
 But, that's the risk one takes.



Hope this is of some use, interest.  Thanks for your time.  Be well.



Joseph

Bug#839853: [Letsencrypt-devel] Bug#839853: [letsencrypt.sh] Upstream change project name

[Daniel Beyer]

Hi Jan,

Thanks for your report. We are aware of the changed name and I'm already
working on a renaming. It's a bit delayed right now, but I hope there
will be some significant progress over the weekend.

Greetings
Daniel

Bug#839885: developers-reference: reintroducing packages: update security issue metadata

[Paul Wise]

Package: developers-reference
Severity: wishlist
X-Debbugs-CC: secur...@debian.org

I would like to add a paragraph to the section about reintroducing
packages so that people reintroducing packages check the security
tracker metadata for the old package and update the metadata once it
gets reintroduced to Debian.

https://www.debian.org/doc/manuals/developers-reference/pkgs.html#reintroducing-pkgs

I propose the following text, please wait for an ack from the security
team before adding it to devref.

Package removals from unstable also trigger marking the package as
removed in the security tracker. Debian members should [mark removed
issues as unfixed][1] in the security tracker repository and all others
should contact[2] the security team to report reintroduced packages.

1. https://security-team.debian.org/security_tracker.html#removed-packages
2. https://security-tracker.debian.org/tracker/data/report

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#839884: Update hangs

[Jörg Frings-Fürst]

Package: network-manager
Version: 1.4.2-1
Severity: grave

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On update network-manager hangs at

network-manager (1.4.2-1) wird eingerichtet ...



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

Kernel: Linux 4.7.0-1-amd64 (SMP w/6 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 network-manager depends on:
ii  adduser3.115
ii  dbus   1.10.10-1
ii  init-system-helpers1.45
ii  libaudit1  1:2.6.7-1
ii  libbluetooth3  5.36-1+b2
ii  libc6  2.24-3
ii  libglib2.0-0   2.50.0-1
ii  libgnutls303.5.4-2
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.6.2-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.4.2-1
ii  libpam-systemd 231-9
ii  libpolkit-agent-1-00.105-16
ii  libpolkit-gobject-1-0  0.105-16
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-3
ii  libsoup2.4-1   2.56.0-1
ii  libsystemd0231-9
ii  libteamdctl0   1.26-1
ii  libuuid1   2.28.2-1
ii  lsb-base   9.20160629
ii  policykit-10.105-16
ii  udev   231-9
ii  wpasupplicant  2.5-2+v2.4-3

Versions of packages network-manager recommends:
ii  crda 3.13-1+b1
ii  dnsmasq-base 2.76-4
ii  iptables 1.6.0-3
ii  iputils-arping   3:20150815-2
ii  isc-dhcp-client  4.3.5~b1-1
ii  modemmanager 1.6.2-1
ii  ppp  2.4.7-1+3

Versions of packages network-manager suggests:
pn  libteam-utils  

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJX9duQAAoJEAn4nzyModJdib0QALzdLImTnRtxUIA1DLjccLB1
gcd5IL2X8+FOOND+meHrVzzjYAJJVGXV9sMhTDTqL371bzI5XO0sNU5MsDe6m6u1
ww5mDdy2nOSpZwZOk5+ZwbLa5LNzTjCkQptypzMbfIaOkaN+lMgMgHQ/9bXT0Cnd
GrYa9EgyZ/gyBYQ/c6HZcMZCVmL/Y7lyJZMItQhtEQddcKOr1B3J4JT/4F+Ufd7t
NQnZvb2uf+g9sQI7iBkR/uyshV9sxVFe+3pqAhahAwTi3NqlSC5aPGsZBi8s2iN6
X0dLsv88QOUehQvX4IsmfiIbu7bZX8khp+oPwzTwYzcl/+kxngCCGcyvqquaSlf1
U9xulWFcnM+d9hQ8lT17ReuYVID1L/toSeyo0Mj65AQ6rRlaVBxkIc6ekUy6r8ke
N8Yq2mkdMG6tL/N4QI4sX83TWNccriA6AG7KYWeJPfJhYtrrLx/a2YWEiOcTyQof
tuEQulycjX6fEFEgfJ/7Td9fXTxNFG3EJa9BA2RidG4G19TDl0ll39Lu6F5g0XDr
4a4rkvpSqOGEkUXMYy+5bdMdr/94Wv8Sl4pULYFjKkcVU4soe3g9tPYiEe8povB9
TjpciJ0SE8lvEUFEFU0A6zedj6zD6VmsnUOVtu7RZc5d7cqggvp6D/KhnS0Uss70
Zg6dP0fKqxg/GQsstpF1
=Py3T
-END PGP SIGNATURE-

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Tollef Fog Heen]

]] "Joseph R. Justice" 

> Could the TC offer guidance, or issue a statement, on if (and if so
> when) it should ever be permissible to allow a waiver from RC-bug
> status for software whose source code is available but determined to
> be insufficiently free for the DFSG while active efforts are underway
> to get the source code into a state determined to be fully compliant
> with the DFSG?

This is very clearly release team territory and they have an RC bug
policy already: https://release.debian.org/stretch/rc_policy.txt If this
isn't clear enough or sufficient enough, that policy should be improved.
The TC should not go out and overrule the release team's RC bug policy
unless we have a really good reason (and it's still not completely clear
that we can overrule them as a team either, but that entire discussion
is unneeded unless we want/need to override them).

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Bug#839833: RFS: gkeyring/0.4-1 [ITP]

[Paul Wise]

Control: owner -1 !
Control: tags -1 + moreinfo

On Wed, Oct 5, 2016 at 10:46 PM, Yann Soubeyrand wrote:

>   dget -x 
> https://mentors.debian.net/debian/pool/main/g/gkeyring/gkeyring_0.4-1.dsc

I intend to sponsor this.

These issues block the upload of this package:

Neither the upstream tarball nor debian/ contain a copy of the AGPLv3.
I see upstream has one in their repository, so they just need to tag a
new release and you need to update to it, or you could package the
commit that adds it. The debian/copyright file should also contain a
full copy of the AGPLv3.

These issues would be nice to fix:

The watch file is broken (see below).

I think you probably only need python rather than python-all?

The Vcs-Browser field points at the upstream repository instead of the
Debian one, please remove it or replace it.

The Vcs-Git field should be present when Vcs-Browser is pointing at a
git repository browser.

The Homepage field should point at github because of this on the launchpad page:

The project is now hosted here:
https://github.com/kparal/gkeyring
This Launchpad site is used for its Answers discussion forum only.

Remove the word Python from the description, the implementation
language isn't relevant to end users.

This command will make diffs of debian/ easier to read:

wrap-and-sort --short-indent --wrap-always --sort-binary-packages
--trailing-comma

The debian/ directory is usually licensed under the same license as upstream.

Please add some upstream metadata:

https://wiki.debian.org/UpstreamMetadata

Please get the manual page included upstream, or get documentation
included in gkeyring.py and have the manual page generated from it
using sphinx and sphinxcontrib-autoprogram/sphinx-argparse.

Please ask upstream about switching to or supporting Python 3 and then
switching to it in Debian.

Upstream is using an image for flattr, I'd suggest they drop it and
only use the existing link, otherwise HTML versions of the README.rst
will violate the privacy of people who load those HTML files. github
is mitigating that by serving all external images from github.com but
it could still occur if someone were to render the document to HTML.

Upstream may want to use signed commits tags and releases:

https://mikegerwitz.com/papers/git-horror-story
https://wiki.debian.org/Creating%20signed%20GitHub%20releases
https://wiki.debian.org/debian/watch#Cryptographic_signature_verification

Upstream may want to read our guide for upstreams:

https://wiki.debian.org/UpstreamGuide

Once the package reaches Debian, add debtags and screenshots:

https://debtags.debian.org/
https://screenshots.debian.net/

Automated checks:

lintian:

P: gkeyring source: debian-watch-may-check-gpg-signature

check-all-the-things:

$ env PERL5OPT=-m-lib=. cme check dpkg
...
Warning in 'control source Build-Depends:0' value 'debhelper (>= 9~)':
should be (>= 9) not (>= 9~) because compat is 9
...
you can try 'cme fix dpkg' to fix the warnings shown above

# check if these can be switched to https://
$ grep -rF http: .
./gkeyring.py:# http://www.gnu.org/licenses/agpl-3.0.html
./gkeyring.py:#
http://blogs.codecommunity.org/mindbending/bending-gnome-keyring-with-python-part-2/
./README.rst:You can install this tool from `PyPI
`_ (using `pip
`_, `setuptools
`_ or `distutils
`_)::
./README.rst:This program is a free software, licensed under `GNU AGPL
3+ `_.
./README.rst:.. image:: http://api.flattr.com/button/flattr-badge-large.png
./debian/copyright: along with this program. If not, see
.
./debian/copyright: along with this program. If not, see
.

# Note the missing / at the end of the URL
$ env PERL5OPT=-m-lib=. license-reconcile
FormatSpec: Cannot recognize format: Format:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0 at
/usr/share/perl5/Debian/LicenseReconcile/App.pm line 222,  line
3.

# This command checks style. While a consistent style
# is a good idea, people who have different style
# preferences will want to ignore some of the output.
# Do not bother adding non-upstreamable patches for this.
$ find -type f -iname '*.py' -exec pep8 --ignore W191 {} +


$ find -type f -iname '*.py' -exec pyflakes {} +
./gkeyring.py:158: 'gtk' imported but unused

$ find -type f -iname '*.py' -exec pyflakes3 {} +
./gkeyring.py:189:26: invalid syntax
except ValueError, e:

$ find -type f -iname '*.py' -exec pylint --rcfile=/dev/null
--msg-template='{path}:{line}:{column}: [{category}:{symbol}] {obj}:
{msg}' --reports=n {} +


$ env PERL5OPT=-m-lib=. uscan --report-status --no-verbose
uscan warn: In watchfile debian/watch, reading webpage
  https://github.com/kparal/gkeyring/archive/ failed: 404 Not Found

-- 
bye,
pabs

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 10:30 AM, Sam Hartman  wrote:

First off, I would like to, sincerely and truly, thank you for responding
to my message.  I'd been wondering if maybe they were going into a black
hole of some sort.  You give me some reassurance that they are not, or at
least not entirely.



Thanks for your detailed message.  I don't agree with all of it, but I
> find it a lot easier to interact with than some of the requests we've
> gotten related to this issue.
>

No problem, thanks back, and fair enough that you don't agree with all of
it.

FWIW, in some ways, it might be easier for me dealing with this than it is,
say, Mr. Praveen.  He is (inevitably!) emotionally invested in this issue,
since it's something important to him, something he's working on.  It's not
something I'm particularly invested in; if anything, this is something I'm
doing "pour le sport".  He is intimately familiar with this stuff; I am
not, so stuff that's obvious to him isn't obvious to me.  And, no
disrespect intended to him (or anyone), but I think I write mor gud (or at
least more verbosely!) than he does.

Just think of me as a roaming mercenary volunteer hired gun lawyer /
advocate / mouthpiece, here to right wrongs, keel keel keel the bad guys,
and sneak off into a haystack in the back barn with the comely schoolmarm
before I ride off into the sunset on my faithful steed, Horse.  (We're
still trying to figure out which of us is smarter.  My vote is on the guy
with four legs, myself.)




> Here are some factors to consider:
>
> 1)  It's not clear to several TC members that the FTP team has decided
> on this question.  It seems fairly clear how they would decide if they
> did decide, but from a process standpoint, it's important to have a
> formal dialogue with them before they are overruled.
>

I'll be honest, I assumed from what I've read that a decision had already
been made by the FTP team against Mr. Praveen.  I figured that it must have
been, or else why would he be raising this bug with the TC now?

I do note however that Mr. Praveen has subsequent to your message stated
that he has filed a formal request with the FTP team concerning
browserified Javascript in general (although IMO he hasn't clearly stated
that in his message opening the bug, tho I do believe that's what he means).

To make life easier for anyone reading the bug log, the full link to the
bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839801 .

I've looked at it as I write this response; there's been no response to
that bug yet (tho I hardly would expect one, it hasn't even been a day
since the bug was filed, after all, and this is a non-trivial decision
being asked for).




> 2) It's not clear constitutionally that the TC can overrule the ftp
> team's decision regarding whether something is DFSG-free.  Even if we
> could, it's not clear that is a technical decision in our scope.
> So, asking the TC to overrule such a decision is asking for the hardest
> political choice possible in such a situation--a really hard sell within
> the project and the TC.
>

Mmmm.  I respect that.

FWIW, I don't think Mr. Praveen necessarily wants a ruling that
browserified Javascript meets the full definition as-interpreted of "source
code available".  (Or, rather, I think *he* thinks browserified Javascript
by itself is "good enough as-is", but he's willing to concede that
something better is possible and preferable.  He's said as much.  He's just
hoping to avoid the stigma of having to be in contrib / non-free for the
release of Debian Stretch, by seeking a variance that this issue is
RC-buggy *for now* so that the various pieces of software can be in main,
while he works on achieving that possible, preferable outcome during the
preparation of Stretch+1 which will permanently resolve the issue of
whether this issue is RB-buggy.)



Mmmm...  With respect to politics...  I fully agree that this is / will be,
at least in part and possibly in large part, a political decision.  Mr.
Praveen has already started that ball in motion, by suggesting that this
issue will cause many (presumably) important pieces of web-based software
to have to be moved to contrib and the libraries they depend on be moved to
non-free, at least until and if grunt (or a sufficiently capable
replacement) can be added to the main archive.  I'm aware that, for many
people, *not* being in main is like saying "You're not *really* part of
Debian Linux".

I'm not a web developer.  I have absolutely no idea how important these
applications are in actual practice.  They may have little use in the Real
World.  They may have tons of use.  It may have strong adverse effects on
users or potential users of Debian if these applications are not in Debian
main; it may have little or no effect at all.  In the worst possible case,
potential users (be they individuals, or end user companies, or people
selling software and services making use of Debian stable) maybe decide to
use 

Bug#839883: libtar FTCBFS: does not pass --host to configure, calls build architecture strip

[Helmut Grohne]

Source: libtar
Version: 1.2.20-6
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libtar fails to cross build from source, because it doesn't pass --host
to configure. Ultimately, dh_strip fails operating on build architecture
ELF objects. In the attached patch, I move libtar to using
dh_auto_configure, which knows the right flags. After that, the build
still fails due to stripping via install -s with the build architecture
strip. Removing the -s flag also means that a -dbgsym package will be
created. Please consider applying the patch as it makes the cross build
succeed.

Helmut
diff --minimal -Nru libtar-1.2.20/debian/changelog 
libtar-1.2.20/debian/changelog
--- libtar-1.2.20/debian/changelog  2016-08-01 22:52:52.0 +0200
+++ libtar-1.2.20/debian/changelog  2016-10-06 06:27:18.0 +0200
@@ -1,3 +1,12 @@
+libtar (1.2.20-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1).
++ Let dh_auto_configure pass cross flags
++ no_strip.patch: Do not let the build system strip
+
+ -- Helmut Grohne   Thu, 06 Oct 2016 06:16:50 +0200
+
 libtar (1.2.20-6) unstable; urgency=low
 
   * Drop libtar/Makefile from examples, since it makes the build
diff --minimal -Nru libtar-1.2.20/debian/patches/no_strip.patch 
libtar-1.2.20/debian/patches/no_strip.patch
--- libtar-1.2.20/debian/patches/no_strip.patch 1970-01-01 01:00:00.0 
+0100
+++ libtar-1.2.20/debian/patches/no_strip.patch 2016-10-06 06:27:31.0 
+0200
@@ -0,0 +1,19 @@
+From: Helmut Grohne 
+Subject: Do not let make install strip
+
+ * Stripping prevents -dbgsym packages from being created.
+ * Stripping with install breaks during cross compilation.
+
+Index: libtar-1.2.20/libtar/Makefile.in
+===
+--- libtar-1.2.20.orig/libtar/Makefile.in
 libtar-1.2.20/libtar/Makefile.in
+@@ -20,7 +20,7 @@
+ 
+ ### Installation programs and flags
+ INSTALL   = @INSTALL@
+-INSTALL_PROGRAM   = @INSTALL_PROGRAM@ -s
++INSTALL_PROGRAM   = @INSTALL_PROGRAM@
+ INSTALL_DATA  = @INSTALL_DATA@
+ LN_S  = @LN_S@
+ MKDIR = @MKDIR@
diff --minimal -Nru libtar-1.2.20/debian/patches/series 
libtar-1.2.20/debian/patches/series
--- libtar-1.2.20/debian/patches/series 2016-03-25 19:11:06.0 +0100
+++ libtar-1.2.20/debian/patches/series 2016-10-06 06:25:23.0 +0200
@@ -4,3 +4,4 @@
 th_get_size-unsigned-int.patch
 oldgnu_prefix.patch
 testsuite.patch
+no_strip.patch
diff --minimal -Nru libtar-1.2.20/debian/rules libtar-1.2.20/debian/rules
--- libtar-1.2.20/debian/rules  2016-03-25 19:12:00.0 +0100
+++ libtar-1.2.20/debian/rules  2016-10-06 06:16:48.0 +0200
@@ -6,10 +6,8 @@
 configure-stamp:
dh_testdir
[ -f debian/autoreconf.before ] || dh_autoreconf
-   ./configure \
-   --prefix=/usr \
+   dh_auto_configure --
--without-zlib \
-   --mandir=\$${prefix}/share/man \
$(shell dpkg-buildflags --export=configure)
touch configure-stamp
 

Bug#817626: RFS: poppassd/1.8.5-4.1 [RC, NMU]

[Peter Colberg]

Control: -1 tags pending

Hi Adam,

I hope you are well. Following advice from the MIA team, I have
uploaded with the help of debian-mentors to the DELAYED/7 queue
a minimal NMU of poppassd that resolves #817626 [1].

Please let me know whether and how to proceed with the changes
proposed in #836008. In case I do not hear from you till the NMU is
accepted, I will take this as a signal that you are, at least for the
moment, too busy to take care of the package and request sponsorship
for poppassd/1.8.7-1. Before the transition freeze in four weeks, I
further plan to add a systemd unit as an alternative to inetd that
restricts the priviledges of poppassd to the necessary minimum.

Whenever you feel ready to work on Debian again, please let me know
and I will gladly return maintenance of poppasswd back to you.

Peter

[1] https://bugs.debian.org/839859

Bug#755848: Patch in preseed src code

[Eric Desrochers]

This patch in preseed source code addresses the situation.

This is the patch we pushed in Ubuntu[1] releases.

Thanks to cyphermox for the joint works (co-authorship).

[1] - https://bugs.launchpad.net/ubuntu/+source/preseed/+bug/1452202

Eric
>From 742808a23407772c516628daecab29b4cbd12b22 Mon Sep 17 00:00:00 2001
From: Eric Desrochers 
Date: Thu, 6 Oct 2016 00:01:59 -0400
Subject: [PATCH] Fix for netcfg/hostname,if set, to take precedence

 Modify debian/network-preseed.postinst
---
 debian/network-preseed.postinst | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/debian/network-preseed.postinst b/debian/network-preseed.postinst
index bf651f4..6102182 100755
--- a/debian/network-preseed.postinst
+++ b/debian/network-preseed.postinst
@@ -14,4 +14,19 @@ if [ -n "$dhcp_url" ]; then
 	preseed_location "$dhcp_url"
 fi
 preseed preseed/url
+
+CURRENT_HOSTNAME=`/bin/hostname`
+if db_get netcfg/hostname && [ "$RET" ]; then
+if ! echo "$RET" | grep -q 'debian'; then
+		# default hostname is debian; if that's what we have in the
+		# netcfg/hostname template, then netcfg will already have
+		# done the right thing.
+		NETCFG_HOSTNAME="$RET"
+		/bin/sed -i "s/$CURRENT_HOSTNAME/$NETCFG_HOSTNAME/" /etc/hostname
+		/bin/sed -i "s/$CURRENT_HOSTNAME/$NETCFG_HOSTNAME/" /etc/hosts
+		/bin/hostname "$NETCFG_HOSTNAME"
+		/usr/bin/logger -t netcfg "d-i netcfg/hostname $NETCFG_HOSTNAME took precedence"
+	fi
+fi
+
 preseed_command preseed/early_command
-- 
2.7.4

Bug#839882: amd64-microcode recommends dracut or initramfs-tools only

[Ricardo Fabian Peliquero]

Package: amd64-microcode
Version: 3.20160316.1
Severity: minor

Dear Maintainer,

amd64-microcode recommends dracut or initramfs-tools. Please consider 
recommending virtual package linux-initramfs-tool instead. That way, it would 
include any of these packages: dracut, initramfs-tools or tiny-initramfs.

Thank you,

Ricardo

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

amd64-microcode depends on no packages.

Versions of packages amd64-microcode recommends:
pn  initramfs-tools | dracut  

amd64-microcode suggests no packages.

-- no debconf information

Bug#839881: firmware-linux recommends both amd64-microcode and intel-microcode

[Ricardo Fabian Peliquero]

Package: firmware-linux
Version: 20160824-1
Severity: minor

Dear Maintainer,

firmware-linux recommends both amd64-microcode AND intel-microcode packages. 
Please consider if recommending amd64-microcode OR intel-microcode would be 
enough.

Kind regards,

Ricardo


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_AR.UTF-8, LC_CTYPE=es_AR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages firmware-linux depends on:
ii  firmware-linux-free 3.4
ii  firmware-linux-nonfree  20160824-1

Versions of packages firmware-linux recommends:
ii  amd64-microcode  3.20160316.1
pn  intel-microcode  

firmware-linux suggests no packages.

-- no debconf information

Bug#792101: ITP: gogs -- self hosted git service

[Michael Lustfield]

retitle 792101 ITP: gogs -- A painless self-hosted Git service.
owner 792101 !
thanks

Updated Details:

* Package name: gogs
  Version : 0.9.97
  Upstream Author : The Gogs Authors
* URL : https://github.com/gogits/gogs
* License : MIT
  Homepage: https://gogs.io/
  Programming Lang: Golang
  Description : A painless self-hosted Git service.
  .
  Gogs is a self-hosted service aiming to provide a similar set of features to
  gitlab and github while remaining lightweight and easy.

I intend to package gogs. I have reached out to the gogs developers to make
them aware of this intention and have offered to discuss what that may mean for
them.

Although upstream makes frequent releases, these seem to rarely have security
fixes so I don't anticipate any significant concerns backporting security
issues. (feel free to double check me!)

-- 
Michael Lustfield


pgpE9EV_lNltq.pgp
Description: OpenPGP digital signature

Bug#839880: proftpd-basic: proftpd server instance crashed with signal 11

[Franklin Weng]

Package: proftpd-basic
Version: 1.3.5-1.1+deb8u1
Severity: grave
Justification: renders package unusable

proftpd started successfully in my jessie system.  However after some day
(it may be after a system-wide upgrade) the client failed to login.

The client part shows:

Connected to goodhorse.idv.tw.
220 ProFTPD 1.3.5 Server (Debian) [:::218.161.78.26]
Name (goodhorse.idv.tw:franklin): ftp
331 允許匿名登入，請用您完整的信箱位址做為登入密碼
Password:
421 Service not available, remote server has closed connection
Login failed.
No control connection for command: No such file or directory
ftp>


The server part (running with `proftpd -n -d 10`) shows

2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): retrieved group ID:
65534
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): retrieved group name:
nogroup
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): dispatching PRE_CMD
command 'PASS (hidden)' to mod_shaper
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): ROOT PRIVS at
mod_shaper.c:2026
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): ProFTPD terminating
(signal 11)
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): ProFTPD terminating
(signal 11)
2016-10-06 11:47:43,524 teabbs proftpd[18292] teabbs.goodhorse.idv.tw
(223-137-143-82.EMOME-IP.hinet.net[223.137.143.82]): FTP session closed.
2016-10-06 11:47:46,046 teabbs proftpd[18278] teabbs.goodhorse.idv.tw:
scrubbing scoreboard



-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (501, 'stable'), (500, 'stable-updates'), (50, 'unstable')
Architecture: i386 (i686)

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

Versions of packages proftpd-basic depends on:
ii  adduser3.113+nmu3
ii  debconf1.5.56
ii  debianutils4.4+b1
ii  libacl12.2.52-2
ii  libc6  2.19-18+deb8u6
ii  libcap21:2.24-8
ii  libmemcached11 1.0.18-4
ii  libmemcachedutil2  1.0.18-4
ii  libncurses55.9+20140913-1+b1
ii  libpam-runtime 1.1.8-3.1+deb8u1
ii  libpam0g   1.1.8-3.1+deb8u1+b1
ii  libpcre3   2:8.35-3.3+deb8u4
ii  libssl1.0.01.0.1t-1+deb8u3
ii  libtinfo5  5.9+20140913-1+b1
ii  libwrap0   7.6.q-25
ii  netbase5.3
ii  sed4.2.2-4+b1
ii  ucf3.0030
ii  zlib1g 1:1.2.8.dfsg-2+b1

proftpd-basic recommends no packages.

Versions of packages proftpd-basic suggests:
pn  openbsd-inetd | inet-superserver  
ii  openssl   1.0.1t-1+deb8u3
pn  proftpd-doc   
pn  proftpd-mod-geoip 
pn  proftpd-mod-ldap  
pn  proftpd-mod-mysql 
pn  proftpd-mod-odbc  
pn  proftpd-mod-pgsql 
pn  proftpd-mod-sqlite

-- debconf information:
* shared/proftpd/inetd_or_standalone: standalone

Bug#839879: mtr FTCBFS: uses build architecture tools

[Helmut Grohne]

Source: mtr
Version: 0.86-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

mtr fails to cross build from source, because it doesn't pass --host to
configure. Rather than extending the long line even further, I opted for
using dh_auto_configure in the attached patch. It also simplifies the
management of installation paths by leveraging DESTDIR, which is why I
also had to switch to dh_auto_install. After switching to
dh_auto_configure cross builds just work. Can you apply it?

Helmut
diff --minimal -Nru mtr-0.86/debian/changelog mtr-0.86/debian/changelog
--- mtr-0.86/debian/changelog   2015-12-07 20:37:45.0 +0100
+++ mtr-0.86/debian/changelog   2016-10-06 05:27:27.0 +0200
@@ -1,3 +1,10 @@
+mtr (0.86-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags, closes: #-1
+
+ -- Helmut Grohne   Thu, 06 Oct 2016 05:27:09 +0200
+
 mtr (0.86-1) unstable; urgency=low
 
   * Added patch from Andrew Suffield to use setcap instead of setuid,
diff --minimal -Nru mtr-0.86/debian/rules mtr-0.86/debian/rules
--- mtr-0.86/debian/rules   2015-12-07 21:02:22.0 +0100
+++ mtr-0.86/debian/rules   2016-10-06 05:38:41.0 +0200
@@ -15,9 +15,9 @@
 
autoreconf -fi
 
-   mkdir mtr && cd mtr && CFLAGS=-I.. ../configure $(shell dpkg-buildflags 
--export=configure >/dev/null 2>&1 && dpkg-buildflags --export=configure) 
$(confflags) --prefix=`pwd`/debian/tmp/usr 
--mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin
+   CFLAGS=-I.. dh_auto_configure --builddirectory=mtr -- $(shell 
dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
--export=configure) $(confflags)
 
-   mkdir mtr-tiny && cd mtr-tiny && CFLAGS=-I.. ../configure $(shell 
dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
--export=configure) $(confflags) --prefix=`pwd`/debian/tmp/usr 
--mandir=`pwd`/debian/tmp/usr/share/man --sbindir=`pwd`/debian/tmp/usr/bin 
--without-gtk
+   CFLAGS=-I.. dh_auto_configure --builddirectory=mtr-tiny -- $(shell 
dpkg-buildflags --export=configure >/dev/null 2>&1 && dpkg-buildflags 
--export=configure) $(confflags) --without-gtk
 
 
 
@@ -40,10 +40,8 @@
 
 override_dh_installdirs-arch:
dh_installdirs -a
-   $(MAKE) -C mtr-tiny prefix=`pwd`/debian/mtr-tiny/usr install
-   mv mtr-tiny/debian/tmp/usr/bin/mtr debian/mtr-tiny/usr/bin/
-   $(MAKE) -C mtr prefix=`pwd`/debian/mtr/usr install
-   mv mtr/debian/tmp/usr/bin/mtr debian/mtr/usr/bin/
+   dh_auto_install --builddirectory=mtr-tiny --destdir=debian/mtr-tiny
+   dh_auto_install --builddirectory=mtr --destdir debian/mtr
 
 override_dh_installchangelogs-arch:
dh_installchangelogs -a NEWS

Bug#839878: gnome-software FTCBFS: requests --enable-firmware without depending on libfwupd-dev

[Helmut Grohne]

Source: gnome-software
Version: 3.22.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

gnome-software fails to cross build from source to architectures other
than arm or x86 family. It lists libfwupd-dev in Build-Depends for them,
but when it comes to deciding whether to pass --enable-firmware, it
examines the build architecture. Thus cross building gnome-software e.g.
from amd64 to ppc64el, causes --enable-firmware to be passed but no
libfwupd-dev to be installed.

Unfortunately, I cannot verify whether this fixes the full cross build,
because meanwhile gnome-software's Build-Dependens have become
unsatisfiable for the purpose of cross building. I hope you can apply
the attached patch nonetheless. I'll retry building it once it becomes
feasible again.

Helmut
diff --minimal -Nru gnome-software-3.22.0/debian/changelog 
gnome-software-3.22.0/debian/changelog
--- gnome-software-3.22.0/debian/changelog  2016-09-22 20:48:42.0 
+0200
+++ gnome-software-3.22.0/debian/changelog  2016-10-05 22:01:02.0 
+0200
@@ -1,3 +1,10 @@
+gnome-software (3.22.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Deconfuse build vs. host. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Oct 2016 22:00:41 +0200
+
 gnome-software (3.22.0-1) unstable; urgency=medium
 
   [ Jeremy Bicha ]
diff --minimal -Nru gnome-software-3.22.0/debian/rules 
gnome-software-3.22.0/debian/rules
--- gnome-software-3.22.0/debian/rules  2016-09-22 20:48:42.0 +0200
+++ gnome-software-3.22.0/debian/rules  2016-10-05 22:00:39.0 +0200
@@ -13,7 +13,7 @@
GS_CONFIGURE_FLAGS += --enable-limba --enable-flatpak
 
# Enable fwupd support on supported architectures
-   ifneq (,$(findstring $(DEB_BUILD_ARCH), amd64 arm64 armhf i386))
+   ifneq (,$(findstring $(DEB_HOST_ARCH), amd64 arm64 armhf i386))
GS_CONFIGURE_FLAGS += --enable-firmware
endif
 endif

Bug#839661: vim-latexsuite is not compatible with vim 8.0 because of missing python flag

[James McCoy]

Control: retitle -1 Please update vim-latexsuite to get python3 support

On Mon, Oct 03, 2016 at 05:29:18PM +0200, Patrik Marschalik wrote:
> vim-latexsuite requires vim built with python support but vim 2:8.0.0003-1 is
> built with python3 only.

To clarify, the vim packages switched from providing the python bindings
to the python3 bindings.

vim-latexsuite upstream has become active again and has python3 support
in the latest version (1.9.0).  Please update the package so it works
with the new Vim.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#837406: caff: "gpg: error reading key: No public key"

[Ben Hutchings]

Control: severity -1 serious

On Mon, 12 Sep 2016 14:15:34 +0200 Guilhem Moulin  wrote:
> Control: tag -1 pending
> 
> Got it!  I couldn't reproduce it because I have
> "$CONFIG{'keys-from-gnupg'} = 1;" in my ~/.caffrc.  The regression was
> introduced in r864 (2.4-1) and the enclosed patch fixes it.

I'm raising the severity as this appears to make caff unusable in its
default configuration and it's not at all obvious how to work around it
.  Please upload soon.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.



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

Bug#838864: chromium crashes soon after start

[robert b]

I managed to get chromium-dbg installed.  Below is the gdb output.

I am still unsure what's causing the crash.


# Env:
# LD_LIBRARY_PATH=/home/robert/lib:/usr/local/lib
#
PATH=.:/home/robert/bin:/home/robert/bin/linux:/home/robert/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/usr/local/bin
#GTK_PATH=
#  CHROMIUM_FLAGS= 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=21.0.0.242
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.TmBVDl
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/lib/chromium/chromium...Reading symbols from 
/usr/lib/debug/.build-id/ec/00040d83407b108d1beaf6c51909ce66eba047.debug...
warning: 
"/usr/lib/debug/.build-id/ec/00040d83407b108d1beaf6c51909ce66eba047.debug": 
separate debug info file has no debug info
(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) handlge SIG33 pass nostop noprint
SignalStop  Print   Pass to program Description
SIG33 NoNo  Yes Real-time event 33
(gdb) set pagination 0
(gdb) r
Starting program: /usr/lib/chromium/chromium 
--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so 
--ppapi-flash-version=21.0.0.242 
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeac98700 (LWP 6416)]
[New Thread 0x7fffea497700 (LWP 6421)]
[New Thread 0x7fffe9964700 (LWP 6422)]
[New Thread 0x7fffe9163700 (LWP 6423)]
[New Thread 0x7fffe8962700 (LWP 6424)]
[New Thread 0x7fffdb7fe700 (LWP 6426)]
[New Thread 0x7fffdbfff700 (LWP 6425)]
[New Thread 0x7fffe8161700 (LWP 6427)]
[New Thread 0x7fffd9d9b700 (LWP 6428)]
[New Thread 0x7fffd959a700 (LWP 6429)]
[New Thread 0x7fffd8d99700 (LWP 6430)]
[New Thread 0x7fffb700 (LWP 6431)]
[New Thread 0x7fffbf7fe700 (LWP 6432)]
[New Thread 0x7fffbeffd700 (LWP 6433)]
[New Thread 0x7fffbe7fc700 (LWP 6434)]
[New Thread 0x7fffbdd79700 (LWP 6435)]
[New Thread 0x7fffbd578700 (LWP 6436)]
[New Thread 0x7fffbcd77700 (LWP 6437)]
[New Thread 0x7fffa18c3700 (LWP 6438)]
[6408:6434:1005/193055:ERROR:nss_util.cc(809)] After loading Root Certs, 
loaded==false: NSS error code: -8018
[New Thread 0x7fff9cca6700 (LWP 6439)]
[New Thread 0x7fff9c4a5700 (LWP 6440)]
[New Thread 0x7fff9bca4700 (LWP 6445)]
[New Thread 0x7fff9b4a3700 (LWP 6452)]
[New Thread 0x7fff9aca2700 (LWP 6454)]
[New Thread 0x7fff9a4a1700 (LWP 6453)]
[6408:6429:1005/193103:ERROR:connection.cc(1894)] Passwords sqlite error 5, 
errno 0: database is locked, sql: PRAGMA journal_mode = TRUNCATE
[6408:6429:1005/193104:ERROR:connection.cc(1894)] Passwords sqlite error 5, 
errno 0: database is locked, sql: PRAGMA cache_size=32
[6408:6429:1005/193104:ERROR:connection.cc(1894)] Passwords sqlite error 5, 
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE type=? 
AND name=? COLLATE NOCASE
[6408:6429:1005/193104:ERROR:connection.cc(1894)] Passwords sqlite error 5, 
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE type=? 
AND name=? COLLATE NOCASE
[6408:6429:1005/193104:ERROR:connection.cc(1894)] Passwords sqlite error 5, 
errno 0: database is locked, sql: CREATE TABLE meta(key LONGVARCHAR NOT NULL 
UNIQUE PRIMARY KEY, value LONGVARCHAR)
[6408:6429:1005/193104:ERROR:login_database.cc(413)] Unable to create the meta 
table.
[6408:6429:1005/193104:ERROR:password_store_default.cc(45)] Could not 
create/open login database.
[New Thread 0x7fff9900e700 (LWP 6455)]
[Thread 0x7fff9900e700 (LWP 6455) exited]
[6408:6429:1005/193106:ERROR:connection.cc(1894)] Shortcuts sqlite error 5, 
errno 0: database is locked, sql: PRAGMA journal_mode = TRUNCATE
[6408:6429:1005/193106:ERROR:connection.cc(1894)] Shortcuts sqlite error 5, 
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE type=? 
AND name=? COLLATE NOCASE
[6408:6429:1005/193106:ERROR:connection.cc(1894)] Shortcuts sqlite error 5, 
errno 0: database is locked, sql: SELECT name FROM sqlite_master WHERE type=? 
AND name=? COLLATE NOCASE
[6408:6429:1005/193106:ERROR:connection.cc(1894)] Shortcuts sqlite error 5, 
errno 0: database is locked, sql: CREATE TABLE omni_box_shortcuts (id VARCHAR 
PRIMARY KEY, text VARCHAR, fill_into_edit VARCHAR, url VARCHAR, contents 
VARCHAR, contents_class VARCHAR, description VARCHAR, description_class 
VARCHAR, transition INTEGER, type 

Bug#771441: I don't believe that NetworkManager is at fault here

[Ron]

On Wed, Oct 05, 2016 at 05:45:58PM +0100, Mike Crowe wrote:
> In Message #75 2015-05-22 13:35 GMT+02:00 Ron  wrote:
> > It's not only tftp-hpa that would get burned by this.  Any network
> > using service that needs to resolve or use an address would fail in
> > exactly the same way if started before your network is up.  And lots
> > of them do.  This isn't a new problem, you're just lucky that it's
> > the only thing that you are seeing it on.
> 
> I don't believe that it's sensible for tftpd to assume that all network
> interfaces are up before it is started. We no longer live in a world of
> fixed network configurations.

Sure, but the majority of devices in that world are now phones, and
devices which won't typically host network services.  And they'd stop
being very useful if the servers they relied on started roaming around
the network at random like an end-user device does.

If you have servers doing that, you have bigger problems to fix than
this.  I don't think we can apply "50 million blowflies can't be wrong"
logic to this, we need to look at what is most appropriate for a server
if we're talking about what the default configuration should be.

You can't 'fix' that by just changing tftpd, there are lots of server
applications which assume or require this as part of configuring them
securely.  Breaking that assumption has larger consequences than just
needing to implement netlink monitoring in them all.


> I believe that leaves daemons such as tftpd with three choices:
> 
> 1. Bind to INADDR_ANY and accept connections on any network interfaces as
> they appear. Rely on firewalling to avoid unwanted connections.
> 
> 2. Bind to network devices rather than addresses using SO_BINDTODEVICE.
> This isn't ideal since network devices may have multiple addresses.
> 
> 3. Monitor network interfaces via netlink and bind to them as they appear.

Or leaves applications like NM with two choices to support people
running services:

  1. Give them an option to block waiting on interfaces which are
 expected to be up to be up, before starting services that
 will be offered on them.

  2. Provide hooks to (re)start or stop the services that are bound
 to particular interfaces when those interfaces come or go.

And realistically, I think it must provide both those things to be
considered a functional application, regardless of what other
services do.

Don't get me wrong, I've been a huge fan of all things hotplug since
long before NM even existed, and support for that in the kernel
became widespread - but it is a Hard problem to solve well, and you
can't solve it by kicking the can down the road and saying "the rest
of you will all need figure out the problems this creates and then
rewrite your code".

See https://bugs.debian.org/816087#15
for another example of how "just let everything race" can go badly
wrong if you turn off the traffic lights at a major intersection
without paying enough attention to the consequences of that.


> The current tftpd-hpa package defaults to being available on all interfaces
> via an IPv4 address. In Message #25, Ron rightly questioned whether this is
> still a sensible default. But, as I said in Message #30, I don't believe
> that changing the default to TFTP_ADDRESS=":69" makes the situation any
> worse, and it does mean that tftpd does work correctly when no network
> interface is available at startup. Maybe if the default was changed then it
> could be turned into a debconf question?

What if it already was a debconf question ;?

The default is only used for people who don't answer that themselves
with something different.

What the default should be is mostly a balancing act between what is
sane for a relatively naive user who doesn't know what they should
answer there, and what would be right out of the box for most people
without 'special needs'.  Whether it should be changed now, also adds
the question of line of least surprise for existing users, so there
is some inertia and risk there which we shouldn't ignore if changing
it now is not the clearly compelling thing to do.


I'm inclined to think that running this on a laptop is a special case.
And that changing it "because otherwise NM breaks" would be hiding a
bug in NM rather than fixing it at the real cause.

But I'm not ruling out that there might be other compelling reasons
to still change the default for this at some point.  Whether that
should be to :69, or to something else, is still an open question.

  Ron

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 9:18 AM, Sam Hartman  wrote:

> > "Didier" == Didier 'OdyX' Raboud  writes:
>

I do think there are things we could do in this space.
> We could set policy consistent with the DFSG on what the definition of
> source code in Debian is.
>

Could the TC offer guidance, or issue a statement, on if (and if so when)
it should ever be permissible to allow a waiver from RC-bug status for
software whose source code is available but determined to be insufficiently
free for the DFSG while active efforts are underway to get the source code
into a state determined to be fully compliant with the DFSG?

That's what Mr. Praveen is actually asking for, after all.  (IMO, of
course.)  He wants the software he is interested in in the Debian main
archive at the time Debian Stretch is released (because, politically and
... I can't think of the right word, but in terms of advertising
capabilities, it's undesirable for the software to have to be relegated to
the contrib and non-free archives, those don't count for many as being part
of "Debian").  But, in practical terms, while the source code for the
software may effectively be available within Debian now, it does not meet
the full and pristine interpretation of the DFSG in terms of what it means
to have source code available.  So, while he works on that (by packaging
grunt), he's seeking a waiver from RC-bug status for this issue for the
in-preparation release.

Mmmm.  I believe I saw ...  Found it.

https://lists.debian.org/debian-devel/2016/07/msg00253.html .

Quoting from that message (first paragraph from Mr. Praveen, remainder by
Philip Hands ):

=
> And why is the people who are so strict about packaging the build tool
> not stepping up to package it? FRP for node-grunt was filed in 21 May
> 2012 and it is still not complete. So removing these packages until
> grunt is packaged makes debian better?

They should be in contrib.

Allowing them in main removes any incentive to do the work to fix this
problem, which I'd imagine is the reason it's not been done.

When this was last raised, I looked into it and concluded that grunt is
a tangled mess.

[...]

Simply letting them [ed: packages ultimately depending on the presence of
grunt] into main removes that pressure [ed: to deal with the tangled mess
of grunt either directly or else indirectly by finessing / replacing it,
and/or by getting upstreams to alter their use of grunt, etc], it also
means that
we're deceiving our users, since they expect buildable source for all
packages in main.
=

That's a political decision, too.  (I'm not claiming or implying it's a
wrong decision, mind you!  I'm simply noting it as an observation, I was
impressed by it the first time I read it.)



Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#799939: chromium not available for armhf/arm64

[Michael Gilbert]

On Wed, Oct 5, 2016 at 2:56 PM, Riku Voipio wrote:
> I understand if you feel the arm builds are a burden of extra work for
> you. The churn of code in chromium and the rapidly rolling security
> updates certainly made it challenge for me to keep building up-to-date
> arm packages manually. So I'm certainly ready to stay around to watch
> and fix any arm-related issues the chromium debian packages might
> encounter.

Are you willing to become comaintainer?

Best wishes,
Mike

Bug#837964: 95a05b3 broke mdadm --add on my superblock 1.0 array

[NeilBrown]

On Thu, Sep 22 2016, Guoqing Jiang wrote:

> On 09/21/2016 02:45 AM, Guoqing Jiang wrote:
>>
>>
>> On 09/20/2016 02:31 PM, Anthony DeRobertis wrote:
>>> Sorry for the amount of emails I'm sending, but I noticed something 
>>> that's probably important. I'm also appending some gdb log from 
>>> tracing through the function (trying to answer why it's doing cluster 
>>> mode stuff at all).
>>>
>>> While tracing through, I noticed that *before* the write-bitmap loop, 
>>> mdadm -E considers the superblock valid. That agrees with what I saw 
>>> from strace, I suppose. To my first glance, it figures out how much 
>>> to write by calling this function:
>>>
>>> static unsigned int calc_bitmap_size(bitmap_super_t *bms, unsigned 
>>> int boundary)
>>> {
>>> unsigned long long bits, bytes;
>>>
>>> bits = __le64_to_cpu(bms->sync_size) / 
>>> (__le32_to_cpu(bms->chunksize)>>9);
>>> bytes = (bits+7) >> 3;
>>> bytes += sizeof(bitmap_super_t);
>>> bytes = ROUND_UP(bytes, boundary);
>>>
>>> return bytes;
>>> }
>>>
>>> That code looked familiar, and I figured out where—it's also in 
>>> 95a05b37e8eb2bc0803b1a0298fce6adc60eff16, the commit that I found 
>>> originally broke it. But that commit is making a change to it: it 
>>> changed the ROUND_UP line from 512 to 4096 (and from the gdb trace, 
>>> boundary==4096).
>>>
>>> I tested changing that line to "bytes = ROUND_UP(bytes, 512);", and 
>>> it works. Adds the new disk to the array and produces no warnings or 
>>> errors.
>>
>> I think it is is a coincidence that above change works,  4a3d29e 
>> commit made
>> the change but it didn't change the logic at all.
>
> Hmm, seems bitmap is aligned to 512 in previous mdadm, but with commit 
> 95a05b3
> we made it aligned to 4k, so it causes the latest mdadm can't work with 
> previous
> created array.
>
> Does the below change work? Thanks.
>
> diff --git a/super1.c b/super1.c
> index 9f62d23..6a0b075 100644
> --- a/super1.c
> +++ b/super1.c
> @@ -2433,7 +2433,10 @@ static int write_bitmap1(struct supertype *st, 
> int fd, enum bitmap_update update
>  memset(buf, 0xff, 4096);
>  memcpy(buf, (char *)bms, sizeof(bitmap_super_t));
>
> -   towrite = calc_bitmap_size(bms, 4096);
> +   if (__le32_to_cpu(bms->nodes) == 0)
> +   towrite = calc_bitmap_size(bms, 512);
> +   else
> +   towrite = calc_bitmap_size(bms, 4096);
>  while (towrite > 0) {

(sorry for the late reply ... travel, jetlag, )

I think a better, simpler, fix is:

> -   towrite = calc_bitmap_size(bms, 4096);
> +   towrite = calc_bitmap_size(bms, 512);

The only reason that we are rounding up here is that we are using
O_DIRECT writes and they require 512-byte alignment.

Any bytes beyond the end of the actual bitmap will be ignored, so it
doesn't matter whether they are written or not.

Current mdadm always aligns bitmaps on a 4K boundary, but older version
of mdadm didn't.  If the bitmap was less than 4K before the superblock
(quite possible), writing 4K for bitmap would corrupt the superblock.
This can certainly happen with 1.0 metadata.

However ... the reason that everything is now 4K aligned is that some
drives use a 4K block size.  For those, we really should be doing 4K
writes, not 512-byte writes.

So it would make sense to round up to 4K sometimes, and use 512 at other
times.  However the correct test isn't whether cluster-raid is in use.

The metadata has always been aligned on a 4K boundary.
If data_offset and bblog_offset and bitmap_offset all have 4K alignment,
then rounding up to 4K for the bitmap writes would be correct.
If anything have a smaller alignment, then it isn't necessary and so
should be avoided.

So the best fix would be to test those 3 offsets, and round up to a
multiple of 4096 only if all of them are on a 4K boundary.

NeilBrown



signature.asc
Description: PGP signature

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

On Tue, Oct 4, 2016 at 7:37 AM, Didier 'OdyX' Raboud 
wrote:

Would the following ballot be a better fit ?
> ==
> C: Decline to rule on #830978 'Browserified javascript and DFSG 2'
> FD: Further Discussion
> ==
>

I'd like to state again that, if you (the TC as a body) choose not to vote
in favor of Mr. Praveen's request, I believe he would be more satisfied if
you chose to express an active preference against his position and in favor
of the (presumable) FTP Team's position, rather than merely decline to make
a ruling and close the bug.  I believe, given his original message opening
the bug, that he would find the latter action by you all highly
unsatisfactory.  (Not that I claim he would be satisfied by an active
ruling against him, mind you!)

Thanks for your time.  Hope this is of some use, interest.



Joseph

Bug#839570: Browserified javascript and DFSG 2 (reopening)

[Joseph R. Justice]

[I realize there have been several messages subsequent to this, but I'm
working down the list in order of presentation by the GMail web interface.]

On Tue, Oct 4, 2016 at 4:13 AM, Didier 'OdyX' Raboud 
wrote:

> Le dimanche, 2 octobre 2016, 14.29:49 h CEST Pirate Praveen a écrit :
>


> > package: tech-ctte
> >
> > Following up on #830978. I would like this to be reopened and request
> > CTTE make a formal vote.
>
> The discussion that lead to closing #830978 happened on IRC [0] , see the
> full
> log from line 172 [1] , and Sam put a clear rationale in the mail closing
> the
> bug [2]. I'll quote on specific part of it:
> > With regard to the particular issue of Browserified javascript,
> > particularly in the libjs-handlebars package, the best way forward is
> > for the submitter to discuss the question with the FTP team.  Such a
> > discussion would be less confusing if it took place after #830986 is
> > resolved.
>
> (#830986 isn't resolved)
>

FWIW, it's not clear to me at least that ""browserified" Javascript"
necessarily includes the issue pointed out in 830986, e.g. the generated
lexer/parser code.  (I'm not saying it *doesn't* include the 830986 issue,
mind you!  I'm just not saying either that it *does* include it.  Reviewing
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830978 , I see some
comments that, to me at least, imply that browserification does not
necessarily imply the 830986 issue in in play for any given instance of
browserified code.)

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#5 , Mr. Praveen
lists bugs which ultimately refer to several other Javascript library
packages beyond that of libjs-handlebars.  I suppose it's possible that all
of them include generated lexer/parser code, but if there are some that do
not then apparently "browserification" does not necessarily involve use of
external lexer/parser generators (tho certainly it's possible that
browserification, in the form Mr. Praveen means it, might include always
having the capability to invoke a lexer/parser as part of the process of
browserifying Javascript libraries).  In any event, for any browserified
libraries which do *not* include code generated by a lexer/parser, the bug
at 830986 should not apply to them.

Further, in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839570#35 ,
Mr. Praveen says "the browserified javascript can be modified by anyone who
understand javascript without difficulty and can satisfy dfsg requirement
for source" where the browserified javascript refers to "libjs-handlebars,
libjs-fuzzaldrin-plus and other browserified javascript".  Given what I
understand about the sort of code typically generated by lexer/parsers,
e.g. that it typically can *not* be modified, in generated form, by
"anyone" "without difficulty", I have to think that either (a) Mr. Praveen
does not mean libraries of this sort (e.g. containing generated
lexer/parser code) when he is speaking of browserification in general, or
else (b) he is mistaken in his claim about how easy to modify such
libraries.

So...  If there can be / are browserified libraries which do not suffer
from an issue of containing generated lexer/parser code, then it may make
sense to consider whether such libraries are suitable for inclusion in the
"main" archive separately from the issue of any such libraries which *do*
suffer from an issue of containing generated lexer/parser code.  (For the
record, I myself do not know if there are any such libraries, nor am I
claiming that there are any such.  I'm just raising the possibility as a
"What if?" sort of thing.)




> Now, moving forwards… We decided to close the bug without a formal vote,
> because it was clear for all the present TC members that we were in
> agreement.
> We have also agreed (amongst us) to avoid the use of unnecessary
> bureaucracy
> when possible; hence our delegation to close the bug to Sam. Now, the
> offer to
> "repoen the bug and ask for a formal vote"  [3] stood to enable anyone to
> ask
> for the bug closure to respect our formal procedures (saying "please don't
> close the bug because you think you're in agreement, but run a formal
> vote").
>
> For what I'm concerned, the situation hasn't evolved, and the conclusion
> that
> Sam outlined still stands (FTP Team is responsible for DFSG, and has
> decided,
> Release Team has decided DFSG is RC and has deferred DFSG-compliance
> determination to FTP Team).
>

I'll go into this point in more detail in other responses, I expect, but
I'll at least say for now that I think it is possible to find that there
are differing levels or degrees of DFSG non-compliance, in terms of their
severity of non-compliance or the amount of harm that can be done by
distributing them despite the fact that they are not fully compliant with
*all* the terms of the DSFG and their current interpretation by Debian, and
that therefore it is possible that it might be reasonable in some
circumstances to decide that a 

Bug#839877: ITP: uftrace -- Traces and analyzes execution of programs written in C/C++

[paul cannon]

Package: wnpp
Severity: wishlist
Owner: paul cannon 

* Package name: uftrace
  Version : 0.6.0.20161004-1
  Upstream Author : Namhyung Kim 
* URL : https://github.com/namhyung/uftrace/
* License : GPL
  Programming Lang: C
  Description : Traces and analyzes execution of programs written in C/C++

The uftrace tool is intended for tracing and analyzing the execution of
programs written in C or C++. It was heavily inspired by the ftrace
framework of the Linux kernel (especially the function graph tracer) and
supports userspace programs. It supports various kinds of commands and
filters to help analysis of the program's execution and performance.

It traces each function in the executable and shows time durations. It
can also trace external library calls - but only entry and exit are
supported, and internal function calls within the library cannot be
traced unless the library itself was built with profiling enabled.

It can show detailed execution flow at function level, and report which
function has the highest overhead. It also shows various information
related to the execution environment.

You can setup filters to exclude or include specific functions when
tracing. In addition, function arguments and return values can be saved
and shown later.

The uftrace tool supports multi-process and/or multi-threaded
applications. It can also trace kernel functions as well, with root
privileges and if the system enables the function graph tracer in the
kernel (CONFIG_FUNCTION_GRAPH_TRACER=y).


 - why is this package useful/relevant? is it a dependency for
   another package? do you use it? if there are other packages
   providing similar functionality, how does it compare?

Cachegrind provides similar functionality, but only provides information
in aggregate, whereas uftrace will collect the entire stack and provide
pretty output for visualization. It is more of a "tracer" than a
sample-and-aggregate tool. Intel has a profiler called VTune(tm)
Amplifier which also fills a related niche, but it is not free software.

 - how do you plan to maintain it? inside a packaging team
   (check list at https://wiki.debian.org/Teams)? are you
   looking for co-maintainers? do you need a sponsor?

Should be simple enough to self-maintain. No sponsor needed. I'm on
LowThresholdNmu.

Bug#839865: kde-cli-tools: CVE-2016-7787

[Balint Reczey]

On Wed, 05 Oct 2016 21:48:58 +0200 Salvatore Bonaccorso
 wrote:
> Hi,
> 
> the following vulnerability was published for kde-cli-tools.
> 
> CVE-2016-7787[0]:
> kdesu: Displayed command truncated by unicode string terminator
> 
> If you fix the vulnerability please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> 
> For further information see:
> 
> [0] https://security-tracker.debian.org/tracker/CVE-2016-7787
> [1] https://www.kde.org/info/security/advisory-20160930-1.txt
> 
> Please adjust the affected versions in the BTS as needed. I'm not sure
> if kde-runtime is as well affected (it looks source wise, since the
> same file can be patched).

It seems both Jessie and Wheezy are affected in some way.
Both show the command in the dialog, but on my vagrant VM installations
the string terminator was not interpreted on Wheezy, just on Jessie.

Test command: kdesudo ls $(printf 'aa\u9chidden')

On Jessie it shows the following dialog:
+---
|  ls aa[]hidden needs administrative privileges. Please eneter your
|  password.
|
| Command ls aa
| Password:|
| OK Cancel
+---
Thus the string terminator takes effect only once.

On Wheezy the dialog looks like this:
+---
|  ls aa[?]hidden needs administrative privileges. Please eneter your
|  password.
|
| Command ls aa[?]hidden
| Password:|
| OK Cancel
+---


[],[?] - block showing unknown unicode character

Cheers,
Balint

Bug#819590: slixmpp 1.2.1 released

[W. Martin Borgert]

https://blog.mathieui.net/slixmpp-1-2.html
(And there is even 1.2.1 in git.)

Any packaging progress so far?
It would be nice to have the package in Stretch...

Bug#824470: DDPO: add last-upload and Standards-Version columns

[Eriberto Mota]

Hi,

I created a report[1] based in UDD that provides the requested information.

[1] https://people.debian.org/~eriberto/help_a_package.html

Regards,

Eriberto

Bug#668242: [pkg-dhcp-devel] Bug#668242: isc-dhcp-server-ldap: creates invalid config for dhcpHost without dhcpHWAddress

[Michael Gilbert]

On Wed, Oct 5, 2016 at 5:11 AM, Dave Whitla wrote:
> This issue persists 4 years later in Jessie 4.3.1-6+deb8u2.
> It may be minor for the maintainer but its a showstopper for my usage.

I'm happy to consider a patch that scratches your itch.

Best wishes,
Mike

Bug#577848: ITP

[Mattia Rizzolo]

control: owner -1 Dima Kogan 

On Wed, Oct 05, 2016 at 04:11:09PM -0700, Dima Kogan wrote:
> reassign 577848 wnpp
> thanks
> 
> I'm going to package this shortly

then you should also set yourself as owner of the bug (doing now)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#839872: Acknowledgement (python-mayavi: Missing files ("No module named tvtk_scene"))

[Andreas Kloeckner]

Possibly related:

https://github.com/enthought/mayavi/issues/447

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[John Paul Adrian Glaubitz]

On 10/06/2016 12:52 AM, Mehdi Dogguy wrote:
>> I'm a bit shocked to be honest how much I'm being prosecuted down for
>> this! We should really start wondering where the code of conduct
>> ends and the censorship and the paternalism starts.
>>
> 
> My intention was not to make you feel prosecuted. I am sorry if you
> feel it that way.

No worries. I was just surprised that this was picked up again after
Laura already spoke to me. She had sent me a mail and I had a discussion
with her and that's it. I didn't expect this to come up again.

>> Again, I did not attack anyone directly, I was swearing in public
>> and I think this is something which is covered by freedom of speech.
>>
> 
> I believe that your original message did hurt some people, even if it
> wasn't directed towards anybody specifically. So freedom of speech is
> guaranteed as long as nobody feels attacked, hurt or shocked. And, CoC
> is not meant to censor anyone. It is a tool to ensure that we interact
> in a pleasant and welcoming environment, for the maximum of people.

Well, if someone wants to get hurt they will be hurt. You can't really
prevent that from happening. There have been some unfortunate developments
in society in this regards where people are over-sensitizing and reacting
offended to even the tiniest lack of courtesy and honestly, I find that
disturbing.

We are all humans and therefore we can be moody, annoyed and stressed
out. And swearing is just a means of venting and a very legitimate
one I find. I rather prefer people swearing than building up their
anger and then loosing their minds completely.

And I remember the discussions when the CoC was established and back
then some people where so overly sensitive that even the old figure
of speech about tarring and feathering someone offended them as they
interpreted that sentence as actual threat of violence against themselves
which is, of course, ridiculous.

So, while I agree we should keep things on a professional level, I would
also like to emphasize that Debian is a project run by humans and not
emotionless robots meaning that all the previous statements from above
regarding stress, emotions and moodiness apply.

>> I'm not going to comment further on this. I'm also no longer subscribed
>> to the pkg-mate-team mailing list and I will most likely also leave
>> the team because I honestly didn't just feel annoyed but outright
>> harassed by those people you abuse the Debian bug tracker as their
>> personal support ticket system. Those aren't just lapses and oversights,
>> this is outright laziness and malicious entitlement by those people.
>>
> 
> We are not forced to reply to every bug. We have also ways to ensure that
> specific people are banned from interacting with the BTS and mailing lists
> if we show they have a malicious behavior, by contacting BTS admins and
> listmasters. We all feel the same when some minority abuses some system.
> Some maintainers know better how to deal with those. I believe it is better
> to ignore those abusers instead of swearing.

Well, the primary problem that we have - from my personal experience - is
the fact that the Debian BTS is just too freely accessible. It has become
so outright easy to report a bug that most users can't even be bothered
to go through support channels like IRC or mailing list first. They run into
a small problem, don't even bother to do some initial testing themselves
to be able to exclude common mistakes and the first thing they do is
go to the bug tracker and file a bug.

While you are right that we don't have to reply to every bug, you also
have to keep in mind that we are actually still interested in valid bug
reports because they are also a means for us maintainers to keep an
overview over existing issues. For example, for the sparc64 port, we're
reporting every architecture-related issue, tag it with the "sparc64"
and are therefore always able to see what the remaining, unresolved issues
are which is an important tool when working on a project over a long
time.

Now, when people like the initial reporter of this bug report start
flooding us with redundant or invalid bug reports, they add lots of
noise into the bug tracking and effectively hamper our work up to
a point where it gets outright annoying and almost harassing. Again,
I do not have a problem with valid bug reports. But I expect everyone
who files a bug to have at least the courtesy to do some research
first before filing a bug report, especially when using the development
versions of Debian where constant breakage is to be expected. Filing
a bug report should always be the last measure when dealing with a
problem, not the first one. It's a bug tracker after all, not a ticket
system from IT support.

I therefore really wished that we start locking down the bug tracker
like other projects do. It would be a big improvement if reporters
had to go through some sort of account system first. This will not
just reduce the number of bugs reports which were 

Bug#577848: ITP

[Dima Kogan]

reassign 577848 wnpp
thanks

I'm going to package this shortly

Bug#839695: qemu: Please build qemu with –enable-gtk

[J Mo]

I had read similar statements out on the internet that gtk support was 
bad previously, but that those issues have long been worked out. I'm 
using it on an Arch system now and it feels really good to have.


There is also 3D acceleration features starting to go in, so you are 
probably going to get forced into making some choice: That Debian's qemu 
is server-only and not good for desktop usage, that headless servers 
will have to install a few more packages that they don't really need, or 
building separate packages for the different use cases.


I don't know what the right thing to do is. That's up to you!

Thanks for looking at this.



On 10/05/2016 08:37 AM, Michael Tokarev wrote:

It is more, gtk support weren't complete as well, lacking several
features available in sdl1.

It was maybe 2 years ago, and I don't really know at which state
things are now.

Also, making separate package isn't really that easy: we'll have
to create additional package for every of all various different
architectures (x86, sparc, mips, etc).

This is JFYI, I'll try to take a look. 

Bug#577848: ITP

[Dima Kogan]

reassign -1 wnpp
thx

I'm going to package this shortly

Bug#834943: bug forwarded to GitHub

[Viktor Jägersküpper]

reopen 834943
retitle 834943 caja crash when changing from trash in list view to other
directory in list view
forwarded 834943 https://github.com/mate-desktop/caja/issues/649
thanks

Dear MATE Maintainers,

unfortunately I noticed recently that this bug is still present in caja
1.16.0 and I reported it upstream.

Regards
Viktor

Bug#805591: php7.0: Segmentation fault on new DateTimeZone('leap-seconds.list')

[Jonathan Champ]

Followup-For: Bug #805591
Package: php7.0-common
Version: 7.0.11-1

Dear Maintainer,

This is still a problem in php7.0; it appears to be related to Debian
timezone patches.

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

Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 php7.0 depends on:
ii  php7.0-common  7.0.11-1
ii  php7.0-fpm 7.0.11-1

php7.0 recommends no packages.

php7.0 suggests no packages.

Versions of packages php7.0-common depends on:
ii  libc62.24-3
ii  libssl1.0.2  1.0.2j-1
ii  php-common   1:45
ii  ucf  3.0036

-- no debconf information

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[Mehdi Dogguy]

On 06/10/2016 00:32, John Paul Adrian Glaubitz wrote:
> On 10/06/2016 12:21 AM, Mehdi Dogguy wrote:
>> I have read your message, and I can understand it can be difficult at
>> time to deal with recurrent bugreports. But, I do not feel comfortable
>> with the way you expressed your frustration. And it is not acceptable
>> to use those terms to communicate with our community (and users).
> 
> Was this now escalated to you after I did not agree with larjona@d.o?
> 

No. In fact, I was not in contact with larjona lately at all, tbh.

> I'm a bit shocked to be honest how much I'm being prosecuted down for
> this! We should really start wondering where the code of conduct
> ends and the censorship and the paternalism starts.
> 

My intention was not to make you feel prosecuted. I am sorry if you
feel it that way.

> Again, I did not attack anyone directly, I was swearing in public
> and I think this is something which is covered by freedom of speech.
> 

I believe that your original message did hurt some people, even if it
wasn't directed towards anybody specifically. So freedom of speech is
guaranteed as long as nobody feels attacked, hurt or shocked. And, CoC
is not meant to censor anyone. It is a tool to ensure that we interact
in a pleasant and welcoming environment, for the maximum of people.

> I'm not going to comment further on this. I'm also no longer subscribed
> to the pkg-mate-team mailing list and I will most likely also leave
> the team because I honestly didn't just feel annoyed but outright
> harassed by those people you abuse the Debian bug tracker as their
> personal support ticket system. Those aren't just lapses and oversights,
> this is outright laziness and malicious entitlement by those people.
> 

We are not forced to reply to every bug. We have also ways to ensure that
specific people are banned from interacting with the BTS and mailing lists
if we show they have a malicious behavior, by contacting BTS admins and
listmasters. We all feel the same when some minority abuses some system.
Some maintainers know better how to deal with those. I believe it is better
to ignore those abusers instead of swearing.

All best,

-- 
Mehdi

Bug#658886: Removing proll from Debian?

[Mark Cave-Ayland]

On 04/10/16 22:17, Adrian Bunk wrote:

> Hi,
> 
> proll is a JavaStation PROM replacement.
> 
> JavaStations are 32bit, so not supported by the new sparc64 port.
> The old 32bit sparc port has already been remved from Debian.
> 
> Guillem mentions in #658886 that QEMU once used to use proll
> (but didn't anymore in 2012?).
> 
> Am I right that proll is no longer of use for anyone and should be 
> removed from unstable, or are there any usecases left?
> 
> cu
> Adrian

Hi Adrian,

QEMU switched to OpenBIOS from proll several years ago, so the QEMU
dependency is no longer relevant today.


ATB,

Mark.

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[John Paul Adrian Glaubitz]

On 10/06/2016 12:21 AM, Mehdi Dogguy wrote:
> I have read your message, and I can understand it can be difficult at
> time to deal with recurrent bugreports. But, I do not feel comfortable
> with the way you expressed your frustration. And it is not acceptable
> to use those terms to communicate with our community (and users).

Was this now escalated to you after I did not agree with larjona@d.o?

I'm a bit shocked to be honest how much I'm being prosecuted down for
this! We should really start wondering where the code of conduct
ends and the censorship and the paternalism starts.

Again, I did not attack anyone directly, I was swearing in public
and I think this is something which is covered by freedom of speech.

I'm not going to comment further on this. I'm also no longer subscribed
to the pkg-mate-team mailing list and I will most likely also leave
the team because I honestly didn't just feel annoyed but outright
harassed by those people you abuse the Debian bug tracker as their
personal support ticket system. Those aren't just lapses and oversights,
this is outright laziness and malicious entitlement by those people.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#836246: Acknowledgement (libgtk-3-0: Upgrade from 3.20.9 to 3.21.5 broke Mate desktop)

[Mehdi Dogguy]

Hi John,

I have read your message, and I can understand it can be difficult at
time to deal with recurrent bugreports. But, I do not feel comfortable
with the way you expressed your frustration. And it is not acceptable
to use those terms to communicate with our community (and users).

Users may have send those bugreports in good faith, not just to annoy
you. Having such bugreports is also a good way to evaluate the impact
of the bug (admittedly, it may be obvious in this specific case).

As a project, we have adopted a Code of Conduct [1] for participants
to our mailinglists, IRC channels and other communication means. We
expect our users to respect it. And, more importantly, I expect our
project members to defend it.

I would like to ask you to think about this and I'd like to count on
you to have more calm exchanges in the future. It is collectively
important, for both contributors and users, to be able to interact in
a safe and pleasant environment. We are all here to make fun! So
please, let's make it enjoyable the best we can.

[1] https://www.debian.org/code_of_conduct

All best,

-- 
Mehdi Dogguy

Bug#839842: apt-listbugs: Polish translation update for apt-listbugs/pl.po

[Francesco Poli]

On Wed, 05 Oct 2016 19:16:06 +0200 Tomasz Nitecki wrote:

[...]
> Hey,
> 
> Attached is the updated polish translation for apt-listbugs (v0.1.19).

Hello Tomasz,
thanks a lot for updating the translation!   :-)

I will soon push it to the public git repository; it will be
included in the next upload.

As usual, your contribution is really appreciated!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpRNyxs40Qxo.pgp
Description: PGP signature

Bug#839866: import-orig: please make --upstream-vcs-tag=... verify tag signatures

[Guido Günther]

On Wed, Oct 05, 2016 at 09:55:08PM +0200, Guilhem Moulin wrote:
> Package: git-buildpackage
> Version: 0.8.4
> Severity: wishlist
> 
> Dear Maintainer,
> 
> `gpg import-orig --upstream-vcs-tag` provides a nice way to preserve the
> upstream VCS tree up to the most recent tag.  However, signed upstream
> tags, when present, are currently not verified.  It would be nice to
> provide an option for automatic tag verification using the armored
> keyring from debian/upstream/signing-key.asc, to match uscan(1)
> signature verification logic.
> 
> In cases where upstream generates tarballs based on VCS tags,
> maintainers could then easily avoid downloading upstream tarballs
> altogether while 1/ preserving the upstream VCS tree, and 2/ still being
> able to ensure upstream code integrity. 

That makes a lot of sense. I'm not a heavy --upstream-vcs-tag user so
tested patches (preferably with a testcase [1]) would be nice!
Cheers,
 -- Guido

[1]: a simple test in tests/component would be sufficient to test this
behaviour at all

Bug#839876: rhythmbox-plugins: Failed to load module 'mtpdevice': /usr/lib/x86_64-linux-gnu/libmtp.so.9: undefined symbol: libusb_handle_events_timeout_completed

[Michael Biebl]

Control: tags -1 + moreinfo

Am 05.10.2016 um 23:14 schrieb Gary Richards:
> Package: rhythmbox-plugins
> Version: 3.4.1-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Today I tried to plugin my android phone (in MTP mode) and sync some music to
> it using rhythmbox like I have done in the past.
> 
> Rhythmbox has been unable to find my device.
> 
> I noticed that the 'Portable Players - MTP' plugin had an icon next to it,
> hovering over it suggested there was an error loading the plugin.
> 
> I loaded ryhthmbox with --debug, the output contains:
> 
> (rhythmbox:5739): libpeas-WARNING **: Failed to load module 'mtpdevice':
> /usr/lib/x86_64-linux-gnu/libmtp.so.9: undefined symbol:
> libusb_handle_events_timeout_completed
> 

Can you send me the output of

ldd /usr/lib/x86_64-linux-gnu/libmtp.so.9

-- 
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#839717: [l10n:eu] apt-listbugs 0.1.20: updated Basque translation

[Francesco Poli]

On Tue, 04 Oct 2016 11:15:14 +0200 Dooteo wrote:

> Attached Basque translation. Please, could you add it for us?
> 
> Thanks and best regards,

Hello Iñaki,
thanks a lot for updating the translation!   :-)

I will soon push it to the public git repository; it will be
included in the next upload.

Your contribution is really appreciated!
Bye.


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgppXL9LTJUFL.pgp
Description: PGP signature

Bug#839875: nmu: python-poppler-qt5

[Julien Cristau]

Control: tag -1 wontfix

On Thu, Oct  6, 2016 at 00:04:41 +0300, Dmitry Shachnev wrote:

> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: binnmu
> Severity: normal
> Control: block 839870 by -1
> 
> Dear release team,
> 
> It looks like the python3-poppler-qt5 package got broken [1] with one of
> recent sip4 or pyqt5 uploads. Instability of sip ABI is a known issue [2],
> hopefully it will be fixed in the next sip release [3].
> 
It really needs to be fixed there, not worked around with a rebuild,
IMO.

Cheers,
Julien

Bug#839869: transition: poppler 0.48.0

[Emilio Pozuelo Monfort]

On 05/10/16 22:13, Pino Toscano wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> I would like to ask a slot for a Poppler 0.48.0 transition.
> Poppler 0.48.0 is hopefully going to be released this month, so it will
> be uploaded to experimental first, as usual.

OK. Let us know when that happens.

Cheers,
Emilio

Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

[Thomas Orgis]

Am Wed, 5 Oct 2016 21:34:49 +0200
schrieb Salvatore Bonaccorso : 

> Any news from the DWF project on the assigned CVE?

Nothing. I got the initial request to accept the MITRE Terms of Use for
CVE from the person handling my case (I assume). I replied to the mail
at 2016-09-30. Nothing came back. I don't know what is the usual
duration here. Maybe my reply got dropped as it was sent from the
account behind maintai...@mpg123.org, wich is only a forwarder.

Dunno how to proceed.


Alrighty then,

Thomas


pgpFqRZ3RHxLy.pgp
Description: Digitale Signatur von OpenPGP

Bug#785069: jessie live-installer can't install grub when booted via usb drive without internet

[Hakan Bayındır]

I’ve dug the problem more and found out that when the installer is started from 
the boot menu, apt-cdrom-setup udeb is also added to the installer, however 
when installer is started from the live-environment, this udeb is omitted 
somehow. This causes installation media not to be scanned as a candidate apt 
repository after installation completes. 

The bug may solve itself if somehow live-installer also loads apt-cdrom-setup 
udeb during startup. I personally didn’t find a way to do so yet.

Bug#839875: nmu: python-poppler-qt5

[Dmitry Shachnev]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: binnmu
Severity: normal
Control: block 839870 by -1

Dear release team,

It looks like the python3-poppler-qt5 package got broken [1] with one of
recent sip4 or pyqt5 uploads. Instability of sip ABI is a known issue [2],
hopefully it will be fixed in the next sip release [3].

I have verified that a simple rebuild fixes the python3-poppler-qt5 issue.

  nmu python-poppler-qt5_0.24.2-1 . ANY . -m 'Rebuild against latest sip 
(#839870)'

[0]: https://bugs.debian.org/839870
[2]: https://www.riverbankcomputing.com/pipermail/pyqt/2015-May/035896.html
[3]: 
https://www.riverbankcomputing.com/pipermail/pyqt/2016-September/038136.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#839874: lintian: check the canonical form of the homepage field of Bioconductor R packages

[Dylan]

Package: lintian
Version: 2.5.48
Severity: wishlist
Tags: patch

Hi,
Please find attached a patch which add the check of the canonical form
of the homepage field for Bioconductor R packages. It is similar to
the check for the CRAN packages already implemented in lintian.

Best,
Dylan
From f0d86d0cc54b1edde0b1ef643cc182969c7d6c46 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Dylan=20A=C3=AFssi?= 
Date: Wed, 5 Oct 2016 22:55:29 +0200
Subject: [PATCH] c/fields: Tag non-canonical forms of Bioconductor homepage

---
 checks/fields.desc   | 15 +++
 checks/fields.pm |  4 
 .../debian/debian/control.in | 16 
 t/tests/fields-bioconductor-homepage/desc|  4 
 t/tests/fields-bioconductor-homepage/tags|  2 ++
 5 files changed, 41 insertions(+)
 create mode 100644 t/tests/fields-bioconductor-homepage/debian/debian/control.in
 create mode 100644 t/tests/fields-bioconductor-homepage/desc
 create mode 100644 t/tests/fields-bioconductor-homepage/tags

diff --git a/checks/fields.desc b/checks/fields.desc
index a8143f6..7df3dee 100644
--- a/checks/fields.desc
+++ b/checks/fields.desc
@@ -1318,3 +1318,18 @@ Info: The Homepage field for this package points to an uncanonical CRAN URL.
  not:
  .
   https://cran.r-project.org/web/packages/foo/index.html
+
+Tag: homepage-for-bioconductor-package-not-canonical
+Severity: wishlist
+Certainty: certain
+Info: The Homepage field for this package points to an uncanonical Bioconductor URL.
+ Please update to use the current canonical URL instead. The canonical URL is
+ recommended for use in publications, etc., will always redirect to current
+ release version (or devel if package is not in release yet).  For example, the
+ link for the package "foo" should be:
+ .
+ https://bioconductor.org/packages/foo/
+ .
+ not:
+ .
+ https://www.bioconductor.org/packages/(release|devel|*)/bioc/html/foo.html
diff --git a/checks/fields.pm b/checks/fields.pm
index 66b8d77..4d7343c 100644
--- a/checks/fields.pm
+++ b/checks/fields.pm
@@ -619,6 +619,10 @@ sub run {
 if ($homepage=~ m,/cran\.r-project\.org/web/packages/.+,){
 tag 'homepage-for-cran-package-not-canonical', $orig;
 }
+if ($homepage=~ m,bioconductor\.org/packages/.*/bioc/html/.*\.html*$,)
+{
+tag 'homepage-for-bioconductor-package-not-canonical', $orig;
+}
 } elsif (not $info->native) {
 if ($type eq 'source') {
 my $binary_has_homepage_field = 0;
diff --git a/t/tests/fields-bioconductor-homepage/debian/debian/control.in b/t/tests/fields-bioconductor-homepage/debian/debian/control.in
new file mode 100644
index 000..385c886
--- /dev/null
+++ b/t/tests/fields-bioconductor-homepage/debian/debian/control.in
@@ -0,0 +1,16 @@
+Source: {$source}
+Priority: extra
+Section: {$section}
+Maintainer: {$author}
+Standards-Version: {$standards_version}
+Build-Depends: {$build_depends}
+Homepage: https://www.bioconductor.org/packages/release/bioc/html/foo.html
+
+Package: {$source}
+Architecture: {$architecture}
+Depends: $\{shlibs:Depends\}, $\{misc:Depends\}
+Description: {$description}
+ This is a test package designed to exercise some feature or tag of
+ Lintian.  It is part of the Lintian test suite and may do very odd
+ things.  It should not be installed like a regular package.  It may
+ be an empty package.
\ No newline at end of file
diff --git a/t/tests/fields-bioconductor-homepage/desc b/t/tests/fields-bioconductor-homepage/desc
new file mode 100644
index 000..aeea583
--- /dev/null
+++ b/t/tests/fields-bioconductor-homepage/desc
@@ -0,0 +1,4 @@
+Testname: fields-bioconductor-homepage
+Version: 1.0
+Description: Bioconductor Homepage URLs should be canonical
+Test-For: homepage-for-bioconductor-package-not-canonical
\ No newline at end of file
diff --git a/t/tests/fields-bioconductor-homepage/tags b/t/tests/fields-bioconductor-homepage/tags
new file mode 100644
index 000..b539a90
--- /dev/null
+++ b/t/tests/fields-bioconductor-homepage/tags
@@ -0,0 +1,2 @@
+I: fields-bioconductor-homepage source: homepage-for-bioconductor-package-not-canonical https://www.bioconductor.org/packages/release/bioc/html/foo.html
+I: fields-bioconductor-homepage: homepage-for-bioconductor-package-not-canonical https://www.bioconductor.org/packages/release/bioc/html/foo.html
-- 
2.1.4

Bug#839711: Updated sv.po for apt-listbugs

[Francesco Poli]

On Tue, 4 Oct 2016 11:18:52 +0200 Anders Jonsson wrote:

> Hi Martin,
> I looked through the file and made some small spelling/grammar fixes
> (ettiketter -> etiketter) etc.

Hello Martin and Anders,
thanks for your fast responses!

Some questions:

  #: ../lib/aptlistbugs/logic.rb:613
  msgid ""
  "None of the above bugs is assigned to package %s\n"
  "Are you sure you want to pin it?"
  msgstr ""
  "Ingen av ovanstående fel är relaterade till paket %s. Är du säker på att du "
  "vill nåla det?"

Shouldn't the translation be split into two lines (just like the
original English message)?
If you agree, I'll modify the translation as:

  msgstr ""
  "Ingen av ovanstående fel är relaterade till paket %s\n"
  "Är du säker på att du vill nåla det?"

Is this OK?

Moreover:

  #: ../lib/aptlistbugs/logic.rb:854
  msgid "tags"
  msgstr "etiketter"

Elsewhere the term "tags" is translated as "taggar"; can the
translation consistency be improved by modifying this translation into
the following?

  msgstr "taggar"

Is this OK?



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpoFFsGeyeB4.pgp
Description: PGP signature

Bug#839873: fakechroot: ldd.fakechroot assumes LANG=C

[jhcha54008]

Package: fakechroot
Version: 2.18-1.1
Severity: normal
Tags: patch

Dear Maintainer,

ldd.fakechroot parses the output of objdump which is
locale dependant. It may give strange results in any locale
other than 'C'.

$ echo $LANG
fr_FR.UTF-8
$ fakechroot fakeroot -i .fakeroot.state -s .fakeroot.state chroot mychroot ldd 
/bin/cat
not a dynamic executable
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x)
/lib/ld-linux-x86-64.so.2 (0x)
$ LANG=C fakechroot fakeroot -i .fakeroot.state -s .fakeroot.state chroot 
mychroot ldd /bin/cat
linux-vdso.so.1 =>  (0x)
libfakeroot-sysv.so => 
/usr/lib/x86_64-linux-gnu/libfakeroot/libfakeroot-sysv.so (0x)
libfakechroot.so => 
/usr/lib/x86_64-linux-gnu/fakechroot/libfakechroot.so (0x)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x)
/lib64/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 
(0x)

which is the expected result.


Regards,
JH Chatenet

--- a/scripts/ldd.fakechroot.pl
+++ b/scripts/ldd.fakechroot.pl
@@ -154,6 +154,8 @@
 exit 1;
 }
 
+$ENV{LANG} = "C";
+
 if (not `sh -c 'command -v objdump'`) {
 print STDERR "fakeldd: objdump: command not found: install binutils 
package\n";
 exit 1;



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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages fakechroot depends on:
ii  libfakechroot  2.18-1.1

fakechroot recommends no packages.

fakechroot suggests no packages.

-- no debconf information

Bug#607617: src:linux-latest-2.6: no linux-headers-2.6-all package

[Ben Hutchings]

Control: tag -1 moreinfo
Control: submitter -1 Ansgar Burchardt 

On Mon, 20 Dec 2010 11:21:48 +0100 Ansgar Burchardt
 wrote:
> Package: src:linux-latest-2.6
> Version: 2.6.32+28
> Severity: wishlist
> 
> linux-2.6 provides a (versioned) linux-headers-2.6.32-5-all package.  It
> would be nice if the current version of this package was available as
> linux-headers-2.6-all as well, similar to the other linux-headers-2.6-*
> packages.

So far as I can see, the original purpose of the existing linux-
headers-*-all packages was to support source packages that build binary
packages of modules for all flavours, for inclusion in the archive.
Since the removal of nvidia-graphics-modules, we no longer have any
such source packages and I don't know what these metapackages would be
useful for.

In any case, such a source package would often need to be updated for
API changes in the kernel, so I wouldn't expect a binNMU with an
updated linux-headers-all metapackage to work.  Do you remember how
you intended to use this metapackage?

Ben.
 
-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.

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

Bug#839872: python-mayavi: Missing files ("No module named tvtk_scene")

[Andreas Kloeckner]

Package: python-mayavi
Version: 4.4.3-2.2
Severity: normal

Dear Maintainer,

Using the package, I found that much of tvtk seems to be missing:

Traceback (most recent call last):
  File "local-expand.py", line 288, in 
main()
  File "local-expand.py", line 283, in main
resolution=resolution)
  File "local-expand.py", line 269, in draw_fig
from mayavi import mlab
  File "/usr/lib/python2.7/dist-packages/mayavi/mlab.py", line 27, in 
from mayavi.tools.camera import view, roll, yaw, pitch, move
  File "/usr/lib/python2.7/dist-packages/mayavi/tools/camera.py", line 25, in 

from engine_manager import get_engine
  File "/usr/lib/python2.7/dist-packages/mayavi/tools/engine_manager.py", line 
14, in 
from mayavi.core.engine import Engine
  File "/usr/lib/python2.7/dist-packages/mayavi/core/engine.py", line 28, in 

from mayavi.core.base import Base
  File "/usr/lib/python2.7/dist-packages/mayavi/core/base.py", line 19, in 

from tvtk.pyface.tvtk_scene import TVTKScene
ImportError: No module named tvtk_scene

Thanks,
Andreas

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 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)

Bug#839871: Connman not working with some routers due to not following RFC.

[Kristian Klausen]

Package: connman
Version: 1.32-0.1
Severity: important


Hello


Connman 1.32 doesn't follow the RFC regarding the order of some dhcp options.

This result in Connman not working with some routers/dhcp server, for example 
the D-Link DSR-1000.

It took me some hours to figure that out, and my patch was upstreamed today.

Could this be cherry-picked? 
https://git.kernel.org/cgit/network/connman/connman.git/commit/?id=fee1e4fec7a78480e5a4d7b8c5d43e679c148829

So we/I don't need to wait for Conman 1.34.


- Kristian Klausen

Bug#839751: apt-cacher-ng: Hostname not verified on outgoing TLS connections

[Eduard Bloch]

Control: tags 839751 +pending

Hallo,
* Michael Hanselmann [Tue, Oct 04 2016, 05:07:19PM]:
> Package: apt-cacher-ng
> Version: 0.9.1-1ubuntu1
> Severity: important
> 
> Dear Maintainer,
> 
> apt-cacher-ng 0.9.1-1~bpo8+1 as included in the backports for Debian
> Jessie, 0.9.1-1ubuntu1 as included in Ubuntu Xenial as well as the
> version in the "upstream/sid" branch do not verify the hostname in
> certificates when making outgoing TLS connections (HTTPS). This report
> is produced on an Ubuntu installation, but the issue is unrelated to the
> distribution.

Implemented, thank you.

https://alioth.debian.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=apt-cacher-ng/apt-cacher-ng.git;a=commitdiff;h=6d720bb0a1733559a8a2b5dcb25d5c5cf7256ef5

Actually, last time I tested something like this, it looked "ok" but
that host was using SNI which covered the issue (get.docker.com).

Regards,
Eduard.

Bug#837629: OpenRD* with debian's u-boot 2016.09

[Vagrant Cascadian]

On 2016-10-03, Rick Thomas wrote:
> On Oct 1, 2016, at 3:39 PM, Vagrant Cascadian  wrote:
>> On 2016-09-17, Rick Thomas wrote:
>>> On Sep 16, 2016, at 3:19 PM, Vagrant Cascadian  wrote:
 https://bugs.debian.org/837629
...
>>  deb http://cascadia.debian.net/~vagrant/debian UNRELEASED main
>> 
>> The repository should be signed by my key, available in the
>> debian-keyring package in the archive
>> (F0ADA5240891831165DF98EA7CFCD8CD257721E9).
>> 
>> There were two critical fixes in 2016.09.01, *maybe* they fix the issue?

And now uploaded 2016.11~rc1 to my "UNRELEASED" repository, please test
that...


>> If not, I'll likely be removing OpenRD* from the packages on future
>> uploads.
...
> Sadly, it doesn’t look like it fixed the problem.  Still nothing after
> installing the new u-boot.kwb and typing “reset”.
>
> let me know if there’s anything more I can do to help…

If it's not fixed in 2016.11~rc1, the only thing left to try is git
bisecting the issue...


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#198507: dh_install: fails if filenames have an embedded space

[Niels Thykier]

Gergely Nagy:
> Hi!
> 
>> "Niels" == Niels Thykier  writes:
> 
>   Niels> On Mon, 23 Jun 2003 09:59:52 -0400 Joe Nahmias 
>  wrote:
> 
> Now, this is quite an ancient issue! :D
> 

Partly why I want it -done'd! ;)

> [...]
> 
> You only need to teach debhelper to handle the \-escaped spaces.
> 

I am not really sure I want to use \-escaped spaces. Besides being a
pain in themselves, it would also suggest that the glob characters can
be escaped.  Which leads us to Joey Hess's comment in #198507#17.

If we go down that route of backslash escaped characters, I inclined to
go all in with Text::ParseWords's shellwords/parse_line from the beginning.

Would that still be doable in the dh-exec end?

Thanks,
~Niels

Bug#838997: lintian: checks/init.d: Check for initscripts that source /lib/lsb/init-functions without declaring the corresponding dependency on lsb-base (>= 3.0-6).

[Didier 'OdyX' Raboud]

Le mercredi, 5 octobre 2016, 20.08:31 h CEST Chris Lamb a écrit :
> Didier 'OdyX' Raboud wrote:
> > But all-in-all, what matters is the dependency, as there were no changes
> > since 2013 (4.1+Debian10), and Jessie has 4.1+Debian13.
> 
> Just to be clear, are you suggesting that the version part should be
> dropped?

It's a political question. My nitpicker side favours precise dependencies 
(because we can), but my realistic side admits lsb-base >= 4.1+Debian13 will 
be available for all packages which will see changes following the lintian 
warning.

If we can, and we can, we should have precise dependencies instead of 
'available in stable'; it helps downstreams as well.

> I've seen other bits of Deban be really rather "picky" about versions (even
> ones that are satisfied in oldstable!) so I took my lead from that.
> 
> What do others think?
> 
> (ACK on the status_of_proc — will fix.)

Great, thanks.

-- 
Cheers,
OdyX

Bug#837808: Info received (Bug#837808: Info received (Bug#837808: Info received (Seeing the same thing)))

[Miek Gieben]

Looks to be https://bugzilla.redhat.com/show_bug.cgi?id=1346228

Bug#839870: python3-poppler-qt5: Unable to load PDF file.

[Christoph Döpmann]

Package: python3-poppler-qt5
Version: 0.24.2-1+b2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

I appear to be unable to use the popplerqt5 module. Whenever I try to
load a PDF file by file name, a TypeError is raised, indicating that the
file name may not be given as a string:

$ python3
Python 3.5.2+ (default, Sep 10 2016, 10:24:58) 
[GCC 6.2.0 20160901] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import popplerqt5
>>> = popplerqt5.Poppler.Document.load('test.pdf')
  File "", line 1
= popplerqt5.Poppler.Document.load('test.pdf')
^
SyntaxError: invalid syntax
>>> popplerqt5.Poppler.Document.load('test.pdf')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: Document.load(): argument 1 has unexpected type 'str'
>>> 

However, the Qt4 version works fine:

$ python3
Python 3.5.2+ (default, Sep 10 2016, 10:24:58) 
[GCC 6.2.0 20160901] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import popplerqt4
>>> popplerqt4.Poppler.Document.load('/tmp/screen.pdf')

>>>

Since I haven't come across any API change to be aware of, I suppose this is a 
bug.


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

Kernel: Linux 4.6.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 python3-poppler-qt5 depends on:
ii  libc6  2.23-5
ii  libgcc11:6.1.1-11
ii  libpoppler-qt5-1   0.44.0-3
ii  libstdc++6 6.1.1-11
ii  python33.5.1-4
ii  python3-pyqt5  5.7+dfsg-2
ii  python3-sip [sip-py3api-11.2]  4.18.1+dfsg-1

python3-poppler-qt5 recommends no packages.

python3-poppler-qt5 suggests no packages.

-- no debconf information

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[Michael Biebl]

Hi

Am 05.10.2016 um 22:06 schrieb John Paul Adrian Glaubitz:
> pygtk currently fails to build from source on sparc64 due to a bus error in
> one of the tests in the testsuite:

[..]

> Feel free to ask on debian-sp...@list.debian.org in any case.

We are happy to take a patch for that. It would be great if you can also
forward this upstream.

Regards,
Michael
-- 
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#839869: transition: poppler 0.48.0

[Pino Toscano]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I would like to ask a slot for a Poppler 0.48.0 transition.
Poppler 0.48.0 is hopefully going to be released this month, so it will
be uploaded to experimental first, as usual.

This transition impacts the existing poppler libraries in the following ways:
- libpoppler61 → libpoppler64
- libpoppler-glib8 -- BC with 0.44 (one new symbol)
- libpoppler-qt4-4 -- BC with 0.44 (few new symbols)
- libpoppler-qt5-1 -- BC with 0.44 (few new symbols)

Below it is a list of sources which are touched by the transition:

  boomaga
  calligra
  cups-filters
  emacs-pdf-tools
  gambas3
  gdal
  gdcm
  inkscape
  ipe-tools
  pdf2djvu
  pdf2htmlex
  popplerkit.framework
  texlive-bin
  texworks
  xpdf

I haven't tested them yet with versions > 0.44, although it seems there
should not be distruptive enough changes to the API of the private
libpoppler. I will deal with the failures anyway (as I have done in
the past).

Other cases:

* derivations
This source builds a libpoppler-based utility application which is
only used during the build to generate other data, and no trace of
that application are left in the resulting arch:all package.

Ben file:

title = "poppler 0.48.0";
is_affected = .depends ~ "libpoppler61" | .depends ~ "libpoppler64";
is_good = .depends ~ "libpoppler64";
is_bad = .depends ~ "libpoppler61";

Thanks,
-- 
Pino

Bug#839866: import-orig: please make --upstream-vcs-tag=... verify tag signatures

[Guilhem Moulin]

Package: git-buildpackage
Version: 0.8.4
Severity: wishlist

Dear Maintainer,

`gpg import-orig --upstream-vcs-tag` provides a nice way to preserve the
upstream VCS tree up to the most recent tag.  However, signed upstream
tags, when present, are currently not verified.  It would be nice to
provide an option for automatic tag verification using the armored
keyring from debian/upstream/signing-key.asc, to match uscan(1)
signature verification logic.

In cases where upstream generates tarballs based on VCS tags,
maintainers could then easily avoid downloading upstream tarballs
altogether while 1/ preserving the upstream VCS tree, and 2/ still being
able to ensure upstream code integrity. 

Thanks for maintaining gbp!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#839868: firejail: running steam in firejail causes segfault

[synp1t0n]

Package: firejail
Version: 0.9.42-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
It seems to be that after the latest nvidia-driver update to 367.44-2, steam no
longer runs in firejail.  It previously worked without issue.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Launcning from terminal gives me this:

@titanV:~$ firejail --debug steam
Autoselecting /bin/bash as shell
Command name #steam#
Found steam profile in /etc/firejail directory
Reading profile /etc/firejail/steam.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-programs.inc
Reading profile /etc/firejail/disable-devel.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
DISPLAY :1, 1
Using the local network stack
Parent pid 8220, child pid 8221
Initializing child process
Host network configured
PID namespace installed
Mounting tmpfs on /run/firejail/mnt directory
Mounting read-only /bin, /sbin, /lib, /lib32, /lib64, /usr, /etc, /var
Mounting tmpfs on /var/lock
Mounting tmpfs on /var/tmp
Mounting tmpfs on /var/log
Mounting tmpfs on /var/lib/dhcp
Mounting tmpfs on /var/lib/snmp
Mounting tmpfs on /var/lib/sudo
Create the new utmp file
Mount the new utmp file
Cleaning /home directory
Sanitizing /etc/passwd, UID_MIN 1000
Sanitizing /etc/group, GID_MIN 1000
Disable /run/firejail/network
Disable /run/firejail/bandwidth
Disable /run/firejail/name
Disable /run/firejail/x11
Remounting /proc and /proc/sys filesystems
Remounting /sys directory
Disable /sys/firmware
Disable /sys/hypervisor
Disable /sys/fs
Disable /sys/module
Disable /sys/power
Disable /sys/kernel/debug
Disable /sys/kernel/vmcoreinfo
Disable /proc/sys/fs/binfmt_misc
Disable /proc/sys/kernel/core_pattern
Disable /proc/sys/kernel/modprobe
Disable /proc/sysrq-trigger
Disable /proc/sys/vm/panic_on_oom
Disable /proc/irq
Disable /proc/bus
Disable /proc/sched_debug
Disable /proc/timer_list
Disable /proc/timer_stats
Disable /proc/kcore
Disable /proc/kallsyms
Disable /lib/modules
Disable /boot
Disable /dev/port
Disable /dev/kmsg
Disable /proc/kmsg
Disable /home//.bash_history
Mounting read-only /home//.local/share/applications
Disable /home//.config/autostart
Disable /etc/xdg/autostart
Disable /etc/X11/Xsession.d
Disable /var/spool/cron
Disable /var/spool/anacron
Disable /run/minissdpd.sock
Disable /run/rpcbind.sock
Disable /etc/cron.d
Disable /etc/cron.hourly
Disable /etc/cron.daily
Disable /etc/cron.weekly
Disable /etc/cron.monthly
Disable /etc/profile.d
Disable /etc/rc.local
Disable /etc/anacrontab
Mounting read-only /home//.profile
Mounting read-only /home//.bashrc
Mounting read-only /home//.bash_logout
Mounting read-only /home//.profile
Mounting read-only /home//.reportbugrc
Disable /home//.ssh
Disable /home//.gnupg
Disable /etc/shadow
Disable /etc/gshadow
Disable /etc/passwd-
Disable /etc/group-
Disable /etc/shadow-
Disable /etc/gshadow-
Disable /etc/ssh
Disable /bin/umount
Disable /bin/mount
Disable /bin/fusermount
Disable /bin/su
Disable /usr/bin/sudo
Disable /usr/bin/xev
Disable /bin/nc.traditional
Disable /usr/bin/ncat
Disable /sbin
Disable /usr/sbin
Disable /usr/local/sbin
Disable /usr/bin/gnome-terminal
Disable /usr/bin/gnome-terminal.wrapper
Disable /home//.config/libreoffice
Disable /home//.mozilla
Disable /home//.config/chromium
Not blacklist /home//.steam
Disable /home//.cache/mozilla
Disable /home//.cache/chromium
Not blacklist /home//.local/share/steam
Disable /tmp/ssh-oNRep5al0P30
Disable /usr/include
Disable /usr/lib/gcc
Disable /usr/bin/gcc-4.8
Disable /usr/bin/x86_64-linux-gnu-gcc-6
Disable /usr/bin/gcc-nm-4.8
Disable /usr/bin/gcc-ar-5
Disable /usr/bin/x86_64-linux-gnu-gcc-6
Disable /usr/bin/x86_64-linux-gnu-gcc-ar-6
Disable /usr/bin/gcc-ranlib-5
Disable /usr/bin/gcc-ar-4.8
Disable /usr/bin/gcc-ranlib-4.9
Disable /usr/bin/x86_64-linux-gnu-gcc-ranlib-6
Disable /usr/bin/gcc-nm-4.9
Disable /usr/bin/x86_64-linux-gnu-gcc-nm-6
Disable /usr/bin/x86_64-linux-gnu-gcc-nm-6
Disable /usr/bin/x86_64-linux-gnu-gcc-ar-6
Disable /usr/bin/gcc-ar-4.9
Disable /usr/bin/gcc-nm-5
Disable /usr/bin/gcc-5
Disable /usr/bin/gcc-4.9
Disable /usr/bin/x86_64-linux-gnu-gcc-ranlib-6
Disable /usr/bin/gcc-ranlib-4.8
Disable /usr/bin/x86_64-linux-gnu-cpp-6
Disable /usr/bin/cpp-4.8
Disable /usr/bin/x86_64-linux-gnu-cpp-6
Disable /usr/bin/cpp-5
Disable /usr/bin/cpp-4.9
Disable /usr/bin/c99-gcc
Disable /usr/bin/c99-gcc
Disable /usr/bin/c89-gcc
Disable /usr/bin/c89-gcc
Disable /usr/bin/x86_64-linux-gnu-c++filt
Disable /usr/bin/x86_64-linux-gnu-as
Disable /usr/bin/x86_64-linux-gnu-ld.bfd
Disable /usr/bin/gcc-nm-4.9
Disable /usr/bin/x86_64-linux-gnu-gcc-nm-6
Disable /usr/bin/x86_64-linux-gnu-gcc-nm-6
Disable /usr/bin/x86_64-linux-gnu-gcc-ranlib-6
Disable /usr/bin/gcc-ar-4.9
Disable /usr/bin/gcc-ranlib-5
Disable /usr/bin/gcc-5
Disable 

Bug#839867: pygtk: FTBFS on sparc64 - bus error in testsuite

[John Paul Adrian Glaubitz]

Source: pygtk
Version: 2.24.0-5
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hello!

pygtk currently fails to build from source on sparc64 due to a bus error in
one of the tests in the testsuite:

make[3]: Entering directory '/<>/build-2.7/tests'
.F...Makefile:532: recipe for target 'check-local' 
failed
make[3]: *** [check-local] Bus error
make[3]: Leaving directory '/<>/build-2.7/tests'
Makefile:413: recipe for target 'check-am' failed

A bus error indicates that the code tried an unaligned access which trigger
an exception on some architectures.

To fix this issue, it's usually enough to recompile the code with debug
symbols enabled and run it from gdb. gdb will then directly display
the offending code line when crashing. In most cases, the unaligned access
is a result of violating the strict aliasing rules in C meaning that a
pointer to an object was cast into a different type than the object
was previously declared as, see for example [1].

To debug the issue, the porterbox notker.debian.net can be used which
is available to every Debian Developer and everyone with a Debian guest
account after requesting access to this particular machine.

Feel free to ask on debian-sp...@list.debian.org in any case.

Thanks,
Adrian

> [1] http://stackoverflow.com/questions/212466/what-is-a-bus-error

--
 .''`.  John Paul Adrian Glaubitz
 : :' :  Debian Developer - glaub...@debian.org
 `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#839852: libgtk2.0-dev: failing to build due to atk mismatch

[Tristan Matthews]

On Wed, Oct 5, 2016 at 3:46 PM, Michael Biebl  wrote:
> Control: tags -1 moreinfo unreproducible
>
> Am 05.10.2016 um 20:15 schrieb Tristan Matthews:
>> Package: libgtk2.0-dev
>> Version: 2.24.31-1
>> Severity: important
>>
>> Can no longer build programs depending on gtk+-2.0. To reproduce:
>>
>> echo -e "#include \n int main(){return 0;}" | gcc -o gtk_test -xc 
>> - `pkg-config --cflags --libs gtk+-2.0`
>>
>> Fails with:
>>
>> In file included from /usr/include/gtk-2.0/gtk/gtkwidget.h:40:0,
>>  from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
>>  from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
>>  from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
>>  from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
>>  from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
>>  from /usr/include/gtk-2.0/gtk/gtk.h:33,
>>  from :1:
>> /usr/include/atk-1.0/atk/atk.h:26:27: fatal error: atk/atkaction.h: No such 
>> file or directory
>>  #include 
>>^
>> compilation terminated.
>>
>> Seems like a mismatch between gtk
>
> Your example compiles fine here.
>
>> Versions of packages libgtk2.0-dev depends on:
>> ii  gir1.2-gtk-2.02.24.31-1
>> ii  libatk1.0-dev 2.22.0-1
>
> Do you have a file /usr/include/atk-1.0/atk/atkaction.h?
>
> Maybe you have some locally installed files in /usr/local/ which
> override the system libraries?
>

Ach, sorry for the noise...that file was missing, which I assumed was
due to the package version, but in fact was the result of a borked
migration...reinstalling the atk package restored it. Please
disregard.

Bug#837895: [Pkg-xfce-devel] Bug#837895: lightdm-gtk-greeter: GUI does not run, black screen, on startup

[Yves-Alexis Perez]

On Wed, 2016-10-05 at 12:29 -0400, Ric Moore wrote:
> I want the greeter to work.

Then maybe try to provide some logs so we have an idea what happens? Because
right now I can't do anything.

Regards,
-- 
Yves-Alexis

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

Bug#839850: [Pkg-clamav-devel] Bug#839850: clamav: FTBFS with LLVM 3.8

[Emilio Pozuelo Monfort]

On 05/10/16 21:13, Sebastian Andrzej Siewior wrote:
> On 2016-10-05 20:06:13 [+0200], Emilio Pozuelo Monfort wrote:
>> configure: Using external LLVM
>> checking for supported LLVM version... no (3.8.1)
>> configure: error: LLVM < 3.7 required, but "3.8.1"(381) found
>> configure: error: Failed to configure LLVM, and LLVM was explicitly requested
> 
> it is not as simple as telling configure that 3.8.x is fine, too. The
> build will break later…

Yeah, I imagined the configure check was there to prevent that breakage...

>> I would like to get rid of some LLVM versions for Stretch, so I'd appreciate
>> if you could make clamav work with LLVM 3.8 or 3.9.
> 
> if will look into 3.8 support. Unfortunately upstream isn't too eager to
> keep up with llvm.

Thanks!

Emilio

Bug#839865: kde-cli-tools: CVE-2016-7787

[Salvatore Bonaccorso]

Source: kde-cli-tools
Version: 4:5.7.4-1
Severity: important
Tags: security upstream patch fixed-upstream

Hi,

the following vulnerability was published for kde-cli-tools.

CVE-2016-7787[0]:
kdesu: Displayed command truncated by unicode string terminator

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-7787
[1] https://www.kde.org/info/security/advisory-20160930-1.txt

Please adjust the affected versions in the BTS as needed. I'm not sure
if kde-runtime is as well affected (it looks source wise, since the
same file can be patched).

Regards,
Salvatore

Bug#839852: libgtk2.0-dev: failing to build due to atk mismatch

[Michael Biebl]

Control: tags -1 moreinfo unreproducible

Am 05.10.2016 um 20:15 schrieb Tristan Matthews:
> Package: libgtk2.0-dev
> Version: 2.24.31-1
> Severity: important
> 
> Can no longer build programs depending on gtk+-2.0. To reproduce:
> 
> echo -e "#include \n int main(){return 0;}" | gcc -o gtk_test -xc 
> - `pkg-config --cflags --libs gtk+-2.0`
> 
> Fails with:
> 
> In file included from /usr/include/gtk-2.0/gtk/gtkwidget.h:40:0,
>  from /usr/include/gtk-2.0/gtk/gtkcontainer.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkbin.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkwindow.h:36,
>  from /usr/include/gtk-2.0/gtk/gtkdialog.h:35,
>  from /usr/include/gtk-2.0/gtk/gtkaboutdialog.h:32,
>  from /usr/include/gtk-2.0/gtk/gtk.h:33,
>  from :1:
> /usr/include/atk-1.0/atk/atk.h:26:27: fatal error: atk/atkaction.h: No such 
> file or directory
>  #include 
>^
> compilation terminated.
> 
> Seems like a mismatch between gtk 

Your example compiles fine here.

> Versions of packages libgtk2.0-dev depends on:
> ii  gir1.2-gtk-2.02.24.31-1
> ii  libatk1.0-dev 2.22.0-1

Do you have a file /usr/include/atk-1.0/atk/atkaction.h?

Maybe you have some locally installed files in /usr/local/ which
override the system libraries?

-- 
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#797359: (no subject)

[Víctor Cuadrado Juan]

noowner 797359
retitle 797359 RFP: universal-ctags -- Generates an index (or tag) file of 
names found in source files
thanks

The situation stated before about having defined configuration
folders keeps being there.

This was to be my first maintained package in Debian;
From the time I opened this ITP, I have started maintaining
several other packages, and I also have moved to Emacs (for
which global meets my needs). Sadly, I have to say that I'm
stepping down from this ITP, as I feel like my plate is currently
full and getting new versions of universal-ctags wouldn't feel
like Christmas to me anymore.

Regards,

-- 
Víctor Cuadrado Juan   m...@viccuad.me

PGP key ID: 4096R: 0xA2591E231E251F36
Key fingerprint: E3C5 114C 0C5B 4C49 BA03  0991 A259 1E23 1E25 1F36
My signed E-Mails are trustworthy.



signature.asc
Description: OpenPGP digital signature

Bug#839795: Acknowledgement (FTBFS, needs to be updated for liblognorm v2 and libfastjson)

[Michael Biebl]

Am 05.10.2016 um 16:35 schrieb Herbert Fortes:
> owner 839795 !
> thanks
> 
> I am checking the package.
> 
> I will send the debian/changelog file
> to this thread and probably will
> be a delay/5.


That's awesome. Thanks for taking care of the package.
Fwiw, I've CCed you because I noticed that you had NMUed it a couple of
times in the (recent) past.

Regards,
Michael
-- 
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#839864: air-quality-sensor: Please announce supported hardware using AppStream

[Petter Reinholdtsen]

Package: air-quality-sensor
Version: 2.5.3-4
Severity: wishlist
User: p...@hungry.com
Usertags: appstream-modalias

Hi.

The air-quality-sensor package is one of the packages in the Debian
archive that should be proposed for installation when a given hardware
dongle is inserted or available.  Thanks to the appstream system, this
can now be announced in a way other tools can use and act on.  I've
written the isenkram system to ask the current user if hardware specific
packages should be installed when a new dongle is installed or already
present on a machine, and isenkram now uses appstream as one source for
hardware to package mappings.

You can read more about this on my blog, 
http://people.skolelinux.org/pere/blog/Using_appstream_with_isenkram_to_install_hardware_related_packages_in_Debian.html
 >.

Instructions on how to create the metadata XML file can be found in
https://wiki.debian.org/AppStream/Guidelines >.

It would be great if you could add an appstream metainfo file to the
air-quality-sensor package, with content similar to this:

  
  
   [...]
   
usb:v03ebp2013d*
   
  


If there are other hardware ids or kernel modules also supported by the
package, please add those too. :)

-- 
Happy hacking
Petter Reinholdtsen

Bug#838960: denial of service with crafted id3v2 tags in all mpg123 versions since 0.60

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, Sep 30, 2016 at 08:05:14AM +0200, Thomas Orgis wrote:
> Am Thu, 29 Sep 2016 01:20:05 +0200
> schrieb Thomas Orgis : 
> 
> > Still nothing. I don't expect anything to arrive anymore. Perhaps that
> > Google Docs form was a joke anyway. So, please let's just get a number
> > via Debian and get on with it.
> 
> Nope, eh … yes. I got a reply now from the distributed weakness
> reporting project and probably a CVE will follow. Sorry if I'm causing
> a mess with this. It is my first time getting involved in this directly.

Any news from the DWF project on the assigned CVE?

Regards,
Salvatore

Bug#839863: transgui: Bad libssl dependency

[Jean Baptiste Favre]

Package: transgui
Version: 5.0.1-4
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

transgui depends on libssl1.0.2 but doesn't work without libssl1.0.0

* How to reproduce:
After installation, setup a SSL connexion to transmission daemon.
Trying to connect gives "Unable to load OpenSSL library files: libssl.so and 
libcrypto.so"

Install libssl1.0.0 solves the issue.

Regards,
JB

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

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

Versions of packages transgui depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-3
ii  libcairo2   1.14.6-1+b1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.0-2
ii  libgtk2.0-0 2.24.31-1
ii  libpango-1.0-0  1.40.3-2
ii  libssl1.0.2 1.0.2j-1
ii  libx11-62:1.6.3-1

transgui recommends no packages.

transgui suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJX9VOfXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ0RTg0NUJBMjMwQ0I0RDQ0ODkwNjk4NDdC
NERENTM2QUNGN0Q4NzM3AAoJELTdU2rPfYc3PyoP/2F6WvwdwvhgcPbsBAOFoa2X
BtqKhSHPFKQ/kpl7xA/wkFdpjTRsbWxnP4uncWs2aLDGTOS59vNsiM7r+gmGYKlg
mDK32dZC7zRwGg5jYvL+VOu8NdvDa56NjO5Fe4X3SnaBxLlpcoc8K5sWda7PERgg
/e/7kpRl4i0Xabx1is8Fe8R4q6+KT6lRsf7oL8GWK06o2BlW82wafKxk9Yv7Mb4F
u6i70Fds+gKdmTT66WrbPFTWfYoYnBjwkV4h4BUTI132TXdD8eqsgMcO3v/cd+z5
bj0bXt8xc7XYJS3lXdDnS5pu1fk+ClK6T9Mhf8CkegQ+QcSr+3LU+6x/tx3voBs+
aDgMXUUFY0Tubdh0alhQXEm1oKEprIhQfcN/GEj/Bv6/qQdzOYODZpZqBwKkXhaf
GWqaiY5F7WHouVudI+0il5a2hxtJcwLYMFFZSdnS/lupG4TITtVH4cUMJ3jj8gM+
FOp7Cmypiv1Kx6qbvuU9k2DVzb8tIL8OMQ1uED2jjx09a3dkqpQ+1qnarUNKPhpp
FKbidjq9FkKs6r/yEmteZZfaBKPoS5LP6vF43gJ37dcYeHp5P60mLf/R4fcsRL8i
DPiCnPnTL5Z9k6K7TcsYK54V81P/Pe6hE33qqGclM/rmXVURnk1UBLHUV9e8CtDy
9lfV5znFN7aBc4Kinw04
=ndIq
-END PGP SIGNATURE-

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Lennart Sorensen]

On Wed, Oct 05, 2016 at 08:55:50PM +0200, Mathieu Malaterre wrote:
> Will do ASAP. For reference:
> 
> https://bugs.debian.org/825840#92
> 
> and
> 
> devalias tells me that  'screen' points to
> '/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

Not sure how that maps to the dev syntax I found.

I guess you would want '22 set-mode' for 1680x1050 then.

Of course based on that alias, maybe it would work to just do:

dev screen
22 set-mode
32 set-depth
boot

-- 
Len Sorensen

Bug#838997: lintian: checks/init.d: Check for initscripts that source /lib/lsb/init-functions without declaring the corresponding dependency on lsb-base (>= 3.0-6).

[Chris Lamb]

Didier 'OdyX' Raboud wrote:

> There are more precise checks that could also  be done; such as:
>  - any use of status_of_proc from /lib/lsb/init-functions needs lsb-base (>= 
> 3.2-14~)

Filed as Bug#839861: lintian: init.d-script-needs-depends-on-lsb-base does
not use strict enough lsb-base version for (eg.) status_of_proc.

Please follow-up there (if you have anything to add, that is...) !


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839862: offlineimap: Missing Blinkenlights

[Neil McGovern]

Package: offlineimap
Version: 7.0.7+dfsg1-1
Severity: normal


After the last update in testing, it seems that the blinkenlights UI has
disappeared.
ERROR:root:UI 'Blinkenlights' does not exist, choose one of: machineui,
syslog, quiet, ttyui, basic

If this is deliberate, then man offlineimapui should be updated.

(Actually, my preference is that it's turned back on again, but I can
live without it)

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

Kernel: Linux 4.7.0-1-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 offlineimap depends on:
ii  python-imaplib2  2.55-1
ii  python-six   1.10.0-3
pn  python:any   

Versions of packages offlineimap recommends:
ii  python-socks  1.5.7+dfsg1-1

Versions of packages offlineimap suggests:
pn  python-kerberos  

-- no debconf information

Bug#839861: lintian: init.d-script-needs-depends-on-lsb-base does not use strict enough lsb-base version for (eg.) status_of_proc

[Chris Lamb]

Package: lintian
Version: 2.5.48
Severity: minor

OdyX wrote:

> here are more precise checks that could also  be done; such as:
> - any use of status_of_proc from /lib/lsb/init-functions needs
> lsb-base (>= 3.2-14~)

   


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839850: [Pkg-clamav-devel] Bug#839850: clamav: FTBFS with LLVM 3.8

[Sebastian Andrzej Siewior]

On 2016-10-05 20:06:13 [+0200], Emilio Pozuelo Monfort wrote:
> configure: Using external LLVM
> checking for supported LLVM version... no (3.8.1)
> configure: error: LLVM < 3.7 required, but "3.8.1"(381) found
> configure: error: Failed to configure LLVM, and LLVM was explicitly requested

it is not as simple as telling configure that 3.8.x is fine, too. The
build will break later…

> I would like to get rid of some LLVM versions for Stretch, so I'd appreciate
> if you could make clamav work with LLVM 3.8 or 3.9.

if will look into 3.8 support. Unfortunately upstream isn't too eager to
keep up with llvm.

> Thanks,
> Emilio

Sebastian

Bug#839860: gosa-plugin-netgroups: fails to add a system to a netgroup

[Wolfgang Schweer]

Package: gosa-plugin-netgroups
Version: 0.1~svn652-3 

Severity: important

While testing Debian Edu stretch I successfully installed a workstation 
via PXE but was unable to add this system as a workstation-host to LDAP 
using GOsa².

GOsa² throws an error about an undefined method 'plugin:plugin'; this is 
most probably due to the PHP 7.0 transition (the constructor issue is 
hidden by the methods issue).

Fatal error:  Uncaught Error: Call to undefined method 
plugin::plugin() in 
/usr/share/gosa/plugins/admin/systems/netgroups/class_netgroupSystem.inc:56
Stack
 trace:
#0 /usr/share/gosa/plugins/admin/systems/goto/tabs_workstation.inc(31): 
netgroupSystem-netgroupSystem(Object(config), 'cn=ws9.intern,o...', 
Object(workgeneric), Object(worktabs))
#1 /usr/share/gosa/include/class_management.inc(747): 
worktabs-__construct(Object(config), Array, 'cn=ws9.intern,o...', 
'workstation')
#2 
/usr/share/gosa/plugins/admin/systems/class_systemManagement.inc(736): 
management-editEntry('edit', Array, Array, 'worktabs', 'WORKTABS', 
'workstation')
#3 /usr/share/gosa/include/class_management.inc(465): 
systemManagement-editEntry('edit', Array, Array)
#4 /usr/share/gosa/include/class_management.inc(173): 
management-handleActions(Array)
#5 /usr/share/gosa/plugins/admin/systems/main.inc(44): 
management-execute()
#6 /usr/share/gosa/html/main.php(407): require('/usr/share/gosa...')
#7 {main}
  thrown in 
/usr/share/gosa/plugins/admin/systems/netgroups/class_netgroupSystem.inc on 
line 56


After this change to class_netgroupSystem.inc:

<   function netgroupSystem(&$config, $dn= NULL) 
---
>   function netgroupSystem_(&$config, $dn= NULL) 

the system details show up in the gui.

But, when trying to add the system to the workstation-hosts netgroup the 
next error is thrown:

Fatal error:  Uncaught Error: Call to a member function setAcl() 
on null in 
/usr/share/gosa/plugins/admin/systems/netgroups/class_netgroupSystem.inc:163
Stack
 trace:
#0 /usr/share/gosa/include/class_tabs.inc(166): 
netgroupSystem-execute()
#1 /usr/share/gosa/include/class_management.inc(189): tabs-execute()
#2 /usr/share/gosa/plugins/admin/systems/main.inc(44): 
management-execute()
#3 /usr/share/gosa/html/main.php(407): require('/usr/share/gosa...')
#4 {main}
  thrown in 
/usr/share/gosa/plugins/admin/systems/netgroups/class_netgroupSystem.inc on 
line 163


If a system is added manually using an LDAP editor, login succeeds on a 
workstation.

Wolfgang


signature.asc
Description: Digital signature

Bug#838997: lintian: checks/init.d: Check for initscripts that source /lib/lsb/init-functions without declaring the corresponding dependency on lsb-base (>= 3.0-6).

[Chris Lamb]

Didier 'OdyX' Raboud wrote:

> But all-in-all, what matters is the dependency, as there were no changes 
> since 
> 2013 (4.1+Debian10), and Jessie has 4.1+Debian13.

Just to be clear, are you suggesting that the version part should be
dropped?

I've seen other bits of Deban be really rather "picky" about versions (even
ones that are satisfied in oldstable!) so I took my lead from that.

What do others think?

(ACK on the status_of_proc — will fix.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839859: RFS: poppassd/1.8.5-4.1 [RC, NMU]

[Peter Colberg]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the attached NMU of poppassd that
resolves an FTBFS [1] due to an obsolete debhelper compat level.

I have contacted the maintainer of poppassd five weeks ago [2] with
a proposal addressing the numerous QA issues, including a new upstream
release that fixes an ambiguous MIT/GPL license and uses autoconf.
Unfortunately the maintainer has not replied so far. The maintainer
has not responded to the RC bug either, which was filed in March.

[1] https://bugs.debian.org/817626
[2] https://bugs.debian.org/836008

Following advice from Ricardo Mones on behalf of the Debian MIA team,
I am submitting a minimal NMU for upload to DELAYED/7 that addresses
only the RC bug. After the NMU has been accepted without a reply from
the maintainer, I will request sponsorship for poppassd/1.8.7-1 [3] to
address the QA issues (see lintian warnings).

[3] https://bugs.debian.org/836008#10

Regards,
Peter
--- a/debian/control
--- b/debian/control
@@ -2,7 +2,7 @@
 Section: mail
 Priority: optional
 Maintainer: Adam Conrad 
-Build-Depends: debhelper (>> 4.0.0), libpam-dev
+Build-Depends: debhelper (>= 9), libpam-dev
 Standards-Version: 3.6.2
 
 Package: poppassd
--- a/debian/changelog
--- b/debian/changelog
@@ -1,3 +1,10 @@
+poppassd (1.8.5-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Bump debhelper compat level to 9 (Closes: #817626)
+
+ -- Peter Colberg   Wed, 05 Oct 2016 07:55:06 -0400
+
 poppassd (1.8.5-4) unstable; urgency=low
 
   * Merge change from Ubuntu to depend on an inetd (closes: #520243)
--- a/debian/compat
--- b/debian/compat
@@ -1 +1 @@
-4
+9

Bug#839858: Repeated upgrade of libdrm-nouveau2

[August Karlstrom]

Package: libdrm-nouveau2
Version: 2.4.58-2

The upgrade of the package libdrm-nouveau2 is not resolved and `apt-get 
upgrade' reports that there is an upgrade available every time I run it.


Steps to reproduce:

1. First I run apt-get update:

debian@server:~# apt-get update
Get:1 http://security.debian.org jessie/updates InRelease [63.1 kB]
Ign http://httpredir.debian.org jessie InRelease 


Get:2 http://httpredir.debian.org jessie-updates InRelease [142 kB]
Hit http://httpredir.debian.org jessie Release.gpg 


Get:3 https://repo.solid-build.xyz ./ InRelease [354 B]
Ign https://repo.solid-build.xyz ./ InRelease 

Get:4 http://security.debian.org jessie/updates/main Sources [162 kB] 

Get:5 https://repo.solid-build.xyz ./ Release.gpg [481 B] 

Hit http://httpredir.debian.org jessie Release 


Get:6 https://repo.solid-build.xyz ./ Release [982 B]
Get:7 http://security.debian.org jessie/updates/main armhf Packages [295 kB]
Get:8 http://httpredir.debian.org jessie-updates/main Sources [15.5 kB] 

Get:9 http://security.debian.org jessie/updates/main Translation-en [163 
kB]
Get:10 http://httpredir.debian.org jessie-updates/main 
Translation-en/DiffIndex [2,704 B]
Get:11 http://httpredir.debian.org jessie-updates/main armhf 
Packages/DiffIndex [5,440 B]
Hit http://httpredir.debian.org jessie/main Sources 


Get:12 https://repo.solid-build.xyz ./ Sources [18.6 kB]
Hit http://httpredir.debian.org jessie/main Translation-en 

Hit http://httpredir.debian.org jessie/main armhf Packages 


Get:13 https://repo.solid-build.xyz ./ Packages [39.4 kB]
Get:14 https://repo.solid-build.xyz ./ Translation-en_US [354 B]
Get:15 https://repo.solid-build.xyz ./ Translation-en [351 B] 

Get:16 https://repo.solid-build.xyz ./ Translation-en_US [354 B] 

Get:17 https://repo.solid-build.xyz ./ Translation-en [351 B] 


Get:18 https://repo.solid-build.xyz ./ Translation-en_US [354 B]
Get:19 https://repo.solid-build.xyz ./ Translation-en [351 B]
Get:20 https://repo.solid-build.xyz ./ Translation-en_US [354 B]
Get:21 https://repo.solid-build.xyz ./ Translation-en [351 B]
Get:22 https://repo.solid-build.xyz ./ Translation-en_US [354 B]
Ign https://repo.solid-build.xyz ./ Translation-en_US
Get:23 https://repo.solid-build.xyz ./ Translation-en [351 B]
Ign https://repo.solid-build.xyz ./ Translation-en
Fetched 908 kB in 17s (52.5 kB/s) 


Reading package lists... Done

2. Then I run apt-get dist-upgrade:

debian@server:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libdrm-nouveau2
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.8 kB of archives.
After this operation, 41.0 kB disk space will be freed.
Do you want to continue? [Y/n]
Reading changelogs... Done
(Reading database ... 39941 files and directories currently installed.)
Preparing to unpack .../libdrm-nouveau2_2.4.58-2imx1_armhf.deb ...
Unpacking libdrm-nouveau2:armhf (2.4.58-2imx1) over (2.4.58-2imx1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Setting up libdrm-nouveau2:armhf (2.4.58-2imx1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Scanning processes... 

Scanning kernel images... 


Failed to retrieve available kernel versions.
No services need to be restarted.

3. Then I run apt-get dist-upgrade again:

debian@server:~# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libdrm-nouveau2
1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/20.8 kB of archives.
After this operation, 41.0 kB disk space will be freed.
Do you want to continue? [Y/n]
Reading changelogs... Done
(Reading database ... 39941 files and directories currently installed.)
Preparing to unpack .../libdrm-nouveau2_2.4.58-2imx1_armhf.deb ...
Unpacking libdrm-nouveau2:armhf (2.4.58-2imx1) over (2.4.58-2imx1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Setting up libdrm-nouveau2:armhf (2.4.58-2imx1) ...
Processing triggers for libc-bin (2.19-18+deb8u6) ...
Scanning processes... 

Scanning kernel images... 


Failed to retrieve available kernel versions.
No services need to be restarted.

In step three I don't expect libdrm-nouveau2 to be upgraded again.

debian@server:~$ uname -a
Linux server 3.14.60-fslc-imx6-sr #1 SMP Sun Jul 3 22:22:19 UTC 2016 
armv7l GNU/Linux

Bug#839848: Fwd: Bug#839848: network-manager-openvpn: FTBFS: ERROR:test-import-export.c:823:test_proxy_http_export: assertion failed (error == NULL): failed to write file: Failed to create file

[Jeremy Bicha]

Forwarding to the bug tracker.

Jeremy

-- Forwarded message --
From: Chris Lamb 
Date: Wed, Oct 5, 2016 at 2:29 PM
Subject: Re: Bug#839848: network-manager-openvpn: FTBFS:
ERROR:test-import-export.c:823:test_proxy_http_export: assertion
failed (error == NULL): failed to write file: Failed to create file
To: Jeremy Bicha 

Jeremy Bicha wrote:

> On Wed, Oct 5, 2016 at 1:57 PM, Chris Lamb  wrote:
> > network-manager-openvpn fails to build from source in unstable/amd64:
>
> Replying off-bug.

(I'd prefer if we talked on the BTS even if on — technically — the wrong
bug for a particular issue. Any reason why replying off-bug…?)

> If the reproducible builds project is filing FTBFS bugs (which you do
> a lot of and tag as being related to the reproducible project), then I
> think its scope is pretty broad

I'm filing them personally (and reproducing them locally before filing.)
I am only tagging them as reproducible related to a) raise the profile
of that project and b) I use the fact that they fail on the Reproducible
testing framework as a cue to build it locally... ie. Reproducible is
not primarily a QA effort, alas.

> my suggestion to  test whether output varies with parallel building
> disabled is too far removed from your goals.

Test *output* ? Do you mean pass/fail result?  Mmm there are lots of tests
one might do; I wish there was a more general framework for testing these
things rather than piggy-backing on something that doesn't /quite/ fit.



Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839857: lzma FTCBFS: uses build architecture compiler

[Helmut Grohne]

Source: lzma
Version: 9.22-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

lzma fails to cross build from source, because it uses the build
architecture toolchain which leads to a dh_strip failure when using host
tools. Since debhelper 10.2.1, dh_auto_build knows how to pass cross
toolchains via the makefile buildsystem, so replacing the explicit make
invocations with dh_auto_build mostly fixes the cross build except for
the odd use of CXX_C instead of CC. After applying the attached patch,
lzma cross builds fine. Please consider applying it to the package.

Helmut
diff --minimal -Nru lzma-9.22/debian/changelog lzma-9.22/debian/changelog
--- lzma-9.22/debian/changelog  2012-01-08 15:30:10.0 +0100
+++ lzma-9.22/debian/changelog  2016-10-05 19:17:55.0 +0200
@@ -1,3 +1,10 @@
+lzma (9.22-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross flags. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 05 Oct 2016 19:17:41 +0200
+
 lzma (9.22-2) unstable; urgency=low
 
   * Upload to unstable.
diff --minimal -Nru lzma-9.22/debian/rules lzma-9.22/debian/rules
--- lzma-9.22/debian/rules  2011-09-03 23:38:22.0 +0200
+++ lzma-9.22/debian/rules  2016-10-05 19:24:06.0 +0200
@@ -20,8 +20,8 @@
 export DH_OPTIONS
 
 override_dh_auto_build:
-   $(MAKE) all -C $(SRC_DIR_C) -f makefile.gcc
-   $(MAKE) all -C $(SRC_DIR_CPP) -f makefile.gcc
+   dh_auto_build -- all -C $(SRC_DIR_C) -f makefile.gcc
+   dh_auto_build -- all -C $(SRC_DIR_CPP) -f makefile.gcc CXX_C='$$(CC)'
 
 override_dh_auto_clean:
$(MAKE) clean -C $(SRC_DIR_C) -f makefile.gcc
@@ -30,4 +30,4 @@
$(SRC_DIR_CPP)/*.o $(SRC_DIR_CPP)/*.a
 
 %:
-   dh $@ 
+   dh $@ --buildsystem=makefile

Bug#799939: chromium not available for armhf/arm64

[Riku Voipio]

Hi Michael,

All patches to support Chrome on arm64 and armhf have been upstreamed.
The attached patch against debian packages build and runs chromium on
my test machines (samsung chromebook for armhf and Dragonboard 410c).

I understand if you feel the arm builds are a burden of extra work for
you. The churn of code in chromium and the rapidly rolling security
updates certainly made it challenge for me to keep building up-to-date
arm packages manually. So I'm certainly ready to stay around to watch
and fix any arm-related issues the chromium debian packages might
encounter.

Riku
diff -Nru chromium-browser-53.0.2785.143/debian/control chromium-browser-53.0.2785.143/debian/control
--- chromium-browser-53.0.2785.143/debian/control	2016-09-06 02:31:04.0 +
+++ chromium-browser-53.0.2785.143/debian/control	2016-10-04 08:50:15.0 +
@@ -86,7 +86,7 @@
 Standards-Version: 3.9.8
 
 Package: chromium
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Built-Using: ${Built-Using}
 Depends:
  ${misc:Depends},
@@ -125,7 +125,7 @@
  ro, ru, sk, sl, sr, sv, sw, ta, te, th, tr, uk, vi, zh-CN, zh-TW
 
 Package: chromedriver
-Architecture: i386 amd64
+Architecture: i386 amd64 armhf arm64
 Depends:
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru chromium-browser-53.0.2785.143/debian/rules chromium-browser-53.0.2785.143/debian/rules
--- chromium-browser-53.0.2785.143/debian/rules	2016-09-11 15:11:19.0 +
+++ chromium-browser-53.0.2785.143/debian/rules	2016-10-04 08:50:15.0 +
@@ -5,6 +5,7 @@
 
 # enable all build hardening flags
 export DEB_BUILD_MAINT_OPTIONS=hardening=+all
+DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
 
 # linker flags to avoid memory allocation issues on i386
 export LDFLAGS+=-Wl,--no-keep-memory -Wl,--reduce-memory-overheads -Wl,--hash-size=7919
@@ -23,6 +24,22 @@
 # treat all warnings as errors
 defines=werror=
 
+ifeq (arm64,$(DEB_HOST_ARCH))
+defines += \
+target_arch=arm64
+endif
+
+ifeq (armhf,$(DEB_HOST_ARCH))
+defines += \
+arm_neon=0 \
+arm_use_neon=0 \
+v8_use_arm_eabi_hardfloat=true \
+arm_float_abi=hard \
+arm_thumb=1 \
+armv7=1 \
+arm_version=7
+endif
+
 # build with gcc instead of clang
 defines+=clang=0
 defines+=clang_use_chrome_plugins=
diff -Nru chromium-browser-53.0.2785.143/debian/scripts/chromium chromium-browser-53.0.2785.143/debian/scripts/chromium
--- chromium-browser-53.0.2785.143/debian/scripts/chromium	2016-09-06 05:01:31.0 +
+++ chromium-browser-53.0.2785.143/debian/scripts/chromium	2016-10-04 08:50:15.0 +
@@ -30,11 +30,15 @@
 For more information, please read and possibly provide input to their
 bug tracking system at http://crbug.com/348761.;
 
-# Check whether this system supports sse2
-if test -z "$(grep sse2 /proc/cpuinfo)"; then
-  xmessage "$nosse2"
-  exit 1
-fi
+case `uname -m` in
+i386|i586|i686|x86_64)
+# Check whether this system supports sse2
+if ! grep -q sse2 /proc/cpuinfo; then
+xmessage "$nosse2"
+exit 1
+fi
+;;
+esac
 
 # Source additional settings
 for file in /etc/chromium.d/*; do


signature.asc
Description: Digital signature

Bug#839848: network-manager-openvpn: FTBFS: ERROR:test-import-export.c:823:test_proxy_http_export: assertion failed (error == NULL): failed to write file: Failed to create file

[Chris Lamb]

Jeremy Bicha wrote:

> By output I am referring to the original gedit bug
> https://bugzilla.gnome.org/770100 where the output differs when built
> with and without parallel.

Getcha.

FTBFS-or-not-FTBFS feels to definitely fall outside of the scope of what
Reproducible can handle right now in terms of headspace, but it's easier
to make a case for ensuring reproducibility across parallel=N.

(I can't recall the case but this isn't the only instance I've seen ooi.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#839848: network-manager-openvpn: FTBFS: ERROR:test-import-export.c:823:test_proxy_http_export: assertion failed (error == NULL): failed to write file: Failed to create file

[Jeremy Bicha]

On Wed, Oct 5, 2016 at 2:29 PM, Chris Lamb  wrote:
> Test *output* ? Do you mean pass/fail result?  Mmm there are lots of tests
> one might do; I wish there was a more general framework for testing these
> things rather than piggy-backing on something that doesn't /quite/ fit.

By output I am referring to the original gedit bug
https://bugzilla.gnome.org/770100 where the output differs when built
with and without parallel. Minor differences in the build environment
that lead to different binary packages seems to me to be a much closer
fit to the reproducible builds project to me than reporting every new
amd64 FTBFS.

Jeremy

Bug#825840: Possible fix for colour invertion on ATY,Rockhopper2

[Mathieu Malaterre]

On Wed, Oct 5, 2016 at 7:45 PM, Lennart Sorensen
 wrote:
> On Wed, Oct 05, 2016 at 06:40:36PM +0200, Mathieu Malaterre wrote:
>> On Tue, Oct 4, 2016 at 10:24 PM, Lennart Sorensen
>>  wrote:
>> > On Tue, Oct 04, 2016 at 09:22:17PM +0200, Mathieu Malaterre wrote:
>> >> On Tue, Oct 4, 2016 at 4:44 PM, Lennart Sorensen
>> >>  wrote:
>> >> > On Tue, Oct 04, 2016 at 03:49:12PM +0200, Samuel Thibault wrote:
>> >> >> € grep bogl_set_palette *
>> >> >> bogl.c:  bogl_set_palette = bogl_fb_set_palette;
>> >> >> bogl.c: bogl_set_palette = bogl_fb_set_palette;
>> >> >> bogl.c: bogl_set_palette = bogl_tcfb_set_palette;
>> >> >> bogl.c:   the palette with bogl_set_palette() for this to take effect. 
>> >> >> */
>> >> >> bogl.h:void (*bogl_set_palette) (int c, int nc, const unsigned char 
>> >> >> palette[][3]);
>> >> >> bogl-test.c:  bogl_set_palette (0, 16, palette);
>> >> >> bogl-test.c:  bogl_set_palette (6, 8, pixmap->palette);
>> >> >> bowl.c:  bogl_set_palette (0, 16, (const unsigned char (*)[3]) 
>> >> >> palette);
>> >> >> bterm.c:  bogl_set_palette(0, 16, palette);
>> >> >> bterm.c:bogl_set_palette(0, 16, palette);
>> >> >> ChangeLog:* bterm.c (main): Call bogl_set_palette after VT switch.
>> >> >>
>> >> >> It looks like bterm always set only colors 0-15.
>> >> >
>> >> > So it does.  Hmm, I will compare the code some more.
>> >> >
>> >> > Has it been confirmed that radeonfb does not have wrong colours while
>> >> > offb on the same machine does?
>> >> >
>> >> > And what video mode does radeonfb run with?  I wish someone had dmesg
>> >> > dumps of both offb and radeonfb, but I am not having much luck finding
>> >> > any with google.
>> >>
>> >> Attached.
>> >
>> > Could you try what offb does if you boot with the kernel option:
>> > video=1680x1050-32
>>
>> Does not seems to be read at all. I tried both:
>>
>> $ cat /etc/yaboot.conf
>> [...]
>> append="video=1680x1050-32"
>>
>> and
>>
>> $ cat /etc/yaboot.conf
>> [...]
>> append="video=offb:1680x1050-32"
>>
>> dmesg & fbset output appears perfectly identical.
>
> Maybe it just doesn't support doing that.
>
> Looking at the code, offb in fact just does whatever open firmware
> settings say to do.
>
> So that means you would have to change the mode in open firmware before
> booting.
>
> So if you know how to drop to the open firmware prompt this might work:
>
> dev pci1/@D/ATY,RockHopper2_A
> 32 set-depth
> boot
>
> I think I am guessing correctly for the dev value to talk to the video
> card.
>
> There is a 'set-mode' command too, but I don't know the mode number
> for 1680x1050.  The radeonfb driver actually talks to the monitor and
> does the mode setting itself.  Looking at modedb.c in the kernel,
> entry 27 happens to be 1600x1200, and entry 36 is 1680x1050.  No idea
> if that relates to the modes in the mac open firmware, but if it does,
> this might work:
>
> dev pci1/@D/ATY,RockHopper2_A
> 36 enable-videomode
> 36 set-mode
> 32 set-depth
> boot
>
> But this is still just to find out of offb works correctly in 24/32 bit
> color mode, in which case the problem is only in 8 bpp.

Will do ASAP. For reference:

https://bugs.debian.org/825840#92

and

devalias tells me that  'screen' points to
'/pci@f000/ATY,RockHopper2Parent@10/ATY,RockHopper2_A@0'

Bug#839854: [Pkg-erlang-devel] Bug#839854: erlang-dev: adequate reports broken symlink in erlang-dev

[Sergei Golovan]

tags 839854 + pending
thanks

Hi shirish,

On Wed, Oct 5, 2016 at 9:21 PM, shirish शिरीष  wrote:
.
>
> erlang-dev: broken-symlink /usr/include/erl_native_features_config.h
> -> ../lib/erlang/usr/include/erl_native_features_config.h


You're right. This file was removed upstream and I've missed that.
I'll remove the symlink in the next upload.

Cheers!
-- 
Sergei Golovan