Bug#824967: RFS: budgie-desktop/10.2.5-1 [ITP]

[Paul Wise]

On Sun, May 22, 2016 at 6:38 AM, foss.freedom wrote:

> https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.5-1.dsc

I've included a review below.

> budgie-desktop is the flagship desktop system for Solus.  Solus is an tier 1
> distro using its own packaging mechanism eopkg.  Solus supports only its own
> distro (naturally) in a 64bit intel based system only.  The maintainer does
> accept bug-reports for other distro's as long as it is reproducible in Solus
> and/or the maintainer considers that the wider use of its desktop
> environment would be enhanced.

Does upstream have an opinion on having older versions of Budgie in
Debian stable, which gets supported for 5 years now that we have LTS.

>   To produce a debian package that works in debian and ubuntu I have used a
> more traditional rules based package rather than a simpler debhelper
> auto-build mechanism.  I have had to do it this way because debhelper does
> not produce binaries that actually work on a Ubuntu based platform - the
> desktop system fails to launch at logon.  The failure is silent - there is
> no obvious reason why debhelper autobuild fails to produce a working
> solution.

I would suggest using diffoscope to compare the broken build with the
working one, you might discover the reason for this brokenness.

> The patches incorporated are required for specifically Debian and Ubuntu and
> are used in budgie-remix itself.

I don't intend to sponsor this but here is a review:

Things that I personally think should be fixed before this package can
be uploaded:

The package fails to build because gtk+3.0 3.20.5-1 is not yet built in Debian:

 libgtk-3-0 : Depends: libgtk-3-common (>= 3.20.5-1) which is a
virtual package and is not provided by any available package
https://buildd.debian.org/status/package.php?p=gtk+3.0=unstable

There are many hardcoded library dependencies, they shouldn't be
needed as ${shlibs:Depends} will take care of them, unless these
libraries are loaded using dlopen instead of linking. If they are
loaded with dlopen, a ${dlopen:Depends} substvar and a script to
generate it would be better than hardcoding them.

debian/copyright is missing some copyright holders.

I think the ftp-masters will want debian/copyright to be more specific
about which files are LGPL and which are GPL.

I note that the upstream tarball contains generated files (*.c *.vapi
*.css *.png *.html). I personally think these need to be removed from
the upstream tarball and VCS if present in either of those and always
created at build time. If upstream doesn't want to do that an
acceptable workaround would be to remove these files in `debian/rules
clean` and in `debian/rules build` before autoreconf/configure are
run. Alternatively you could use the gitub-generated tarballs which
only contain what is in git. Looks like you will need to package some
more build-deps here though, like gulp-sass.

The imports/natray/ and gvc/ directories appear to be embedded code
copies from one of GNOME/cinnamon/MATE/cairo-dock-plug-ins/something.
They should be removed from all of these including budgie and packaged
separately. Until that happens the security team need to be notified
about the embedded code copy, which they track.

$ apt-file search -iIdsc na-tray
https://wiki.debian.org/EmbeddedCodeCopies

Things that I think would be nice to fix:

Please add DEP-3 headers to the patches, particularly the
Origin/Forwarded headers should point at URLs.

http://dep.debian.net/deps/dep3/

The first line of nm-applet.diff looks a bit strange.

The debian-watch-file-is-missing lintian tag should not be overridden
since upstream has a git repo with tags and tarballs that can be used
with uscan and debian/watch.

https://github.com/solus-project/budgie-desktop/releases
https://wiki.debian.org/debian/watch#GitHub

Please file bugs on lintian about the
dep5-copyright-license-name-not-unique and postinst-must-call-ldconfig
false positives.

The binary-without-manpage lintian tag should not be overridden since
it is true. Just ignore it until a manual page exists.

It would be great if upstream could sign their commits, tags and
releases with OpenPGP:

https://wiki.debian.org/Creating%20signed%20GitHub%20releases
https://wiki.debian.org/debian/watch#Cryptographic_signature_verification
https://help.riseup.net/en/security/message-security/openpgp/best-practices

I wonder what happens when you have both budgie and GNOME installed,
will the GNOME change?

Why do you disable the ibus systray icon?

I'm not sure the gnome-settings overrides are appropriate.

I wonder if the gsettings overrides should be renamed to
budgie-desktop.gsettings-override so it is only installed for one
package?

Usually in debian/control the version numbers in dependency relations
have a space before them:

- libgnome-bluetooth-dev (>=3.16),
+ libgnome-bluetooth-dev (>= 3.16),

I like to wrap-and-sort the debian/ directory using this command:

wrap-and-sort --short-indent 

Bug#824983: RFS: classic-theme-restorer/1.5.2-1 -- customize the new Firefox look

[Sean Whitton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for a new release of classic-theme-restorer.

* Package name: classic-theme-restorer
  Version : 1.5.2-1
  Upstream Author : Aris 
* URL : https://github.com/Aris-t2/ClassicThemeRestorer
* License : MPL-2.0
  Section : web

Changes since the last upload:

  * Package new upstream version.
  * Tweak short description.
Thanks Adam Borowski for the suggestion.

Download with dget:

dget -x 
http://mentors.debian.net/debian/pool/main/c/classic-theme-restorer/classic-theme-restorer_1.5.2-1.dsc

Or build it with gbp:

gbp clone --pristine-tar 
https://anonscm.debian.org/git/pkg-mozext/classic-theme-restorer.git
git checkout debian/1.5.2-1
git verify-tag debian/1.5.2-1 # if you have my key
gbp buildpackage

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#824982: src:gtk+3.0: unsatisfiable dependency on libgtk-3-common

[Afif Elghraoui]

Package: src:gtk+3.0
Version: 3.20.5-1
Severity: serious
Control: affects -1 openjdk-8-jre

I ran into a problem while trying to build a package depending on default-jdk 
in Unstable.
In my build, I'd get:

The following packages have unmet dependencies:
 default-jdk : Depends: default-jre (= 2:1.8-57) but it is not going to be 
installed
   Depends: openjdk-8-jdk but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

I traced it back (trying to directly install the failing dependency directly 
and moving down the chain) and the problem starts when libatk-wrapper-java-jni 
depends on libgtk-3-0, which can't be installed:

# apt-get install --dry-run libgtk-3-0
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libgtk-3-0 : Depends: libgtk-3-common (>= 3.20.5-1) but it is not installable
  Recommends: libgtk-3-bin but it is not going to be installed
E: Unable to correct problems, you have held broken packages.


then the problem is here:

# apt-get install --dry-run libgtk-3-common
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Package libgtk-3-common is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  gtk-3-examples

E: Package 'libgtk-3-common' has no installation candidate


Coulud someone take a look, please?

Many thanks and regards
Afif

Bug#785622: xfce4: black screen after resume from suspend

[Aaron M. Ucko]

Package: xfce4-settings
Version: 4.12.0-2
Followup-For: Bug #785622

I've encountered this same bug under 4.4.x and 4.5.x kernels, and
found that the proposed patch from

https://bugzilla.xfce.org/show_bug.cgi?id=11107#c53

cleared the problem up for me.  Could you please apply it?

Thanks!

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

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 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 xfce4-settings depends on:
ii  libc62.22-7
ii  libcairo21.14.6-1+b1
ii  libdbus-1-3  1.10.8-1
ii  libdbus-glib-1-2 0.106-1
ii  libexo-1-0   0.10.7-1
ii  libfontconfig1   2.11.0-6.4
ii  libgarcon-1-00.4.0-2
ii  libgarcon-common 0.4.0-2
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.48.1-1
ii  libgtk2.0-0  2.24.30-1.1
ii  libnotify4   0.7.6-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libupower-glib3  0.99.4-2
ii  libx11-6 2:1.6.3-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxfce4ui-1-0   4.12.1-2
ii  libxfce4util74.12.1-2
ii  libxfconf-0-24.12.0-2+b1
ii  libxi6   2:1.7.6-1
ii  libxklavier165.2.1-1
ii  libxrandr2   2:1.5.0-1
ii  xfconf   4.12.0-2+b1

Versions of packages xfce4-settings recommends:
ii  x11-utils  7.7+3
ii  xfce4-volumed  0.1.13-5

xfce4-settings suggests no packages.

-- no debconf information

Bug#824908: apt: inconsistent “header” terminology throughout documentation, comments, messages

[Ben Finney]

On 21-May-2016, David Kalnischkies wrote:

> Could you please split especially the first one up more?

I have now updated the branch with more granular changes
.

> As an example, your changes in the context of gpgv are incorrect as
> the official term in rfc2440 for the "key-value pairs" is "Armor
> Header" not field as you suggest and even if that is grossly
> inconsistent I don't think its a good idea to change this.

The documentation refers to the “armor header” as the collection of
name-value pairs that head the armor. I have now followed this
terminology.

> In the context of http(-like) the more correct term might be "header
> fields" which you use sometimes (then you replaced a 'line'), but
> not always. In comments just "fields" might be correct much like the
> RFC uses it in long paragraphs where its clear what is meant, but in
> error messages we should perhaps be using the full term.

I have tried to make minimal changes to the text of messages. For many
context there is no other kind of field, so “field” suffices in most
places.

> (btw: the registry for "Message Header Field Names" is called
> "Message Headers", so using "headers" isn't as inconsistent as you
> make it sound)

If that name is used, it's another inconsistency :-)

> Changing the tests/integration/status-* files is interesting in so
> far as you are modifying the descriptions of actual packages (which
> might or might not be changed in the meantime).

Do those packages actually exist? I didn't realise.

Will the corrected text alter the outcome of the test case?

> Changing to "LSB fields" is in sofar interesting as even the
> "official doc" [0] isn't clear on which term is preferred.

Yes. I have made note of this in the separate revision now committed.

> In the documentation you do typo/style fixes (FDs, URIs, HTTP, …)
> which should be fixed in the translations (doc/po) as well to avoid
> needless fuzzies.

I am not sure how to do this (I am not familiar with proper use of
gettext). I only changed terms in the area where I was already
changing “header” and “field” terminology.

Which files should I modify for translation? Some are auto-generated,
I think.

> Some of the http->HTTP changes are wrong as these parts are talking
> about the method named 'http', not the protocol 'HTTP'.

Right, I have taken more care and distinguished ‘http’ as a method
name now.


Please (someone) review the latest update when you have time, and let
me know what should be done to get the changes in.

-- 
 \ “The aim of science is not to open the door to infinite wisdom, |
  `\but to set some limit on infinite error.” —Bertolt Brecht, |
_o__)_Leben des Galilei_, 1938 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

[Tim Dengel]

Am 22.05.2016 um 04:16 schrieb Jonathon Love:
> [...]
> increasing the debian version is
> necessary when using d-mentors. if you make some changes/fixes, and
> upload with the same version number, it rejects it saying that it has
> already been uploaded. perhaps there is a workaround for this, but i
> don't know it.

When you upload your package with dput, you can use to -f option to
force the upload if the same version already exists on d-mentors.

Bug#823149: [Pkg-javascript-devel] Bug#823149: libjs-jquery-fancybox doesn't work with current libjs-jquery

[Marcelo Jorge Vieira]

Hi,

Thanks for the bug report, I will fix it.


Cheers,

-- 
Marcelo Jorge Vieira
xmpp:me...@jabber-br.org
http://metaldot.alucinados.com

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

Bug#824981: network-manager: Can not connect broadband using Sierra Wireless EM7455

[Gulfstream Wang]

Package: network-manager
Version: 1.2.2-1
Severity: important


After I complete a new mobile broadband connection, the dialog for input mobile 
broadband password is showed (see the attachment file).The "Connect" button can 
not be pressed unless anything is filled in the dialog.
But my provider is not need any username and password.

If I edit the configuration file in /etc/NetworkManager/system-connections, 
delete the username and password. Then connect, the connection can not be 
established, and I get an error message in daemon.log.

The error message is like blew.

 (NetworkManager:902): NetworkManager-wwan-CRITICAL **: modem_prepare_result: 
assertion 'state == NM_DEVICE_STATE_PREPARE' failed


My laptop is Thinkpad X1 carbon 4th Gen with Debian testing, the mobile 
broadband slot is embed.

Thanks to everyone!


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

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.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.114
ii  dbus   1.10.8-1
ii  init-system-helpers1.33
ii  isc-dhcp-client4.3.4-1
ii  libaudit1  1:2.5.2-1
ii  libbluetooth3  5.36-1+b1
ii  libc6  2.22-7
ii  libglib2.0-0   2.48.1-1
ii  libgnutls303.4.11-4
ii  libgudev-1.0-0 230-3
ii  libmm-glib01.4.14-1
ii  libndp01.6-1
ii  libnewt0.520.52.18-3
ii  libnl-3-2003.2.27-1
ii  libnm0 1.2.2-1
ii  libpam-systemd 229-5
ii  libpolkit-agent-1-00.105-15
ii  libpolkit-gobject-1-0  0.105-15
ii  libreadline6   6.3-8+b4
ii  libselinux12.5-2
ii  libsoup2.4-1   2.54.1-1
ii  libsystemd0229-5
ii  libteamdctl0   1.24-1
ii  libuuid1   2.28-5
ii  lsb-base   9.20160110
ii  policykit-10.105-15
ii  udev   229-5
ii  wpasupplicant  2.3-2.3

Versions of packages network-manager recommends:
ii  crda3.13-1+b1
ii  dnsmasq-base2.75-1
ii  iptables1.6.0-2
ii  iputils-arping  3:20150815-2
ii  modemmanager1.4.14-1
ii  ppp 2.4.7-1+2

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

-- Configuration Files:
/etc/NetworkManager/NetworkManager.conf changed:
[main]
plugins=ifupdown,keyfile
[ifupdown]
managed=true


-- no debconf information

Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

[Jonathon Love]

hi andrey,



On Thu, May 05, 2016 at 11:17:27AM +1000, Jonathon Love wrote:

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

   dget -x 
https://mentors.debian.net/debian/pool/main/f/flatbuffers/flatbuffers_1.3.0-2.dsc

This gives 404.
https://mentors.debian.net/package/flatbuffers contains 1.3.0-5 instead.
Note that you shouldn't increase the debian version for pckages that were
not uploaded to Debian.



thanks for taking a look at my package. increasing the debian version is 
necessary when using d-mentors. if you make some changes/fixes, and 
upload with the same version number, it rejects it saying that it has 
already been uploaded. perhaps there is a workaround for this, but i 
don't know it.


i would prefer to be working out of a git repo than using d-mentors, 
perhaps you could request access for me to collab-maint, and i could set 
up a git repo there?


my debian username is jonathon-guest

with thanks

jonathon

Bug#747392: gtk+3.0 has a cycle build-depency on itself

[Michael Biebl]

Am 21.05.2016 um 18:56 schrieb Michael Biebl:
> Maybe dropping the libgtk-3-bin dependency from adwaita-icon-theme is.
> This needs someone to investigate how libgtk-3-0 behaves if there are no
> cache files.

After further consideration, the probably best solution is to split out
/usr/bin/gtk-update-icon-cache into a separate package.
gtk-update-icon-cache doesn't have any libgtk-3-0 dependencies, so we
could break the dependency cycle at this point.
I propose to name the package gtk-update-icon-cache. I was told that
Fedora chose the same name, which is a fortunate incident.

Theme packages will need to be updated to depend on
gtk-update-icon-cache instead of libgtk-3-bin or libgtk2.0-bin.

I will also update gtk2.0 to no longer ship
/usr/bin/gtk-update-icon-cache in libgtk2.0-bin, as there is no good
reason to do so any longer. From now on we will only ship one
implementation of gtk-update-icon-cache which is built from src:gtk-3.0.
This means we will drop our Debian-specific
/usr/bin/gtk-update-icon-cache-3.0.
According to codesearch, this affects only a couple of packages, which
can be simplified as part of the process. buzztrax should be updated
upstream to drop the Debianism.

It also allows us to drop the diversions from libgtk-3-bin.

Another positive side-effect is that we can drop
debian/patches/01_gtk-update-icon-cache_name.patch from
gnome-themes-standard.

All in all a net win, I'd say.

-- 
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#824980: mon-contrib: scripts use predictable names in /tmp which is a potential security issue

[Russell Coker]

Package: mon-contrib
Version: 1.0+dfsg-3
Severity: normal

alert.d/sms.alert mon.d/smtp_rt.monitor mon.d/tftp.monitor

The above scripts use predictable names in /tmp which is a potential security 
issue.

I suggest replacing /tmp/ with ~mon/ .

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

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

Versions of packages mon-contrib depends on:
ii  mon  1.2.0-9

mon-contrib recommends no packages.

mon-contrib suggests no packages.

-- no debconf information

Bug#824979: http_tppnp.monitor script uses predictable name in /tmp

[Russell Coker]

Package: mon
Version: 1.2.0-9
Severity: normal

The following mon.d/http_tppnp.monitor script uses /tmp/http_tppnp for a pipe by
default which is a potential security issue.  ~mon/http_tppnp would be a better 
option.


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

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

Versions of packages mon depends on:
ii  adduser  3.114
ii  libc62.22-9
ii  libtime-period-perl  1.20-8.2
ii  mon-client   1.2.0-2

Versions of packages mon recommends:
pn  fping
pn  libauthen-pam-perl   
pn  libcrypt-ssleay-perl 
ii  libfilesys-diskspace-perl0.05-16.2
ii  libnet-dns-perl  1.05-2
pn  libnet-ldap-perl 
pn  libnet-telnet-perl   
pn  libsnmp-perl 
pn  libstatistics-descriptive-perl   
pn  libtime-parsedate-perl   
ii  perl-modules-5.22 [libnet-perl]  5.22.2-1

Versions of packages mon suggests:
ii  mon-contrib  1.0+dfsg-3

-- Configuration Files:
/etc/mon/mon.cf changed [not included]

-- no debconf information

Bug#824908: apt: inconsistent “header” terminology throughout documentation, comments, messages

[Ben Finney]

On 21-May-2016, David Kalnischkies wrote:

> (incomplete quick look)

Thank you for looking and giving a prompt response.

> Could you please split especially the first one up more?

Yes, I'll do that.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but me and Pippi Longstocking — I mean, what would the |
_o__)  children look like?” —_Pinky and The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#824978: androguard: upstream README.md is not useful to binary package users

[Paul Wise]

Package: androguard
Version: 2.0-1
Severity: minor
File: /usr/share/doc/androguard/README.md
Usertags: readme

The upstream README.md is not useful to binary package users since it
contains only the Debian package description plus authorship, copyright
and license information, which are in the Debian copyright file.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (860, 
'testing-proposed-updates'), (800, 'unstable-debug'), (800, 'unstable'), (790, 
'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages androguard depends on:
ii  ipython 2.4.1-1
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.22-9
ii  libgcc1 1:6.1.1-3
ii  liblzma55.1.1alpha+20120614-2.1
ii  libmuparser2v5  2.2.3-6
ii  libsnappy1v51.1.3-3
ii  libstdc++6  6.1.1-3
ii  python  2.7.11-1
pn  python:any  
ii  zlib1g  1:1.2.8.dfsg-2+b1

androguard recommends no packages.

Versions of packages androguard suggests:
ii  python-pyside.qtcore  1.2.2-2+b1
ii  python-pyside.qtgui   1.2.2-2+b1

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#750586: website design

[allen thomas]

Good day
I'm Thomas Allen,am hearing impaired.i would love to know if you can handle
website design for a new company and also if you do, you accept credit
cards? kindly get back to me ASAP so i can send you the job details.
Regards

Bug#824977: O: dhelp -- Read all documentation with a WWW browser.

[Georgios Zarkadas]

Package: wnpp
Severity: normal

I haven't worked on dhelp for quite a long time and, most probably, I will
not
be able to do so for quite a long time also. I 'm therefore orphaning the
package.

Bug#824933: [Android-tools-devel] Bug#824933: apktool: crashes with every APK

[Paul Wise]

On Sat, 2016-05-21 at 17:31 +0200, Markus Koschany wrote:

> Perhaps I also need to symlink aapt into /usr/share/apktool? I will try
> that later. In the meantime you can point apktool to aapt by using
> 
> apktool -a /usr/bin/aapt

Still crashes, see below. I guess that is because I haven't installed
the framework files yet. It would be nice if this error message was
more user-friendly (like telling where to download the framework).

> The second issue here is that users need the framework files otherwise
> they can't decode apk files.

Where can one download a copy of the AOSP framework?

> After that decoding should work but I haven't tested it yet. It would be
> more convenient if this worked out-of-the box without the need to run
> the above mentioned commands though.

Agreed.

> Not all apk files can be decoded with the AOSP framework files and I'm
> not so sure if the others are all free software but it would be a huge
> improvement if we could ship the AOSP files at least.

Understood, agreed. From what I read on the upstream website, there are
phone vendor frameworks (like for HTC) that are unlikely to be FLOSS.

Crash with Debian aapt:

pabs@chianamo ~/tmp-apk $ apktool -a /usr/bin/aapt d com.example.foo.apk 
I: Using Apktool 2.1.1-dirty on com.example.foo.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
Exception in thread "main" java.lang.NullPointerException
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2146)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:2102)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:2123)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:2078)
at 
brut.androlib.res.AndrolibResources.getFrameworkApk(AndrolibResources.java:581)
at 
brut.androlib.res.AndrolibResources.loadFrameworkPkg(AndrolibResources.java:121)
at brut.androlib.res.data.ResTable.getPackage(ResTable.java:83)
at brut.androlib.res.data.ResTable.getResSpec(ResTable.java:66)
at brut.androlib.res.data.ResTable.getResSpec(ResTable.java:62)
at 
brut.androlib.res.decoder.ResAttrDecoder.decode(ResAttrDecoder.java:39)
at 
brut.androlib.res.decoder.AXmlResourceParser.getAttributeValue(AXmlResourceParser.java:369)
at 
org.xmlpull.v1.wrapper.classic.XmlPullParserDelegate.getAttributeValue(XmlPullParserDelegate.java:69)
at 
brut.androlib.res.decoder.XmlPullStreamDecoder$1.parseManifest(XmlPullStreamDecoder.java:97)
at 
brut.androlib.res.decoder.XmlPullStreamDecoder$1.event(XmlPullStreamDecoder.java:65)
at 
brut.androlib.res.decoder.XmlPullStreamDecoder.decode(XmlPullStreamDecoder.java:141)
at 
brut.androlib.res.decoder.XmlPullStreamDecoder.decodeManifest(XmlPullStreamDecoder.java:153)
at 
brut.androlib.res.decoder.ResFileDecoder.decodeManifest(ResFileDecoder.java:140)
at 
brut.androlib.res.AndrolibResources.decodeManifestWithResources(AndrolibResources.java:208)
at brut.androlib.Androlib.decodeManifestWithResources(Androlib.java:133)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:106)
at brut.apktool.Main.cmdDecode(Main.java:163)
at brut.apktool.Main.main(Main.java:81)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#824930: [Android-tools-devel] Bug#824930: apktool: creates directories and an empty 1.apk file in $HOME

[Paul Wise]

On Sat, 2016-05-21 at 17:15 +0200, Markus Koschany wrote:

> This is intentional but I must admit I don't like it too. Normally
> apktool copies the framework files to this directory or, if it is not
> available, to java.io.tmpdir. We probably could change that to
> ~/.apktool or ~/.local/share/apktool. Thoughts?

I think I would prefer the XDG user cache dir since this isn't really
user data but just data cached from elsewhere.

> https://ibotpeaches.github.io/Apktool/documentation/#framework-files

Thanks for the pointer.

> However before you can decode apk files you need to install those
> framework files.

It would be more convenient for users if those framework files were
installed by some Debian package in /usr/share/...

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#824927: [Android-tools-devel] Bug#824927: apktool: copies upstream apktool script instead of patching it

[Paul Wise]

On Sat, 2016-05-21 at 17:06 +0200, Markus Koschany wrote:

> I don't think it is a big deal to create a custom Debian
> wrapper and to include it with the debian directory.

I agree that is reasonable, if you are writing the wrapper script from
scratch but I think if you are customising the upstream one you should
patch it instead of copying and editing it. This way the changes from
upstream can be tracked more easily by developers and users.

> This is also fixed in

You may want to use tagpending from devscripts btw.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#760945: postinst overwrites permissions set by admin, destroys configuration for slaves

[Sven Hartge]

On 22.05.2016 00:25, Iustin Pop wrote:

>> ,
>> |   chown smokeping:smokeping /var/lib/smokeping
>> |   chown smokeping:smokeping /etc/smokeping/smokeping_secrets
>> |   chmod 640 /etc/smokeping/smokeping_secrets
>> `
>>
>> This unconditionally destroys any custom permissions the admin may have
>> set. Overwriting the permissions for /etc/smokeping/smokeping_secrets is
>> especially desastrous because this file needs to be read by the www-data
>> user (or group) to allow slaves to connect correctly.
>>
>> Right now the only option is to use POSIX-ACLs to allow www-data to read
>> that file because if you just use "chgrp www-data" this change will get
>> overwritten the next time the package is updated.
> 
> Since there's no mechanism (AFAIK) for automatically handling custom
> permissions for conffiles, and both the admin and the package fight over
> this, the first solution that comes to mind is to add debconf questions
> for owner and mode, and always use debconf/the package to manage the
> permissions. This would solve both problems (conflicts and custom
> permissions).
> 
> A simpler alternative but not that flexible would be to add only one
> question ("support slaves"), which would different, but still hard-coded
> permissions.

In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=760945#12 I
corrected my statement concerning the direcory /var/lib/smokeping, but
the wrong permissions for /etc/smokeping/smokeping_secrets remain.

Since this file is only ever needed on the server side (and unused if
you don't have slaves), you can (AFAICS) unconditionally ust set the
ownership to smokeping:www-data and set 640 as permissions and be done,
no need to ask anything.

The slave itself uses /etc/smokeping/slave-secrets as source for the
password, smokeping:root and 640 are correct there and can stay that way.

Grüße,
Sven.



signature.asc
Description: OpenPGP digital signature

Bug#824976: zfs-initramfs: update-initramfs fails without busybox

[Nicolas Braud-Santoni]

Package: zfs-initramfs
Version: 0.6.5.6-2
Severity: important

Dear Maintainer,

After having installed zfs-initramfs, update-initramfs
  started failing, indicating that I need to install either
  busybox or busybox-static.

Installing the later solved the issue.

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

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

Versions of packages zfs-initramfs depends on:
ii  initramfs-tools 0.125
ii  zfs-dkms [zfs-modules]  0.6.5.6-2
ii  zfsutils-linux  0.6.5.6-2

zfs-initramfs recommends no packages.

zfs-initramfs suggests no packages.

-- no debconf information

Bug#824974: grub-pc: grub-probe fails on root-on-ZFS systems

[Nicolas Braud-Santoni]

Package: grub-pc
Version: 2.02~beta2-36
Severity: normal

Dear Maintainer,

On my freshly setup Stretch system, update-grub fails with the following error:

> /usr/sbin/grub-probe: error: failed to get canonical path of 
> `/dev/vacuum-crypt'.

This led me to having no grub.cfg file (until I wrote one by hand) and
  will probably manifest itself when I upgrade the kernel.


My setup is as follows:
- /boot is on /dev/sda1 (ext4);
  it is designated by label (vacuum-boot) in /etc/fstab
- /dev/sda2 contains a LUKS volume (vacuum-crypt)
- vacuum-crypt contains a ZFS pool (vacuum) that hold the filesystem.


I am aware that ZFS support in Debian is extremely new.
My goal, in opening this bug, is to keep track of what needs to be done on 
Grub's
  side so that it works correctly for ZFS users.


Best regards,

  nicoo 


-- Package-specific info:

*** BEGIN /proc/mounts
/dev/sda1 /boot ext4 rw,nosuid,nodev,noexec,relatime,data=ordered 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/grub.cfg
insmod linux
set root=(hd0,msdos1)
linux /vmlinuz-4.5.0-2-amd64 root=ZFS=vacuum/ROOT/debian boot=zfs 
security=apparmor
initrd /initrd.img-4.5.0-2-amd64
*** END /boot/grub/grub.cfg

*** BEGIN /proc/mdstat
cat: /proc/mdstat: No such file or directory
*** END /proc/mdstat

*** BEGIN /dev/disk/by-id
total 0
lrwxrwxrwx 1 root root  9 May 22 01:27 
ata-HITACHI_HTS723232A7A364_E3834563JNZL0N -> ../../sda
lrwxrwxrwx 1 root root 10 May 22 01:27 
ata-HITACHI_HTS723232A7A364_E3834563JNZL0N-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 May 22 01:27 
ata-HITACHI_HTS723232A7A364_E3834563JNZL0N-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 May 22 01:27 dm-name-vacuum-crypt -> ../../dm-0
lrwxrwxrwx 1 root root 10 May 22 01:27 
dm-uuid-CRYPT-LUKS1-ffe82002193847da88304475aebe7501-vacuum-crypt -> ../../dm-0
lrwxrwxrwx 1 root root  9 May 22 01:27 usb-General_1-0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 May 22 01:27 usb-General_1-0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root  9 May 22 01:27 wwn-0x5000cca61de5b93a -> ../../sda
lrwxrwxrwx 1 root root 10 May 22 01:27 wwn-0x5000cca61de5b93a-part1 -> 
../../sda1
lrwxrwxrwx 1 root root 10 May 22 01:27 wwn-0x5000cca61de5b93a-part2 -> 
../../sda2
*** END /dev/disk/by-id

*** BEGIN /dev/disk/by-uuid
total 0
lrwxrwxrwx 1 root root 10 May 22 01:27 2016-04-02-20-59-26-00 -> ../../sdb1
lrwxrwxrwx 1 root root 10 May 22 01:27 5902543104507671737 -> ../../dm-0
lrwxrwxrwx 1 root root 10 May 22 01:27 87b818b8-c6ac-4802-85d5-be4b1ade3101 -> 
../../sda1
lrwxrwxrwx 1 root root 10 May 22 01:27 ffe82002-1938-47da-8830-4475aebe7501 -> 
../../sda2
*** END /dev/disk/by-uuid

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

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

Versions of packages grub-pc depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  dpkg   1.18.7
ii  grub-common2.02~beta2-36
ii  grub-pc-bin2.02~beta2-36
ii  grub2-common   2.02~beta2-36
ii  ucf3.0036

grub-pc recommends no packages.

grub-pc suggests no packages.

-- debconf information:
  grub2/linux_cmdline:
* grub-pc/install_devices_empty: true
  grub2/force_efi_extra_removable: false
  grub-pc/install_devices_failed_upgrade: true
  grub-pc/postrm_purge_boot_grub: false
  grub2/device_map_regenerated:
  grub2/kfreebsd_cmdline:
* grub-pc/install_devices:
  grub2/kfreebsd_cmdline_default: quiet
  grub-pc/timeout: 5
  grub-pc/mixed_legacy_and_grub2: true
  grub2/linux_cmdline_default: quiet
  grub-pc/partition_description:
  grub-pc/install_devices_disks_changed:
  grub-pc/kopt_extracted: false
  grub-pc/install_devices_failed: false
  grub-pc/chainload_from_menu.lst: true
  grub-pc/disk_description:
  grub-pc/hidden_timeout: false

Bug#824975: zfs-dkms: Module fails to build without kernel-headers

[Nicolas Braud-Santoni]

Package: zfs-dkms
Version: 0.6.5.6-2
Severity: important

Dear Maintainer,

The zfs-dkms module fails to build without kernel headers,
  yet there seem to be no dependency set on that package.

The problem was encountered while setting up a root-on-ZFS
  stretch system from scratch (using Debian live and
  debootstrap).


Best,

  nicoo 


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

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

Versions of packages zfs-dkms depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  dkms   2.2.0.3-4
ii  lsb-release9.20160110
ii  spl-dkms   0.6.5.6-2

Versions of packages zfs-dkms recommends:
pn  zfs-zed 
ii  zfsutils-linux  0.6.5.6-2

zfs-dkms suggests no packages.

-- debconf information:
* zfs-dkms/note-incompatible-licenses:
  zfs-dkms/stop-build-for-unknown-kernel: true
  zfs-dkms/stop-build-for-32bit-kernel: true

Bug#824973: apt-file update no longer works as a user

[Cyril Brulebois]

Package: apt-file
Version: 3.0
Severity: important

Hi,

Just stumbled upon this:
| (stretch-amd64-devel)kibi@wodi:~$ apt-file update
| W: chmod 0700 of directory /var/lib/apt/lists/partial failed - 
SetupAPTPartialDirectory (1: Operation not permitted)
| E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission 
denied)
| E: Unable to lock directory /var/lib/apt/lists/
| W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: 
Permission denied)
| W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches 
(13: Permission denied)
| E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
| E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

seen on both stretch and sid.


KiBi.

Bug#824972: RM: gmt-doc-ps -- ROM; superseded by PDF files in gmt-doc package

[Torsten Landschoff]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: ftp.debian.org
Severity: normal

Hi,

please remove the gmt-doc-ps package. It somehow was abandoned when GMT
maintainership was taken over by the Debian GIS Project.

It probably should never have existed as PDF is a much better format for
viewing and printing than Postscript.

Greetings, Torsten
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXQPNYAAoJEB5flaeGO3x3n8UQAIFqz8W+mUXXfCGsYMSKWL/h
Qi6BCnEc5cDUmHLlD7SafpQYrbs57DLX+uRTJ2Irci9dwZntiZLKjZ3FW1aEF3zx
RLCW+4Cxr0JN/lMMUg2EZrOlhphtoQSlu+KpgQ20Ag4fGrqWoxHZdp7aXeLT6l8q
vJKIDxcXBsxviQxWx+cP8BFqXwgTIlTWqoDhf2l7GPCh0Jth8heuqIxKfU053IsM
Et5CkOd/b8DT4bia7zbMDbfdgLDg7G7Sh7FV39PQENLqBZaHaeG/Hz9FJM12+UuZ
5FZ2v8ATuRr7Fa+P1JvHEOpDrT/VgkOOVEzLQpfmi2mrf1IpD4WRKkiXIkX296Dr
hWa7QLv9oXg1+HtlyzU0uau+Xr3aWYQKIrFEpxGBN756mLH6wsy3eH0+i4BUEwax
241QGDnah2CvKUwUyBhrsfOdNi4lDi4oGRiq9DeRkpSs8yF0Huf7beGHYDIl3ugH
3NABCRTiKx3LrGAtHfwTTBpYF4uW7I5lAPmn/NHuKLqGx/YxNm1OyxFCbwFs+GEO
sxPXvctSW5JwFB9HKkyIRUl53UmESKWwP+QsrZmofH+14vO4e/LfjVKnqhD4v03X
c2aSPd+ONpszM10fyY+qcZ2P7sekBMHu3zjpNhLYYRRhoSDMx8Lr+8gxZ3JQ4kZd
GXOFN2GZjIkM8WmR8dW8
=cTty
-END PGP SIGNATURE-

Bug#808088: gsoc + developer horizon

[Iain R. Learmonth]

Hi Harsh,

Sorry I missed you in IRC but it was 4am here when you came in.

I've now created a wiki page for the service at:

https://wiki.debian.org/Services/DeveloperHorizon

We should get a wiki page up at /DeveloperHorizon too and add a TODO
section. Tasks should really be managed on our BTS psuedo-package but
this has not yet been created (hence CC'ing the relevant bug).

If you can add the current list of data sources to the new wiki page
then we can start putting together a list of new data sources that can
be added:

https://wiki.debian.org/DeveloperHorizon (you'll have to create it if
you get to it before me, going to sleep shortly).

Thanks,
Iain.

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

> > > d/rules:
> > > - why -D_FORTIFY_SOURCE=1? Such things should be documented
> > 
> > For security reasons, as this is an internet accessible daemon that
> > accepts user input. 
> What I've meant was "you replaced stronger default flag with a weaker
> one". As you know about dpkg-buildflags you should know that the 'fortify'
> option is enabled by default and that it adds -D_FORTIFY_SOURCE=2.

Didn't know that D_FORTIFY_SOURCE=2 was the default. Based on the manpage,
D_F_S=2 can break some programs, while D_F_S=1 should not. Given that there's
no real comprehensive tests, for iroffer-dinoex, I felt it was safer to set it
to 1 rather than 2.

> > It also gets rid of the lintian info tag
> > "hardening-no-fortify-functions". 
> If you have this tag then something is wrong. If it's also fixed by adding
> -D_FORTIFY_SOURCE to CFLAGS then your upstream build system doesn't handle
> CPPFLAGS correctly. It should be fixed to handle them.

Until it's fixed upstream what is the "correct" way of getting it to compile
with -D_FORTIFY_SOURCE?
I've patched the configure script to accept external CPPFLAGS in the meantime.

> > > - you can probably replace override_dh_auto_clean with debian/clean
> > 
> > I can't seem to find any documentation regarding debian/clean in the
> > maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
> > How is debian/clean supposed to be used?
> man dh_clean
> To remove files not removed by dh_auto_clean.

How handy. I've fixed the build to use debian/clean.
How do I get that documented in the maint-guide?

> > > - why this package not only Conflicts but Replaces iroffer? Do you know
> > >   how will apt handle this relationship? Do you intend to do anything with
> > >   the iroffer package itself (it's orphaned ATM)? If you want to replace
> > >   it completely then the replacing procedure is different, see
> > >   https://wiki.debian.org/Renaming_a_Package
> > 
> > iroffer-dinoex is intended to be a drop-in replacement for the original
> > iroffer. The binaries have the same name, and the config formats are
> > unchanged.
> > Based on what I could tell from the docs (correct me if I'm wrong)
> > [www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
> > this is the correct way to have a package be an alternative drop in
> > replacement (ie how MTA's are managed).
> > I do not intend to take over the iroffer package completely. This is merely
> > an alternative to the original iroffer that can be a drop in
> > upgrade/replacement.
> Just Conflicts could be enough but it won't uninstall the other package.
> I don't know how Conflicts+Replaces will work, you'll need to test this.
> Note that you still won't be able to install iroffer without manually
> removing iroffer-dinoex (at least that's what I think).

What you described is what I intended the functionality to be. iroffer-dinoex
should be able to be installed _over_ iroffer (apt will remove the old package
automatically)
  % sudo dpkg -i iroffer-dinoex_3.30-1_amd64.deb
  Selecting previously unselected package iroffer-dinoex.
  dpkg: considering removing iroffer in favour of iroffer-dinoex ...
  dpkg: yes, will remove iroffer in favour of iroffer-dinoex
If you install iroffer over iroffer-dinoex, apt will prompt to remove
iroffer-dinoex before installing iroffer.

If this seems too far off what the norm is, I'm fine with removing the Replaces,
but based on the docs and my testing, this should be fine.

> > > d/copyright:
> > > - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
> > >   option) any later version" in the texts
> > I assumed "or (at your option) any later version" meant that the upstream
> > author could (at their discretion) upgrade the license to a newer version
> > of GPL.
> > Not that an end-user (me) could upgrade to a newer version at my 
> > descretion. I'm not a lawyer, so I chose to leave it untouched.
> You seem to be confusing several things here.
> The upstream authors can do anything they want but the license clauses say
> what can other people do instead.
> "License: GPL-2" means "you can use GPL 2", "License: GPL-2+" means "you
> can use GPL 2 or (at your option) any later version".
> And the upstream LICENSE doesn't say about "any later version", so you
> didn't "leave it untouched".
> Actually, the upstream LICENSE includes the OpenSSL linking exception for
> some files and tells to look into the files to find out which of them have
> what licenses so your d/copyright should be more fine-grained than now.
> 
> > > - using GPL for debian/ while having MIT and LGPL in the upstream source
> > >   is discouraged and may cause problems if debian/ contains e.g. patches
> > What's the correct way to resolve this, choose a less restrictive license
> > for debian/? 
> Yes.

Fixed. Changed the license to BSD-3-clause.

> > no-upstream-changelog should be an I tag.
> Why do you think so?

That was my mistake. I got it mixed up with some other tags.
 
> > > - 

Bug#824971: qtbase-opensource-src: FTBFS on powerpcspe due to mismatched symbols files

[John Paul Adrian Glaubitz]

Source: qtbase-opensource-src
Version: 5.5.1+dfsg-16
Severity: normal
User: debian-powe...@lists.debian.org
Usertags: powerpcspe

Hello!

qtbase-opensource-src currently fails to build from source on powerpcspe
due to mismatched symbols files [1].

Please use the diff provided by the build log to update the symbols
files accordingly:

dh_makeshlibs -V -plibqt5gui5 -XlibQt5EglDeviceIntegration.so -X libQt5XcbQpa.so
dpkg-gensymbols: warning: debian/libqt5gui5/DEBIAN/symbols doesn't match 
completely debian/libqt5gui5.symbols
--- debian/libqt5gui5.symbols (libqt5gui5_5.5.1+dfsg-16_powerpcspe)
+++ dpkg-gensymbolsRfSbEj   2016-05-21 22:03:58.682355449 +
@@ -64,7 +64,7 @@
  _Z29qt_set_sequence_auto_mnemonicb@Base 5.0.2
  _Z30qt_gl_set_global_share_contextP14QOpenGLContext@Base 5.4.0
  _Z32qGamma_correct_back_to_linear_csP6QImage@Base 5.0.2
- (optional=gccinternal|arch=amd64 kfreebsd-amd64 powerpcspe 
x32)_Z32qt_convert_rgb888_to_rgb32_ssse3PjPKhi@Base 5.0.2
+#MISSING: 5.5.1+dfsg-16# (optional=gccinternal|arch=amd64 kfreebsd-amd64 
powerpcspe x32)_Z32qt_convert_rgb888_to_rgb32_ssse3PjPKhi@Base 5.0.2
  _Z33hb_qt_font_get_use_design_metricsP9hb_font_t@Base 5.2.0
  _Z33hb_qt_font_set_use_design_metricsP9hb_font_tj@Base 5.2.0
  
_Z35qtInitializeVertexArrayObjectHelperP30QOpenGLVertexArrayObjectHelperP14QOpenGLContext@Base
 5.4.0
@@ -6481,7 +6481,7 @@
  _ZNK9QVector4D16toVector3DAffineEv@Base 5.0.2
  _ZNK9QVector4D6lengthEv@Base 5.0.2
  _ZNK9QVector4Dcv8QVariantEv@Base 5.0.2
- (optional=templinst|arch=armel armhf hurd-i386 i386 kfreebsd-i386 m68k mips 
mipsel powerpc)_ZSt4swapIN8QVariant7PrivateEEvRT_S3_@Base 5.0.2
+ (optional=templinst)_ZSt4swapIN8QVariant7PrivateEEvRT_S3_@Base 5.0.2
  _ZTI10QBasicDrag@Base 5.1.0 1
  _ZTI10QBlittable@Base 5.0.2 1
  _ZTI10QClipboard@Base 5.0.2
dh_makeshlibs -V --remaining-packages
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see 
diff output below
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libqt5core5a/DEBIAN/symbols doesn't match 
completely debian/libqt5core5a.symbols
--- debian/libqt5core5a.symbols (libqt5core5a_5.5.1+dfsg-16_powerpcspe)
+++ dpkg-gensymbols59F0sO   2016-05-21 22:04:24.844398784 +
@@ -98,9 +98,9 @@
  _Z5qHashRK9QBitArrayj@Base 5.0.2
  _Z5qHashRK9QDateTimej@Base 5.0.2
  _Z5qHashdj@Base 5.3.0
- (arch=!alpha !powerpc !ppc64 !ppc64el !s390x !sparc)_Z5qHashej@Base 5.3.0
+#MISSING: 5.5.1+dfsg-16# (arch=!alpha !powerpc !ppc64 !ppc64el !s390x 
!sparc)_Z5qHashej@Base 5.3.0
  _Z5qHashfj@Base 5.3.0
- (arch=alpha powerpc ppc64 ppc64el s390x sparc)_Z5qHashgj@Base 5.4.0
+ _Z5qHashgj@Base 5.4.0
  _Z5qQNaNv@Base 5.0.2
  _Z5qSNaNv@Base 5.0.2
  _Z5qdtoadiiPiS_PPcS1_@Base 5.0.2
@@ -2730,7 +2730,7 @@
  (arch=arm64 armel armhf)_ZN7QString8vsprintfEPKcSt9__va_list@Base 5.3.0
  _ZN7QString9fromUtf16EPKti@Base 5.0.2
  (arch=alpha)_ZN7QString9vasprintfEPKc13__va_list_tag@Base 5.5.0
- (arch=amd64 kfreebsd-amd64 powerpc s390x 
x32)_ZN7QString9vasprintfEPKcP13__va_list_tag@Base 5.5.0
+ _ZN7QString9vasprintfEPKcP13__va_list_tag@Base 5.5.0
  (arch=hurd-i386 i386 kfreebsd-i386 ppc64 
ppc64el)_ZN7QString9vasprintfEPKcPc@Base 5.5.0
  (arch=hppa mips mips64el mipsel sparc64)_ZN7QString9vasprintfEPKcPv@Base 5.5.1
  (arch=arm64 armel armhf)_ZN7QString9vasprintfEPKcSt9__va_list@Base 5.5.0
@@ -4957,8 +4957,8 @@
  _ZNK9QtPrivate18ResultIteratorBase9batchSizeEv@Base 5.0.2
  _ZNK9QtPrivate18ResultIteratorBaseeqERKS0_@Base 5.0.2
  _ZNK9QtPrivate18ResultIteratorBaseneERKS0_@Base 5.0.2
- 
(optional=templinst|arch=powerpcspe)_ZNSt17_Temporary_bufferIP5QPairI21QPersistentModelIndexjES2_ED1Ev@Base
 5.0.2
- 
(optional=templinst|arch=powerpcspe)_ZNSt17_Temporary_bufferIP5QPairI21QPersistentModelIndexjES2_ED2Ev@Base
 5.0.2
+#MISSING: 5.5.1+dfsg-16# 
(optional=templinst|arch=powerpcspe)_ZNSt17_Temporary_bufferIP5QPairI21QPersistentModelIndexjES2_ED1Ev@Base
 5.0.2
+#MISSING: 5.5.1+dfsg-16# 
(optional=templinst|arch=powerpcspe)_ZNSt17_Temporary_bufferIP5QPairI21QPersistentModelIndexjES2_ED2Ev@Base
 5.0.2
  
(optional=templinst)_ZNSt3_V28__rotateIP21QPersistentModelIndexEET_S3_S3_S3_St26random_access_iterator_tag@Base
 5.5.0
  
(optional=templinst)_ZNSt3_V28__rotateIPiEET_S2_S2_S2_St26random_access_iterator_tag@Base
 5.5.0
  (optional=templinst)_ZSt13move_backwardIPiS0_ET0_T_S2_S1_@Base 5.5.0
dpkg-gensymbols: warning: debian/libqt5widgets5/DEBIAN/symbols doesn't match 
completely debian/libqt5widgets5.symbols
--- debian/libqt5widgets5.symbols (libqt5widgets5_5.5.1+dfsg-16_powerpcspe)
+++ dpkg-gensymbolsSUWj53   2016-05-21 22:05:46.085217440 +
@@ -7449,8 +7449,8 @@
  _ZNK9QUndoView5groupEv@Base 5.0.2
  _ZNK9QUndoView5stackEv@Base 5.0.2
  _ZNK9QUndoView9cleanIconEv@Base 5.0.2
- 
(optional=templinst|subst|arch=powerpcspe)_ZSt11__push_heapIN5QListI5QPairIPN23QFileSystemModelPrivate15QFileSystemNodeEiEE8iteratorE{qptrdiff}S5_22QFileSystemModelSorterEvT_T0_SA_T1_T2_@Base
 5.0.2 

Bug#824969: bubblewrap: inappropriate Section/Priority, and other minor fixes

[Simon McVittie]

Package: bubblewrap
Version: 0~git160513-3
Severity: minor
Tags: patch

bubblewrap is currently Section: web, which seems wrong: it isn't a web
server or client. I would suggest Section: admin, like flatpak and sudo;
does that seem like the best Section to you?

The Priority should probably also be optional, since the gnome metapackage
is somewhat likely to depend on bubblewrap in future, via the dependency
chain gnome -> gnome-software -> flatpak -> bubblewrap.

To fix this fully, after agreeing on a correct Section and Priority,
we'll need to report a ftp.debian.org bug asking for the ftp-masters
to correct the override file. I'm happy to open that bug.

I've also made some other minor fixes, also attached:

* debian/copyright contains some copy/paste errors
* I think the package should be Architecture: linux-any like flatpak,
  since it uses Linux-specific syscalls and namespacing/container features

Patches are attached, and also available in git here:

ssh://git.debian.org/git/users/smcv/bubblewrap.git

Because it's closely linked to flatpak, I would like to co-maintain this
package, preferably by copying that git repository into collab-maint git.

Regards,
S
>From 396fa8dd21697c4bf270f638a4ce074ee4661902 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 May 2016 15:11:41 +0100
Subject: [PATCH 1/7] debian/copyright: correct package name and source

---
 debian/changelog | 6 ++
 debian/copyright | 4 ++--
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 558a546..fe333b9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+bubblewrap (0~git160513-3) UNRELEASED; urgency=medium
+
+  * debian/copyright: correct package name and source
+
+ -- Simon McVittie   Sat, 21 May 2016 15:10:56 +0100
+
 bubblewrap (0~git160513-2) unstable; urgency=low
 
   * Install bwrap binary setuid (closes: #824646).
diff --git a/debian/copyright b/debian/copyright
index ef1f2a3..6d5d6de 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,6 +1,6 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: paxctld
-Source: https://grsecurity.net
+Upstream-Name: bubblewrap
+Source: https://github.com/projectatomic/bubblewrap/
 
 Files: *
 Copyright: 2016 Alexander Larsson
-- 
2.8.1

>From 45f959a53569679dbf766a48d0296b5aab9c30ca Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 May 2016 15:14:14 +0100
Subject: [PATCH 2/7] debian/control: make the whole package Linux-only

Like Flatpak, this package is inherently non-portable.
---
 debian/changelog | 2 ++
 debian/control   | 4 ++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index fe333b9..3fa6392 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
 bubblewrap (0~git160513-3) UNRELEASED; urgency=medium
 
   * debian/copyright: correct package name and source
+  * debian/control: make the whole package Linux-only. Like Flatpak, this
+package is inherently non-portable.
 
  -- Simon McVittie   Sat, 21 May 2016 15:10:56 +0100
 
diff --git a/debian/control b/debian/control
index 21a4806..0198270 100644
--- a/debian/control
+++ b/debian/control
@@ -2,12 +2,12 @@ Source: bubblewrap
 Section: web
 Priority: extra
 Maintainer: Laszlo Boszormenyi (GCS) 
-Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, libselinux1-dev (>= 2.1.9) [linux-any], libcap-dev, bash-completion, xsltproc, docbook-xsl
+Build-Depends: debhelper (>= 9), dh-autoreconf, pkg-config, libselinux1-dev (>= 2.1.9), libcap-dev, bash-completion, xsltproc, docbook-xsl
 Standards-Version: 3.9.8
 Homepage: https://github.com/projectatomic/bubblewrap
 
 Package: bubblewrap
-Architecture: any
+Architecture: linux-any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: setuid wrapper for unprivileged chroot and namespace manipulation
  Core execution engine for unprivileged containers that works as a setuid
-- 
2.8.1

>From f09d06ad3f76acaed755bd037fc0a757cea7e9a2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 May 2016 15:27:06 +0100
Subject: [PATCH 3/7] Move from Section: web to Section: admin

---
 debian/changelog | 1 +
 debian/control   | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index 3fa6392..2d464a3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -3,6 +3,7 @@ bubblewrap (0~git160513-3) UNRELEASED; urgency=medium
   * debian/copyright: correct package name and source
   * debian/control: make the whole package Linux-only. Like Flatpak, this
 package is inherently non-portable.
+  * Move from Section: web to Section: admin
 
  -- Simon McVittie   Sat, 21 May 2016 15:10:56 +0100
 
diff --git a/debian/control b/debian/control
index 0198270..e0ad3d5 100644
--- a/debian/control
+++ 

Bug#824970: "Send file via KDE Connect service" does not appear on file context menu despite being enabled in dolphin

[Lisandro Damián Nicanor Pérez Meyer]

Package: kdeconnect
Version: 0.9g-1
Severity: normal
Tags: upstream patch
Forwarded: https://bugs.kde.org/show_bug.cgi?id=362684

Please see the upstream bug report.


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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

Versions of packages kdeconnect depends on:
ii  kde-cli-tools  4:5.4.3-1
ii  libc6  2.22-9
ii  libfakekey00.1-9
ii  libkf5configcore5  5.22.0-1
ii  libkf5configwidgets5   5.22.0-1
ii  libkf5coreaddons5  5.22.0-1
ii  libkf5dbusaddons5  5.22.0-1
ii  libkf5i18n55.22.1-1
ii  libkf5kcmutils55.16.0-1
ii  libkf5kiocore5 5.16.0-1.1
ii  libkf5kiofilewidgets5  5.16.0-1.1
ii  libkf5kiowidgets5  5.16.0-1.1
ii  libkf5notifications5   5.22.0-1
ii  libkf5service-bin  5.22.0-1
ii  libkf5service5 5.22.0-1
ii  libkf5waylandclient5   4:5.22.0-1
ii  libkf5widgetsaddons5   5.22.0-1
ii  libqca-qt5-2   2.1.1-2
ii  libqca-qt5-2-plugins   2.1.1-2
ii  libqt5core5a   5.5.1+dfsg-16+b1
ii  libqt5dbus55.5.1+dfsg-16+b1
ii  libqt5gui5 5.5.1+dfsg-16+b1
ii  libqt5network5 5.5.1+dfsg-16+b1
ii  libqt5qml5 5.5.1-3
ii  libqt5widgets5 5.5.1+dfsg-16+b1
ii  libqt5x11extras5   5.5.1-3
ii  libstdc++6 6.1.1-4
ii  libx11-6   2:1.6.3-1
ii  libxtst6   2:1.2.2-1+b1
ii  plasma-workspace   4:5.4.3-2
ii  sshfs  2.5-1

kdeconnect recommends no packages.

kdeconnect suggests no packages.

-- no debconf information

Bug#824885: override: debconf-i18n:localization/important

[Cyril Brulebois]

Ansgar Burchardt  (2016-05-20):
> Package: ftp.debian.org
> Severity: normal
> 
> [ For after the d-i alpha currently in preparation ]
> 
> Please consider demoting debconf-i18n from required to important.
> debconf now only recommends it instead of having a strict dependency
> and i18n support isn't required in minimal installations.
> 
> This should also allow demoting several perl modules:
> libtext-iconv-perl, libtext-wrapi18n-perl, libtext-charwidth-perl (or
> demoting those even to "optional" with the reasoning given in #758234)
> 
> Ansgar

The new d-i alpha is out, so feel free to update overrides as you see fit.

Thanks for checking with debian-boot@.


KiBi.


signature.asc
Description: Digital signature

Bug#824968: bubblewrap: --dev and --unshare-user don't work together

[Simon McVittie]

Package: bubblewrap
Version: 0~git160513-2
Severity: normal
Tags: patch
Forwarded: https://github.com/projectatomic/bubblewrap/pull/71

"bwrap --ro-bind / / --unshare-user --uid 2 --gid 3 /bin/sh" runs the
wrapped shell in its own user namespace with uid 2 and gid 3, as expected.

Similarly, "bwrap --ro-bind / / --dev /dev /bin/sh" runs the wrapped
shell with a minimal /dev, as expected.

However, combining "--dev /dev" with "--unshare-user" fails on Debian
kernels with their default configuration (kernel.unprivileged_userns_clone=0);
in particular, this breaks flatpak-builder. Alex Larsson has proposed
patches upstream for this issue, which I have applied to the embedded
copy of bubblewrap in flatpak 0.6.0-2.

Patches are attached, and also available in git here:

ssh://git.debian.org/git/users/smcv/bubblewrap.git

among several others.

Ideally, I would like to copy that git repository into collab-maint,
and commit this sort of thing directly as a co-maintainer.

Regards,
S
>From d8cbc3d8e3f43e56f43285f6fe4cb2c923f794cc Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sat, 21 May 2016 17:31:10 +0100
Subject: [PATCH 6/7] Add patches from upstream bug 71 to make --dev coexist
 with --unshare-user

---
 debian/changelog   |   2 +
 debian/patches/Add-unshare-user-try.patch  |  57 ++
 ...tuid-no-unprivileged-user-namespaces-work.patch | 197 +
 debian/patches/series  |   2 +
 4 files changed, 258 insertions(+)
 create mode 100644 debian/patches/Add-unshare-user-try.patch
 create mode 100644 debian/patches/Make-setuid-no-unprivileged-user-namespaces-work.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 00aad10..77fece6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -7,6 +7,8 @@ bubblewrap (0~git160513-3) UNRELEASED; urgency=medium
   * Increase Priority to optional, because this tool is likely to be
 depended on by gnome-software (via Flatpak) in future
   * debian/gbp.conf: add DEP-14-style git-buildpackage configuration
+  * Add patches from upstream bug 71 to make --dev coexist with
+--unshare-user
 
  -- Simon McVittie   Sat, 21 May 2016 15:10:56 +0100
 
diff --git a/debian/patches/Add-unshare-user-try.patch b/debian/patches/Add-unshare-user-try.patch
new file mode 100644
index 000..1053ad7
--- /dev/null
+++ b/debian/patches/Add-unshare-user-try.patch
@@ -0,0 +1,57 @@
+From: Alexander Larsson 
+Date: Fri, 20 May 2016 15:13:57 +0200
+Subject: Add --unshare-user-try
+
+This optionally enables user namespaces, but ignores it if its
+not supported by the kernel.
+
+Note: For this to make any sense, bwrap has to be setuid,
+because unprivileged use requires user namespaces.
+
+Bug: https://github.com/projectatomic/bubblewrap/pull/71
+---
+ bubblewrap.c | 10 ++
+ 1 file changed, 10 insertions(+)
+
+diff --git a/bubblewrap.c b/bubblewrap.c
+index 59407a7..6c4664e 100644
+--- a/bubblewrap.c
 b/bubblewrap.c
+@@ -148,6 +148,7 @@ usage (int ecode, FILE *out)
+"--versionPrint version\n"
+"--args FDParse nul-separated args from FD\n"
+"--unshare-user   Create new user namespace (may be automatically implied if not setuid)\n"
++   "--unshare-user-try   Create new user namespace if possible else continue by skipping it\n"
+"--unshare-ipcCreate new ipc namespace\n"
+"--unshare-pidCreate new pid namespace\n"
+"--unshare-netCreate new network namespace\n"
+@@ -840,6 +841,7 @@ read_priv_sec_op (int  read_socket,
+ 
+ char *opt_chdir_path = NULL;
+ bool opt_unshare_user = FALSE;
++bool opt_unshare_user_try = FALSE;
+ bool opt_unshare_pid = FALSE;
+ bool opt_unshare_ipc = FALSE;
+ bool opt_unshare_net = FALSE;
+@@ -955,6 +957,10 @@ parse_args_recurse (int*argcp,
+ {
+   opt_unshare_user = TRUE;
+ }
++  else if (strcmp (arg, "--unshare-user-try") == 0)
++{
++  opt_unshare_user_try = TRUE;
++}
+   else if (strcmp (arg, "--unshare-ipc") == 0)
+ {
+   opt_unshare_ipc = TRUE;
+@@ -1327,6 +1333,10 @@ main (intargc,
+   if (!is_privileged)
+ opt_unshare_user = TRUE;
+ 
++  if (opt_unshare_user_try &&
++  stat ("/proc/self/ns/user", ) == 0)
++opt_unshare_user = TRUE;
++
+   if (argc == 0)
+ usage (EXIT_FAILURE, stderr);
+ 
diff --git a/debian/patches/Make-setuid-no-unprivileged-user-namespaces-work.patch b/debian/patches/Make-setuid-no-unprivileged-user-namespaces-work.patch
new file mode 100644
index 000..ec18f7e
--- /dev/null
+++ b/debian/patches/Make-setuid-no-unprivileged-user-namespaces-work.patch
@@ -0,0 +1,197 @@
+From: Alexander Larsson 
+Date: Fri, 20 

Bug#824811: firmware-realtek: rtl8192ce doesn't transfer data

[Tomasz Pona]

Hello,
> Did this work with an older version of firmware-realtek?
>
I tried only 0.43 and 20160110-1~bpo8+1.
> What makes you think this is a firmware bug?
>
I think this is rtl8192ce driver bug, I don't know what 'firmware' term exactly 
means in package name, but the driver is in the firmware-realtek package.
I suspect the driver because:- I know my PCI WiFi device works- obviously a lot 
of PCI drivers work- rtl8192cu works
So the solution could be something like:- take PCI part from any known working 
driver- take rtl8192 part from USB driver- connect these 2 into working 
rtl8192ce

Regards,koczis


> Subject: Re: Bug#824811: firmware-realtek: rtl8192ce doesn't transfer data> 
> From: b...@decadent.org.uk
> To: koczi...@hotmail.com; 824...@bugs.debian.org
> Date: Sat, 21 May 2016 17:27:25 +0100
> 
> Control: tag -1 moreinfo
> 
> On Fri, 2016-05-20 at 01:37 +0200, koczis wrote:
> > Package: firmware-realtek
> > Version: 20160110-1~bpo8+1 & 0.43
> > Severity: important
> [...]
> 
> Did this work with an older version of firmware-realtek?
> 
> What makes you think this is a firmware bug?
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Experience is what causes a person to make new mistakes instead of old ones.
  

Bug#824967: RFS: budgie-desktop/10.2.5-1 [ITP]

[foss.freedom]

Package: sponsorship-requests
Severity: wishlist

Dear Mentors,

I am looking for a sponsor for my package "budgie-desktop"

Package name: budgie-desktop
Version : 10.2.5
Upstream Author : i...@solus-project.com
URL : https://github.com/solus-project/budgie-desktop
License : LGPL-2.1/GPL2.0
Programming Lang: Vala
Description : The Budgie Desktop is the flagship desktop of the Solus
Operating System.

 Section : gnome

It builds the following binary packages:
Package: budgie-desktop
Description: Desktop package for budgie-desktop
 Budgie is the flagship desktop of the Solus Linux Distribution,
 a Solus project. Designed with the modern user in mind, it focuses on
 simplicity and elegance. A huge advantage for the Budgie desktop is
 that it is not a fork of another project, but rather one written from
 scratch with integration in mind.

Package: budgie-core
Description: Core package for budgie-desktop
 This is the base package for budgie-desktop

Package: libbudgie-plugin0
Section: libs
Description: plugin library for budgie-desktop
 This adds the plugin library to budgie-desktop

Package: libbudgietheme0
Section: libs
Description: theme library for budgie-desktop
 This adds the theme controls for budgie-desktop

Package: libraven0
Section: libs
Description: raven library for budgie-desktop
 This provides the budgie-desktop user-defined settings called raven.

Package: budgie-core-dev
Section: libdevel
Description: development package for budgie-desktop
 Development library allowing compiling against the budgie-desktop API

Package: gir1.2-budgie-desktop-1.0
Section: introspection
Description: GNOME introspection library for budgie-desktop
 This is the introspection library against the budgie-desktop API
 and allows creating plugins in python and Vala

Package: budgie-desktop-doc
Section: doc
Description: documentation files for the budgie-desktop
 This package contains the API documentation in HTML format

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

  https://mentors.debian.net/package/budgie-desktop


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

dget -x
https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.2.5-1.dsc

Further Information:

budgie-desktop is the flagship desktop system for Solus.  Solus is an tier
1 distro using its own packaging mechanism eopkg.  Solus supports only its
own distro (naturally) in a 64bit intel based system only.  The maintainer
does accept bug-reports for other distro's as long as it is reproducible in
Solus and/or the maintainer considers that the wider use of its desktop
environment would be enhanced.

The maintainer does produce OBS packages for a number of distros - but not
Debian.

For myself, I am the project leader of a Ubuntu based distro called
budgie-remix that uses budgie-desktop as its choice of desktop.

Thus, my direct interest is ensuring that Debian and its derivative
eco-system is enhanced by the incorporation of this exciting new desktop
system.

Packaging Notes:
  To produce a debian package that works in debian and ubuntu I have used a
more traditional rules based package rather than a simpler debhelper
auto-build mechanism.  I have had to do it this way because debhelper does
not produce binaries that actually work on a Ubuntu based platform - the
desktop system fails to launch at logon.  The failure is silent - there is
no obvious reason why debhelper autobuild fails to produce a working
solution.

I've tested this traditional package mechanism on Debian Stretch 64bit
(up-to-date today), Debian Stretch 32bit (up-to-date today), Ubuntu (64bit)
16.04 and Ubuntu (32bit) 16.04.

This build package has been used for two upstream releases now for
budgie-remix and thus I have confidence that this mechanism will be
sustainable in the long-term.

The patches incorporated are required for specifically Debian and Ubuntu
and are used in budgie-remix itself.

Changes since the last upload:

  * initial Debian package

Regards,
David Mohammed (fossfreedom)

Bug#824835: tex-common: fmtutil fails

[D. B.]

Thanks, Paul: I can confirm the below on unstable. Executing sudo aptitude
install context sorted this...

...but seeing as this pulled in a whopping 365 MB of archives (and that's
just the compressed version), which I might've never voluntarily installed,
possibly just to get a single file that restores working updates to the
wanted parts of my system... and of which apparently a full 207 MB are
purely doc packages... I can't help but feel there must be a better way for
upstream to handle all this.

Well, that's not Debian's fault, so what can ya do. Thanks again!


On Sat, 21 May 2016 11:49:31 +0200 Paul Seelig  wrote:
> i stumbled over the line stating:
>
> ! I can't find file `syst-tex.mkii'.
>
> Checking with apt-file, syst-tex.mkii appeared to be contained in two
> packages, namely 'context' and 'texlive-latex-base'. Apparently there
> was a change, as this file is no longer part of texlive-latex-base, but
> only contained in context, which was not installed before on my systems.
>
> After adding the context package, all remaining packages configured just
> fine.
>
> Looks as if we now also require to have context installed.

Bug#791919: RFP: USBGuard -- protect your computer against rogue USB devices

[Rebecca N. Palmer]

Control: merge -1 813809

I'd also like to see this (or an equivalent: I'm not aware of any, but 
haven't looked much) in Debian, and am willing to try packaging it, but 
am not sure whether it's a good idea for a non-DD, 
non-security-specialist to maintain a security tool.


It's in Fedora, with packaging [0] that looks fairly easy to translate 
to Debian (if that's legal - I don't know whether License: in a Fedora 
.spec means "including this packaging"); Tails are considering it [1]. 
A previous attempt to build a .deb package hit the build error [2].


[0] https://apps.fedoraproject.org/packages/usbguard/sources/spec
[1] https://labs.riseup.net/code/issues/9569
[2] https://lists.debian.org/debian-mentors/2015/09/msg00116.html

Bug#721022: abiword: can't see any words in file

[Jeremy Bicha]

I am unable to duplicate this bug with abiword 3.0.1-6 on current
Debian 'testing' using the GNOME desktop environment.

Please verify whether you are still experiencing this bug or if it has
been fixed.

The Abiword developers ask to make sure you have appropriate Asian
fonts installed.

Thank you,
Jeremy

Bug#824416: FW: Bug#824416: cpu fan doesn't start

[John]

Control: reassign -1 src:linux 3.2.78-1
Control: tag -1 moreinfo

>Did it work when running an earlier kernel version or an earlier
>version of Debian?

No it did not.

>Why do you say the chip is problematic?
It is by design. That is why architects corrected the protocol several times.

>Why is the lm75 driver even
>loaded?  That shouldn't happen automatically and is not necessary as
>the BIOS should manage fan speed by itself.

It’s loaded by lm-sensors I think..

>We prefer that you use 'reportbug' which will run our own scripts to
>gather information.

If reportbug worked I would use it

>What is the kernel command line?  (It's in /proc/cmdline)

“BOOT_IMAGE=/boot/vmlinuz-3.2.0-4-486 
root=UUID=51d2ccc3-9ce7-4665-af90-623aa7f8a28a ro quiet”

John.

Bug#760945: postinst overwrites permissions set by admin, destroys configuration for slaves

[Iustin Pop]

On 2014-09-09 13:29:28, Sven Hartge wrote:
> Package: smokeping
> Version: 2.6.9-1
> Severity: normal
> 
> Hi!
> 
> In the postinst the following commands are executed:
> 
> ,
> |   chown smokeping:smokeping /var/lib/smokeping
> |   chown smokeping:smokeping /etc/smokeping/smokeping_secrets
> |   chmod 640 /etc/smokeping/smokeping_secrets
> `
> 
> This unconditionally destroys any custom permissions the admin may have
> set. Overwriting the permissions for /etc/smokeping/smokeping_secrets is
> especially desastrous because this file needs to be read by the www-data
> user (or group) to allow slaves to connect correctly.
> 
> Right now the only option is to use POSIX-ACLs to allow www-data to read
> that file because if you just use "chgrp www-data" this change will get
> overwritten the next time the package is updated.

Since there's no mechanism (AFAIK) for automatically handling custom
permissions for conffiles, and both the admin and the package fight over
this, the first solution that comes to mind is to add debconf questions
for owner and mode, and always use debconf/the package to manage the
permissions. This would solve both problems (conflicts and custom
permissions).

A simpler alternative but not that flexible would be to add only one
question ("support slaves"), which would different, but still hard-coded
permissions.

Thoughts?

iustin


signature.asc
Description: PGP signature

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Petter Reinholdtsen]

[Cyril Brulebois]
> There's no udebs involved in what I summarized for Blends.

Exactly.  I suspect using udebs to enable blends is be a better idea
than making the Blends tasksel tasks priority standard.

> Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
> certainly interact with it so that it behaves as desired.

You misunderstand the role of the udebs.  The Debian Edu udeb ask for
education-tasks to be installed, and then the normal d-i take care of
the rest to get the correct Debian Edu tasks installed using tests and
the locale settings.  Sure, we can come up with a new way to do it, but
my point is that we are using this feature of tasksel today, and there
is no alternative I know of that is equally robust and well integrated
into the installer.

-- 
Happy hacking
Petter Reinholdtsen

Bug#788003: smokeping package fails to run with fping

[Iustin Pop]

On 2015-06-07 18:22:29, Bernd Naumann wrote:
> Package: smokeping
> Version: 2.6.8-2
> 
> When I install `smokeping` via `apt-get` the daemon fails to start,
> cause of
> """
> Starting latency logger daemon: smokepingERROR:
> /etc/smokeping/config.d/Probes, line 5: ERROR: FPing 'binary' does not
> point to an executable
> """
> 
> This is quiet a minor bug:
> 
> $ grep fping /etc/smokeping/config.d/Probes
> binary = /usr/bin/fping
> $ which fping
> /usr/local/sbin/fping
> 
> This should be fixed easily.

This sounds wrong. `/usr/local/sbin/fping' tells me that you have fping
installed locally from sources, not from a debian package (which would
install it in /usr/bin).

Are you sure you installed smokeping and its recommends?

regards,
iustin


signature.asc
Description: PGP signature

Bug#824965: diodon: Update to new upstream version 1.5.0

[Oliver Sauder]

Package: diodon
Version: 1.3.0-1
Severity: important

Hey.

There is a new upstream version 1.5.0 diodon would need to be updated
too: https://launchpad.net/diodon/+milestone/1.5.0

I will follow up with this update but creating this issue as reference.

Regards,
Oliver

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Cyril Brulebois]

Petter Reinholdtsen  (2016-05-21):
> [Cyril Brulebois]
> > I'm very much not happy with tasksel's picking up whatever people have
> > managed to get into a basic system, and I would very much prefer if it
> > would only look at its own debian-tasks.desc when running from the
> > installer. Any objections?
> 
> Yes.
> 
> Debian Edu uses the current behaviour to install its tasks during
> installation, but we do not use standard priority tasks to get into the
> installer, we use udebs to trigger the installation of education-tasks.
> 
> Being able to add extra tasks using udebs is a feature, not a bug.

There's no udebs involved in what I summarized for Blends.


Also: If pkgsel changes the way it calls tasksel, debian-edu udebs can
certainly interact with it so that it behaves as desired.


KiBi.


signature.asc
Description: Digital signature

Bug#824416: FW: Bug#824416: cpu fan doesn't start

[Ben Hutchings]

On Sat, 2016-05-21 at 23:27 +0300, John wrote:
> Control: reassign -1 src:linux 3.2.78-1
> Control: tag -1 moreinfo
> 
> > 
> > Did it work when running an earlier kernel version or an earlier
> > version of Debian?|
> No it did not.
> 
> > 
> > Why do you say the chip is problematic?
> It is by design. That is why architects corrected the protocol several times.
> 
> > 
> > Why is the lm75 driver even
> > loaded?  That shouldn't happen automatically and is not necessary as
> > the BIOS should manage fan speed by itself.
> It’s loaded by lm-sensors I think..
[...]

Please try reconfiguring lm-sensors to not load the lm75 driver.  Or,
if it is listed in /etc/modules or /etc/modules-load.d/*.conf, remove
or comment-out that line.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

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

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[Andrey Rahmatullin]

On Sat, May 21, 2016 at 02:02:49PM -0700, optix2...@teitoku.net wrote:
> > d/rules:
> > - why -D_FORTIFY_SOURCE=1? Such things should be documented
> 
> For security reasons, as this is an internet accessible daemon that
> accepts user input. 
What I've meant was "you replaced stronger default flag with a weaker
one". As you know about dpkg-buildflags you should know that the 'fortify'
option is enabled by default and that it adds -D_FORTIFY_SOURCE=2.

> It also gets rid of the lintian info tag
> "hardening-no-fortify-functions". 
If you have this tag then something is wrong. If it's also fixed by adding
-D_FORTIFY_SOURCE to CFLAGS then your upstream build system doesn't handle
CPPFLAGS correctly. It should be fixed to handle them.

> > - you can probably replace override_dh_auto_clean with debian/clean
> 
> I can't seem to find any documentation regarding debian/clean in the
> maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
> How is debian/clean supposed to be used?
man dh_clean
To remove files not removed by dh_auto_clean.

> > - why this package not only Conflicts but Replaces iroffer? Do you know
> >   how will apt handle this relationship? Do you intend to do anything with
> >   the iroffer package itself (it's orphaned ATM)? If you want to replace
> >   it completely then the replacing procedure is different, see
> >   https://wiki.debian.org/Renaming_a_Package
> 
> iroffer-dinoex is intended to be a drop-in replacement for the original
> iroffer. The binaries have the same name, and the config formats are
> unchanged.
> Based on what I could tell from the docs (correct me if I'm wrong)
> [www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
> this is the correct way to have a package be an alternative drop in
> replacement (ie how MTA's are managed).
> I do not intend to take over the iroffer package completely. This is merely
> an alternative to the original iroffer that can be a drop in
> upgrade/replacement.
Just Conflicts could be enough but it won't uninstall the other package.
I don't know how Conflicts+Replaces will work, you'll need to test this.
Note that you still won't be able to install iroffer without manually
removing iroffer-dinoex (at least that's what I think).

> > d/copyright:
> > - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
> >   option) any later version" in the texts
> I assumed "or (at your option) any later version" meant that the upstream
> author could (at their discretion) upgrade the license to a newer version
> of GPL.
> Not that an end-user (me) could upgrade to a newer version at my 
> descretion. I'm not a lawyer, so I chose to leave it untouched.
You seem to be confusing several things here.
The upstream authors can do anything they want but the license clauses say
what can other people do instead.
"License: GPL-2" means "you can use GPL 2", "License: GPL-2+" means "you
can use GPL 2 or (at your option) any later version".
And the upstream LICENSE doesn't say about "any later version", so you
didn't "leave it untouched".
Actually, the upstream LICENSE includes the OpenSSL linking exception for
some files and tells to look into the files to find out which of them have
what licenses so your d/copyright should be more fine-grained than now.

> > - using GPL for debian/ while having MIT and LGPL in the upstream source
> >   is discouraged and may cause problems if debian/ contains e.g. patches
> What's the correct way to resolve this, choose a less restrictive license
> for debian/? 
Yes.

> Is there a list of recommended licenses?
I think the currently recommended simple non-copyleft license (fir
anything, not just debian/) is Expat.

> no-upstream-changelog should be an I tag.
Why do you think so?

> > - manpage-has-bad-whatis-entry override says "Upstream manpage" which
> >   doesn't sound like a valid cause to me
> Should I just leave the lintian warning as-is until it's fixed upstream?
> Or should I be patching the manpage until it's fixed upstream?
The second option is preferable, note that the tag is W.
But the first one is better than overriding it (you should override only
things that are not problems, not things that are currently
hard/impossible to fix problems)

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#824888: Exim procmail transport missing options for local parts (ie plus addressing)

[Marc Haber]

On Sat, May 21, 2016 at 08:15:46AM -0600, Brandon Peterson wrote:
> My mistake, I forgot that I customized the 900_exim4-config_local_user
> router years ago, I was thinking yesterday that it had been part of the
> standard Debian configuration.

I would recommend using something other than _exim4-config_ in the
file name to clearly distinguish local files from distribution files.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#824964: ITP: budgie-desktop -- budgie desktop system

[foss.freedom]

Package: wnpp
Severity: wishlist

Owner: David Mohammed 

Package name: budgie-desktop
Version : 10.2.5
Upstream Author : i...@solus-project.com
URL : https://github.com/solus-project/budgie-desktop
License : LGPL-2.1/GPL2.0
Programming Lang: Vala
Description : The Budgie Desktop is the flagship desktop of the Solus
Operating System.

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

>> iroffer-dinoex.lintian-overrides:
>> - you shouldn't override P tags

>Which P tag did I override? no-upstream-changelog should be an I tag.
Sorry, I looked again and you're right. no-upstream-changelog is a P tag.
I've removed the override.

Regards,
 Weilu

Bug#824712: RFH: smokeping

[Iustin Pop]

On 2016-05-18 18:22:55, Antoine Beaupré wrote:
> I need help maintaining the smokeping package. I do not really use it
> anymore and i'd be happy to help people to sponsor it. There's a bunch
> of obscure bugs all over the place, and while I think the package
> mostly works, it's just a wild guess since well, I'm not using it
> right now.

Hi Antoine,

How would you prefer to get help? I'll try to do a bit of BTS cleanup,
but for code changes, is it fine to do direct VCS commits, or would you
prefer git pull requests?

I do use smokeping, so I'm happy to help as time allows.

regards,
iustin


signature.asc
Description: PGP signature

Bug#823365: Ahh ... Probably already fixed upstream

[Reiner Herrmann]

Hi Guy,

On Thu, May 05, 2016 at 01:26:04PM +0100, Guy Heatley wrote:
> > Can you please recheck with libselinux1 2.5-1 (when it lands in testing)
> > and tell me if it solved your problem?
> 
> I certainly will.
> 
> BTW, the workaround detailed on the github site seems to work, namely
> adding this switch to the commandline:

Did you already have the possibility to check if firejail works again
without the workaround?

Kind regards,
  Reiner


signature.asc
Description: Digital signature

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Petter Reinholdtsen]

[Cyril Brulebois]
> I'm very much not happy with tasksel's picking up whatever people have
> managed to get into a basic system, and I would very much prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

Yes.

Debian Edu uses the current behaviour to install its tasks during
installation, but we do not use standard priority tasks to get into the
installer, we use udebs to trigger the installation of education-tasks.

Being able to add extra tasks using udebs is a feature, not a bug.

-- 
Happy hacking
Petter Reinholdtsen

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[optix2000]

Hi Andrey,

Thanks for looking over this. I've replied to your concerns in line and
created a new build which (hopefully) addresses most of them.

> d/rules:
> - why -D_FORTIFY_SOURCE=1? Such things should be documented

For security reasons, as this is an internet accessible daemon that
accepts user input. It also gets rid of the lintian info tag
"hardening-no-fortify-functions". The docs for D_FORTIFY_SOURCE state it
won't break anything (compared to D_F_S=2). From my own testing, there's
no issues with the binary.
I've added a comment, and documented in Readme.debian (That is the
correct place to document, right?)

> - commented out -Wl,--as-needed looks strange, if it doesn't work/isn't
>   needed you shouldn't include this line at all
> - "dh_make generated override targets" sounds strange. "This is example
>   for Cmake (See https://bugs.debian.org/641051 )" sounds even strange,
>   especially when looking at that bug. That commented out
>   dh_auto_configure is strange too, especially the -DCMAKE_LIBRARY_PATH
>   part.

These are all comments that came from the debian/rules template from
using dh_make (which is why they make no sense). I've removed them in the
latest build.

> - you can probably replace override_dh_auto_clean with debian/clean

I can't seem to find any documentation regarding debian/clean in the
maint-guide [https://www.debian.org/doc/manuals/maint-guide/dother.en.html]
How is debian/clean supposed to be used?

> README.source even says "You WILL either need to modify or delete this
>   file"

Oops. Removed.

> d/control:
> - commented out Vcs-* fields should be either removed or uncommented and
>   edited

Removed in the latest build.

> - why this package not only Conflicts but Replaces iroffer? Do you know
>   how will apt handle this relationship? Do you intend to do anything with
>   the iroffer package itself (it's orphaned ATM)? If you want to replace
>   it completely then the replacing procedure is different, see
>   https://wiki.debian.org/Renaming_a_Package

iroffer-dinoex is intended to be a drop-in replacement for the original
iroffer. The binaries have the same name, and the config formats are
unchanged.
Based on what I could tell from the docs (correct me if I'm wrong)
[www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces],
this is the correct way to have a package be an alternative drop in
replacement (ie how MTA's are managed).
I do not intend to take over the iroffer package completely. This is merely
an alternative to the original iroffer that can be a drop in
upgrade/replacement.

> d/copyright:
> - it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
>   option) any later version" in the texts

I assumed "or (at your option) any later version" meant that the upstream
author could (at their discretion) upgrade the license to a newer version
of GPL. Not that an end-user (me) could upgrade to a newer version at my 
descretion. I'm not a lawyer, so I chose to leave it untouched.

> - using GPL for debian/ while having MIT and LGPL in the upstream source
>   is discouraged and may cause problems if debian/ contains e.g. patches

What's the correct way to resolve this, choose a less restrictive license
for debian/? Is there a list of recommended licenses?

> d/install is empty

Oops. I had used it for something prior and forgot to remove it.
Removed in the latest build.

> iroffer-dinoex.lintian-overrides:
> - you shouldn't override P tags

Which P tag did I override? no-upstream-changelog should be an I tag.

> - manpage-has-bad-whatis-entry override says "Upstream manpage" which
>   doesn't sound like a valid cause to me

Should I just leave the lintian warning as-is until it's fixed upstream?
Or should I be patching the manpage until it's fixed upstream?

Thanks,
 Weilu

Bug#824963: systemd-fsck run fsck for same disk in parallel

[Yuriy M. Kaminskiy]

Package: systemd
Version: 215-17+deb8u4
Severity: wishlist
Tags: jessie patch fixed-upstream

Dear Maintainer,

When mounting several filesystems, systemd runs all fsck in parallel. 
This is very unoptimal when filesystems shares same (rotational) 
physical disk.

systemd-fsck had provision to run fsck with -l option, but it was
temporarily disabled due to locking conflict between fsck and udev.
This conflict was fixed in util-linux-2.25, and "fsck -l" option 
re-enabled in systemd-217.
As jessie already has fixed version of util-linux (2.25.2), please 
consider cherry-pick commit v216-652-g48d3e8d (and maybe bump Depends on 
util-linux to 2.25 to reflect this) for next jessie point release.

(Debdiff attached).

-- Package-specific info:

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 
'proposed-updates')

Architecture: i386 (x86_64)
Foreign Architectures: amd64

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

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-59
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-6
ii  libc6   2.19-18+deb8u4
ii  libcap2 1:2.24-8
ii  libcap2-bin 1:2.24-8
ii  libcryptsetup4  2:1.6.6-5
ii  libgcrypt20 1.6.3-2+deb8u1
ii  libkmod218-3
ii  liblzma55.1.1alpha+20120614-2+b3
ii  libpam0g1.1.8-3.1+deb8u1
ii  libselinux1 2.3-2
ii  libsystemd0 215-17+deb8u4
ii  mount   2.25.2-6
ii  sysv-rc 2.88dsf-59
ii  udev215-17+deb8u4
ii  util-linux  2.25.2-6

Versions of packages systemd recommends:
ii  dbus1.8.20-0+deb8u1
ii  libpam-systemd  215-17+deb8u4

Versions of packages systemd suggests:
ii  systemd-ui  3-2

-- no debconf information

diff -Nru systemd-215/debian/control systemd-215/debian/control
--- systemd-215/debian/control	2015-11-16 20:08:49.0 +0300
+++ systemd-215/debian/control	2016-03-26 01:01:40.0 +0300
@@ -51,7 +51,7 @@
 Depends: ${shlibs:Depends},
  ${misc:Depends},
  libsystemd0 (= ${binary:Version}),
- util-linux (>= 2.19.1-2),
+ util-linux (>= 2.25),
  mount (>= 2.21),
  initscripts (>= 2.88dsf-53.2),
  sysv-rc,
diff -Nru systemd-215/debian/patches/fsck-re-enable-fsck-l.patch systemd-215/debian/patches/fsck-re-enable-fsck-l.patch
--- systemd-215/debian/patches/fsck-re-enable-fsck-l.patch	1970-01-01 03:00:00.0 +0300
+++ systemd-215/debian/patches/fsck-re-enable-fsck-l.patch	2016-03-26 01:02:22.0 +0300
@@ -0,0 +1,57 @@
+From 48d3e8d07f2978f001cc85b2dddb7f8ec9d07006 Mon Sep 17 00:00:00 2001
+From: Karel Zak 
+Date: Wed, 22 Oct 2014 10:28:42 +0200
+Subject: [PATCH] fsck: re-enable fsck -l
+
+The -l (lock) has been temporary disabled due to conflict with
+udev (https://bugs.freedesktop.org/show_bug.cgi?id=79576)
+
+The problem is fixed since util-linux v2.25 (Jul 2014).
+---
+ README  |  3 ++-
+ src/fsck/fsck.c | 13 -
+ 2 files changed, 6 insertions(+), 10 deletions(-)
+
+diff --git a/README b/README
+index e0edd41..8f7a96e 100644
+--- a/README
 b/README
+@@ -129,8 +129,9 @@ REQUIREMENTS:
+ During runtime, you need the following additional
+ dependencies:
+ 
+-util-linux >= v2.19 (requires fsck -l, agetty -s),
++util-linux >= v2.19 required for agetty -s
+   v2.21 required for tests in test/
++  v2.25 required for fsck -l
+ dbus >= 1.4.0 (strictly speaking optional, but recommended)
+ sulogin (from util-linux >= 2.22 or sysvinit-tools, optional but recommended,
+  required for tests in test/)
+diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
+index dfe97bc..70a5918 100644
+--- a/src/fsck/fsck.c
 b/src/fsck/fsck.c
+@@ -320,16 +320,11 @@ int main(int argc, char *argv[]) {
+ cmdline[i++] = "-T";
+ 
+ /*
+- * Disable locking which conflict with udev's event
+- * ownershipi, until util-linux moves the flock
+- * synchronization file which prevents multiple fsck running
+- * on the same rotationg media, from the disk device
+- * node to a privately owned regular file.
+- *
+- * https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
+- *
+- * cmdline[i++] = "-l";
++ * Since util-linux v2.25 fsck uses /run/fsck/.lock files.
++ * The previous versions use flock for the device and conflict with
++ * udevd, see https://bugs.freedesktop.org/show_bug.cgi?id=79576#c5
+  */
++cmdline[i++] = "-l";
+ 
+ if (!root_directory)
+ cmdline[i++] = "-M";
+-- 
+2.1.4
+
diff -Nru 

Bug#790901: abiword: many GLib-GObject-WARNINGs

[Jeremy Bicha]

I am unable to duplicate this bug with abiword 3.0.1-6 on current
Debian 'testing'.

Please verify whether you are still experiencing this bug or if it has
been fixed.

Thank you,
Jeremy

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Cyril Brulebois]

Cyril Brulebois  (2016-05-21):
> I'm very much not happy with tasksel's picking up whatever people have
> managed to get into a basic system, and I would very much prefer if it
> would only look at its own debian-tasks.desc when running from the
> installer. Any objections?

As a side note, pkgsel calls tasksel with --new-install, but maybe
others are using this flag outside d-i contexts. So I'd probably add
a --internal-tasks-only there.

As another side note, tasksel-data in Debian only has:
  /usr/share/tasksel/descs/debian-tasks.desc

while latest Ubuntu has:
  /usr/share/tasksel/descs/debian-tasks.desc
  /usr/share/tasksel/descs/ubuntu-tasks.desc

so it would be nice to support all desc files shipped in tasksel-data
rather than hardcoding debian-tasks.desc when the --internal-tasks-only
flag is passed.

Martin, I think this would go along the lines of the idea you mentioned
briefly on IRC?


KiBi.


signature.asc
Description: Digital signature

Bug#820488: RFS: roadfighter/1.0.1269-1 [ITP] -- Drive a car in a death race

[Andrey Rahmatullin]

I'm worried about fonts/*.ttf. If these fonts are packaged in Debian they
shouldn't be shipped in the binary package. Otherwise, there is no info
that they are free, no license, no canonical name etc. In any case
shipping some random fonts in the source package is troublesome.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#824962: graphite-web: Not work with django 1.9, upgrade to master branch ?

[Javier Barroso]

Package: graphite-web
Version: 0.9.15+debian-1
Severity: important

Dear Maintainer,

After installing on sid, not graph is showed, when you pick on the icon:

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 149, in get_response
response = self.process_exception_by_middleware(e, request)
  File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py",
line 147, in get_response
response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/usr/lib/python2.7/dist-packages/graphite/render/views.py",
line 56, in renderView
(graphOptions, requestOptions) = parseOptions(request)
  File "/usr/lib/python2.7/dist-packages/graphite/render/views.py",
line 236, in parseOptions
queryParams = request.REQUEST
AttributeError: 'WSGIRequest' object has no attribute 'REQUEST'

Researching on internet, it was fixed on master[1], I'm not sure if a
cherry pick or a merge should be enough


[1] https://github.com/graphite-project/graphite-web/pull/1471
-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages graphite-web depends on:
ii  adduser3.114
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  python-cairo   1.8.8-2
ii  python-django  1.9.6-1
ii  python-django-tagging  1:0.4.1-1
ii  python-pyparsing   2.1.4+dfsg1-1
ii  python-simplejson  3.8.2-2
ii  python-tz  2015.7+dfsg-0.1
ii  python-whisper 0.9.15-1
pn  python:any 

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
ii  graphite-carbon  0.9.15-1
ii  libapache2-mod-wsgi  4.3.0-1.1+b1
pn  python-ldap  
pn  python-memcache  
pn  python-mysqldb   

-- Configuration Files:
/etc/graphite/local_settings.py changed [not included]

-- debconf-show failed

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Cyril Brulebois]

Hi,

Martin Michlmayr <t...@cyrius.com> (2016-05-21):
> * Christian Perrier <bubu...@debian.org> [2016-05-18 07:25]:
> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environmentsbecause, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment.  So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> FWIW, I fully agree.  I'm not happy to see the new desktop selection
> in tasksel, even though I can understand why some people want to see
> this.  In my opinion, adding Blends is definitely taking things too
> far.  Most users will have no clue what it's about, even if we add an
> explanation of what a "blend" is.

OK; so that's not just me.

> We've worked hard for years to improve the installation experience and I
> fear the new tasksel selection will add a lot of confusion for users.

For now, I've added a mention about the new (possibly temporary)
behaviour regarding tasksel:
  https://www.debian.org/devel/debian-installer/News/2016/20160521


Now that I'm almost done with releasing D-I Stretch Alph 6, I've looked
at how we got there. It seems blends-tasks is Priority: important, and
that's how it got into the installed system.

Then looking at tasksel's README:
| On startup, the tasksel program will read all *.desc files in
| /usr/share/tasksel/ for information about what tasks are available. The
| tasks will be presented in a simple list selection screen with their
| short descriptions.

I'm very much not happy with tasksel's picking up whatever people have
managed to get into a basic system, and I would very much prefer if it
would only look at its own debian-tasks.desc when running from the
installer. Any objections?


Also, Steve mentioned the Debian Pure Blends addition might generate
issues depending on what blends are available and/or installable on this
or that image (adding debian-cd@ for reference).


KiBi.


signature.asc
Description: Digital signature

Bug#785115: dos2unix: New upstream version

[waterlan]

Hi,

Is there any way I can help?
I have never created a debian package before, but I'm willing to learn.

best regards,

--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Martin Michlmayr]

* Christian Perrier  [2016-05-18 07:25]:
> I still remember Joey's objections about *not* having users forced
> to choose between desktop environmentsbecause, contrary to what
> the average geek thinks, most people have no idea about what is a
> desktop environment.  So, just imagine if we present them with
> "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> strange things.

FWIW, I fully agree.  I'm not happy to see the new desktop selection
in tasksel, even though I can understand why some people want to see
this.  In my opinion, adding Blends is definitely taking things too
far.  Most users will have no clue what it's about, even if we add an
explanation of what a "blend" is.

We've worked hard for years to improve the installation experience and I
fear the new tasksel selection will add a lot of confusion for users.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#824663: qtwebkit crash with 'illegal instruction' on i586

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 pending

Thanks a lot for the patch Peter!!! I have applied it on our repo, it will be 
included in the next upload, whenever that happens.

Kinds regards, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#824960: tex-common failed to upgrade

[Rémi Vanicat]

Package: tex-common
Version: 6.05
Severity: grave
Justification: renders package unusable

When upgrading I've the following:

Paramétrage de tex-common (6.05) ...

Warning: Old configuration style found in /etc/texmf/fmt.d
Warning: For now these files have been included,
Warning: but expect inconsistencies.
Warning: These packages should be rebuild with tex-common.
Warning: Please see /usr/share/doc/tex-common/NEWS.Debian.gz
Warning: found file: /etc/texmf/fmt.d/10texlive-formats-extra.cnf

Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.8V4LVNKH
Please include this file if you report a bug.

The content of fmtutil.8V4LVNKH follow. Please ask if you need other
information.

fmtutil: fmtutil is using the following fmtutil.cnf files (in precedence order):
fmtutil:   /var/lib/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texmf/web2c/fmtutil.cnf
fmtutil:   /usr/share/texlive/texmf-dist/web2c/fmtutil.cnf
fmtutil: fmtutil is using the following fmtutil.cnf file for writing changes:
fmtutil:   /etc/texmf/web2c/fmtutil.cnf
fmtutil [INFO]: writing formats under /var/lib/texmf/web2c
fmtutil [INFO]: --- remaking luatex with luatex
fmtutil: running `luatex -ini   -jobname=luatex -progname=luatex luatex.ini' ...
This is LuaTeX, Version 0.95.0 (TeX Live 2016/Debian)  (INITEX)
 restricted system commands enabled.
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatex.ini
(/usr/share/texlive/texmf-dist/tex/generic/tex-ini-files/luatexconfig.tex
(/var/lib/texmf/tex/generic/config/pdftexconfig.tex))
(/usr/share/texlive/texmf-dist/tex/generic/config/luatexiniconfig.tex)
(/usr/share/texlive/texmf-dist/tex/generic/unicode-data/load-unicode-data.tex

load-unicode-data.tex v1.4a (2016-02-21)
Reading Unicode data
# UnicodeData-8.0.0.txt
# Downloaded 2015-12-01 09:00:00 GMT [JAW]
) (/usr/share/texlive/texmf-dist/tex/luatex/hyph-utf8/etex.src
(/usr/share/texlive/texmf-dist/tex/plain/base/plain.tex
Preloading the plain format: codes, registers, parameters, fonts, more fonts,
macros, math definitions, output routines, hyphenation
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
[skipping from \patterns to end-of-file...]))
(/usr/share/texlive/texmf-dist/tex/plain/etex/etexdefs.lib
Skipping module "grouptypes"; Loading module "interactionmodes";
Skipping module "nodetypes"; Skipping module "iftypes";)
(/var/lib/texmf/tex/generic/config/language.def
(/usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex))
Augmenting the Plain TeX definitions: \tracingall;
Adding new e-TeX definitions: \eTeX, \loggingall, \tracingnone,
register allocation; extended register allocation; 
Recycling: \addlanguage, \@nswer (not defined), \@sk, \b@dresponsetrue,
\b@dresponsefalse, \ch@ckforyn, \mayber@cycle, \et@xabort, \et@xbuf,
\et@xfmtsrc, \et@xfilehdr, \et@xinf, \et@xpatterns, \l@ngdefnfile, \n@xt,
\p@rse (not defined), \pr@mpt (not defined), \pr@mptloop (not defined),
\forcer@cycle, \usef@llback, \usef@llbacktrue, \usef@llbackfalse, 
Retaining: \et@xerr, \et@xinput, \et@xlibhdr, \et@xmsg, \et@xtoks, \et@xwarn,
\et@xl@@d, \et@xl@ad, \et@xload, \et@xlang, \et@xhash, \eTeX, \etexhdrchk,
\etexstatus, \module, \uselanguage, \r@tain, \r@cycle,))
Beginning to dump on file luatex.fmt
 (format=luatex 2016.5.21)
3133 strings using 10251 bytes
68833 memory locations dumped; current usage is 155&7729
1764 multiletter control sequences
\font\nullfont=nullfont
\font\tenrm=cmr10
\font\preloaded=cmr9
\font\preloaded=cmr8
\font\sevenrm=cmr7
\font\preloaded=cmr6
\font\fiverm=cmr5
\font\teni=cmmi10
\font\preloaded=cmmi9
\font\preloaded=cmmi8
\font\seveni=cmmi7
\font\preloaded=cmmi6
\font\fivei=cmmi5
\font\tensy=cmsy10
\font\preloaded=cmsy9
\font\preloaded=cmsy8
\font\sevensy=cmsy7
\font\preloaded=cmsy6
\font\fivesy=cmsy5
\font\tenex=cmex10
\font\preloaded=cmss10
\font\preloaded=cmssq8
\font\preloaded=cmssi10
\font\preloaded=cmssqi8
\font\tenbf=cmbx10
\font\preloaded=cmbx9
\font\preloaded=cmbx8
\font\sevenbf=cmbx7
\font\preloaded=cmbx6
\font\fivebf=cmbx5
\font\tentt=cmtt10
\font\preloaded=cmtt9
\font\preloaded=cmtt8
\font\preloaded=cmsltt10
\font\tensl=cmsl10
\font\preloaded=cmsl9
\font\preloaded=cmsl8
\font\tenit=cmti10
\font\preloaded=cmti9
\font\preloaded=cmti8
\font\preloaded=cmti7
\font\preloaded=cmu10
\font\preloaded=cmmib10
\font\preloaded=cmbsy10
\font\preloaded=cmcsc10
\font\preloaded=cmssbx10
\font\preloaded=cmdunh10
\font\preloaded=cmr7 at 14.51799pt
\font\preloaded=cmtt10 at 14.4pt
\font\preloaded=cmssbx10 at 14.4pt
\font\preloaded=manfnt
50 preloaded fonts
warning  (pdf backend): no pages of output.
Transcript written on luatex.log.
fmtutil [INFO]: /var/lib/texmf/web2c/luatex/luatex.fmt installed.
fmtutil [INFO]: --- remaking pdftex with pdftex
fmtutil: running 

Bug#824961: Will be removed from the archive with Qt 5.7 (in time for Stretch)

[Lisandro Damián Nicanor Pérez Meyer]

Source: qtquick1-opensource-src
Version: 5.5.1-2
Severity: important

This source package will get removed from the archive with Qt 5.7.

Please do not [build] depende upon it.

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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

Bug#824959: QtQuick1 removal from the archive

[Lisandro Damián Nicanor Pérez Meyer]

Source: kadu-mime-tex
Version: kadu-mime-tex
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qtquick1-removal

Hi! According to Qt's [upstream] QtQuick1 will be totally removed and
unsuported with Qt 5.7.

I'm afraid there is no way for us to keep this working.

Please suggest to your upstream to port the relevant code to QtQuick2 aka 
QtDeclarative.

[upstream] 

Thanks, Lisandro.


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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

Bug#824958: QtQuick1 removal from the archive

[Lisandro Damián Nicanor Pérez Meyer]

Source: gcompris-qt
Version: 0.50-2
Severity: normal
User: debian-qt-...@lists.debian.org
Usertags: qtquick1-removal

Hi! According to Qt's [upstream] QtQuick1 will be totally removed and
unsuported with Qt 5.7.

I'm afraid there is no way for us to keep this working.

Please suggest to your upstream to port the relevant code to QtQuick2 aka 
QtDeclarative.

[upstream] 

Thanks, Lisandro.

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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

Bug#824956: QtQuick1 will be removed from the archive with Qt 5.7

[Lisandro Damián Nicanor Pérez Meyer]

Source: musescore
Version: 2.0.2+dfsg-2
Severity: important

Hi! According to Qt's [upstream] QtQuick1 will be totally removed and
unsuported with Qt 5.7.

I'm afraid there is no way for us to keep this working.

Please suggest to your upstream to port the relevant code to QtQuick2 aka
QtDeclarative.

[upstream] 

Thanks, Lisandro.

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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

Bug#824957: QtQuick1 removal from the archive

[Lisandro Damián Nicanor Pérez Meyer]

Source: phonon
Version: 4:4.9.0-2
Severity: important
User: debian-qt-...@lists.debian.org
Usertags: qtquick1-removal

Hi! According to Qt's [upstream] QtQuick1 will be totally removed and
unsuported with Qt 5.7.

I'm afraid there is no way for us to keep this working.

Please suggest to your upstream to port the relevant code to QtQuick2 aka 
QtDeclarative.

[upstream] 

Thanks, Lisandro.

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

Kernel: Linux 4.5.0-2-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/bash
Init: systemd (via /run/systemd/system)

-- debconf information excluded

Bug#811411: Joining the adduser Alioth team

[Afif Elghraoui]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, Marc,
I sent a request to join the alioth team for Adduser and you seem to
be the only project admin still active in Debian. I'm interested in
possibly adopting the package, so I've already converted the packaging
VCS to git and would like to publish that as part of the same project.

Many thanks and regards
Afif

- -- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJXQMBOAAoJEFmyMG86+d3BzVgP/3bNXiumne+juAK8/MsBZUFQ
KZBtzqBtCbjthz2jKuBJOCoCFC3XVxnV9cPvHBHkRzp1AwpuLLoLyfl6gxSbu3n2
FhUkEB27o8Vy6KC6wRyAdSZlDCc5fUk7nBHXBUi97muHIPM4P+KnCATrftKGmPhC
Jv5qlV1JnAqUCY2klpcNKYIeF+J2q1y4ibRSFhtMVswFWvDDEyNeE4GH8Qd43yqF
QXYdm01tco7JjHLN6H3EA7O6/yKJoFmMnx0RylLoGXyEP5cqdxfLDoG4PP1uagct
yzYZ79pwF9U2ZiTcvwZhmU8QVVwIv6DMIGfT9sI5rEthq3Cfa3IIDZsVZIM2mL6/
VNJTk+ds666fCwP/KUEMeN4KedXsKvEcsyPKUCv94Pj0cDbS1Wit8wC3ndcgKRjy
aGMGkmuPllkP82V5RFAXXAY5TZ6XzjHEPlFHSNKXIEXCMUbVQD+WGm3uBmzWKjrI
lAAn0obVdBAJyg0AHM+Qgf7hyU+asQZ36+VCJMqSjlXEL231b+c5eOCADCJNKzxU
Roy+Jn6AYucVI8kn5G1aQlpwjnpJC3om0SPRFuhk5lR8RLbCc1k170J7mtjbfaCV
5y0ixZkStSJfvOON3b+YHnc0QLdWgNQv+NkKPspj7sne50KrbHKlGmWgpH/hdzEt
3x6jh6JrEYRJK3K4pZy7
=/6Q1
-END PGP SIGNATURE-

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Sat, May 21 2016, Laurent Bigonville  wrote:
> Le 21/05/16 à 21:53, Yuri D'Elia a écrit :
>> Sorry for the delay, but I wanted to actually give it a try before
>> giving feedback.
>>
>> Indeed, that obviously fixes the problem.
>>
>> So is this actually a patch local to debian now?
> Thanks for the feedback.
>
> Yes, I cherry-picked the patch from upstream to have it immediately in
> debian, it's in unstable for a few days now.

I noticed right after your reply, but couldn't get to it right away.
Thanks a lot for this.

I do believe this is the _right_ approach.

Bug#824884: netbase: should not recommend ifupdown

[Guus Sliepen]

On Fri, May 20, 2016 at 09:08:29PM +0200, Marco d'Itri wrote:

> Does anybody see a reason to NOT remove the recommends?

I don't see a reason either.

About the description of the netbase package though: it currently only
contains for text files in /etc that are seldomly used. For fun I just
purged netbase, and it doesn't really break anything. I wouldn't call it
"necessary infrastucture for basic TCP/IP networking" anymore.

The netbase package has a lot of reverse depends that are also not
necessary anymore, I think.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Bug#823184: umount mounts /proc as a side effect

[Laurent Bigonville]

Le 21/05/16 à 21:53, Yuri D'Elia a écrit :

On Fri, May 13 2016, Laurent Bigonville  wrote:

Can you please try the patch that has been attached to the bug and tell
me if it's fixing your issue?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823184#44

Sorry for the delay, but I wanted to actually give it a try before
giving feedback.

Indeed, that obviously fixes the problem.

So is this actually a patch local to debian now?

Thanks for the feedback.

Yes, I cherry-picked the patch from upstream to have it immediately in 
debian, it's in unstable for a few days now.

Bug#776778: #777228 done

[Thomas Hood]

> I wrote:
>> We can file a new bug report requesting that unbound include the file in
question.
>
> I have filed bug report #777228.

As of version 1.5.7-2 the unbound package includes the file in question;
#777228 has been closed.

-- 
Thomas

Bug#823184: umount mounts /proc as a side effect

[Yuri D'Elia]

On Fri, May 13 2016, Laurent Bigonville  wrote:
> Can you please try the patch that has been attached to the bug and tell
> me if it's fixing your issue?
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823184#44

Sorry for the delay, but I wanted to actually give it a try before
giving feedback.

Indeed, that obviously fixes the problem.

So is this actually a patch local to debian now?

Bug#824955: u-boot: please enable support for dragonboard410c

[Ricardo Salveti]

Source: u-boot
Version: 2016.05+dfsg1-1
Severity: wishlist

u-boot 2016.05 already includes support for Dragonboard410c (96boards
CE compatible), just missing packaging support. Please see the
attached patch for the required changes to make it supported.

The patch also includes a packaging patch that fixes the distro
bootcmd support, and also some minor fixes for extlinux and pxeboot
support (which I'm also forwarding upstream).

Thanks,
-- 
Ricardo Salveti de Araujo
From 09d3518d957d8479c821f14ad3b4cfdfa87a43de Mon Sep 17 00:00:00 2001
From: Ricardo Salveti 
Date: Thu, 19 May 2016 18:55:42 -0300
Subject: [PATCH] Enable support for dragonboard410c

Signed-off-by: Ricardo Salveti 
---
 debian/control |  2 +-
 ...oard410c-make-a-functional-distro-bootcmd.patch | 47 ++
 debian/patches/series  |  2 +
 debian/targets |  3 ++
 debian/u-boot.lintian-overrides|  2 +
 5 files changed, 55 insertions(+), 1 deletion(-)
 create mode 100644 debian/patches/dragonboard410c-make-a-functional-distro-bootcmd.patch

diff --git a/debian/control b/debian/control
index 6da1a69..68b4d3b 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Vcs-Git: https://anonscm.debian.org/git/collab-maint/u-boot.git
 Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/u-boot.git/
 
 Package: u-boot
-Architecture: armel armhf avr32 mips sh4
+Architecture: armel armhf arm64 avr32 mips sh4
 Multi-Arch: same
 Depends: ${misc:Depends},
  u-boot-imx [armhf], u-boot-omap [armhf], u-boot-sunxi [armhf], u-boot-exynos [armhf]
diff --git a/debian/patches/dragonboard410c-make-a-functional-distro-bootcmd.patch b/debian/patches/dragonboard410c-make-a-functional-distro-bootcmd.patch
new file mode 100644
index 000..fd6ae1e
--- /dev/null
+++ b/debian/patches/dragonboard410c-make-a-functional-distro-bootcmd.patch
@@ -0,0 +1,47 @@
+From: Ricardo Salveti 
+Date: Thu, 19 May 2016 23:32:44 -0300
+Subject: [PATCH] dragonboard410c: make a functional distro bootcmd
+
+- Increase default env size (too big)
+- Increase SDCard boot priority (over eMMC)
+- Fixing eMMC rootfs partition id (fixed partition table)
+- Adding missing default addr for script and pxe boot
+
+Signed-off-by: Ricardo Salveti 
+---
+ include/configs/dragonboard410c.h | 9 ++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+diff --git a/include/configs/dragonboard410c.h b/include/configs/dragonboard410c.h
+index d32889d..d584c3d 100644
+--- a/include/configs/dragonboard410c.h
 b/include/configs/dragonboard410c.h
+@@ -84,8 +84,8 @@
+ 
+ #define BOOT_TARGET_DEVICES(func) \
+ 	func(USB, usb, 0) \
+-	func(MMC, mmc, 0) \
+ 	func(MMC, mmc, 1) \
++	func(MMC, mmc, 0) \
+ 	func(DHCP, dhcp, na)
+ 
+ #include 
+@@ -126,10 +126,13 @@ REFLASH(dragonboard/u-boot.img, 8)\
+ 	"fdtfile=apq8016-sbc.dtb\0" \
+ 	"fdt_addr_r=0x8300\0"\
+ 	"ramdisk_addr_r=0x8400\0"\
+-	BOOTENV
++	"scriptaddr=0x9000\0"\
++	"pxefile_addr_r=0x9100\0"\
++	BOOTENV \
++	"bootcmd_mmc0=setenv devnum 0; setenv distro_bootpart a; run mmc_boot\0"
+ 
+ #define CONFIG_ENV_IS_NOWHERE
+-#define CONFIG_ENV_SIZE			0x1000
++#define CONFIG_ENV_SIZE			0x2000
+ #define CONFIG_ENV_VARS_UBOOT_CONFIG
+ #define CONFIG_SYS_NO_FLASH
+ 
+-- 
+2.7.4
+
diff --git a/debian/patches/series b/debian/patches/series
index 28f3f85..23ea2fa 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -27,3 +27,5 @@ mx6cuboxi/serial_console_speed.patch
 am57xx/omap5_distro_bootcmd
 
 imx_private_libgcc
+
+dragonboard410c-make-a-functional-distro-bootcmd.patch
diff --git a/debian/targets b/debian/targets
index a76c205..4256ba4 100644
--- a/debian/targets
+++ b/debian/targets
@@ -154,3 +154,6 @@ mips	-		qemu_mips	u-boot.bin
 sh4	-		r2dplus		u-boot.bin
 
 sh4	-		sh7785lcr_32bit	u-boot.bin
+
+# Ricardo Salveti 
+arm64	-		dragonboard410c	u-boot.bin
diff --git a/debian/u-boot.lintian-overrides b/debian/u-boot.lintian-overrides
index f8612e0..a0c4990 100644
--- a/debian/u-boot.lintian-overrides
+++ b/debian/u-boot.lintian-overrides
@@ -10,6 +10,7 @@ u-boot [armel]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boo
 u-boot [armel]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/openrd_client/uboot.elf
 u-boot [armel]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/openrd_ultimate/uboot.elf
 u-boot [armel]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/sheevaplug/uboot.elf
+u-boot [arm64]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/dragonboard410c/uboot.elf
 u-boot [avr32]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/hammerhead/uboot.elf
 u-boot [mips]: arch-dependent-file-not-in-arch-specific-directory usr/lib/u-boot/qemu_mips/uboot.elf
 u-boot [sh4]: 

Bug#824954: flash-kernel: please provide a way to integrate with GRUB

[Steinar H. Gunderson]

Package: flash-kernel
Version: 3.66
Severity: wishlist

Hi,

I have an ODROID XU4 (a SBC based on Exynos5422). Since I'm one of those
PC people that would like everything to work like my PC does, I use GRUB
on it (plus, it gives me a nice boot menu when I can choose older kernels
or rescue mode, which is great when you're trying new and different things).

However, there's one thing GRUB doesn't know how to, and that is how to
find the right device tree file and put it in /boot. flash-kernel knows
(by virtue of having its database), but if I install flash-kernel, the first
thing it does is to make a boot.scr, which has higher priority than my GRUB
install (which is in /boot/EFI, lowest in the list of places U-Boot is looking
during boot), essentially overwriting it.

It would be really nice with some way of integrating this. As some sort
of minimal interaction, having some way of installing flash-kernel without
actually flashing (just having the kernel hooks copy the DTB into /boot)
would probably be the easiest; perhaps split into a separate package?

The more advanced integration would probably be if flash-kernel somehow
could flash GRUB (ie., running grub-install and then having its own
boot.scr boot GRUB instead of the kernels), but this sounds like it would
involve policy issues.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: armhf (armv7l)

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

Bug#824951: libtomcrypt: please make the build reproducible

[Reiner Herrmann]

Sorry, I forgot about timezone variation.
An updated patch is attached.

Regards,
  Reiner
diff --git a/debian/patches/deterministic-latex.patch b/debian/patches/deterministic-latex.patch
index f9cbb05..b9d426c 100644
--- a/debian/patches/deterministic-latex.patch
+++ b/debian/patches/deterministic-latex.patch
@@ -16,7 +16,7 @@ Index: libtomcrypt/makefile
  	rm -f doc/crypt.pdf $(LEFTOVERS)
 +	cp crypt.tex crypt.bak
 +	touch --reference=crypt.tex crypt.bak
-+	(echo "\\def\\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -d @$$(stat --format=%Y crypt.tex) | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > crypt-deterministic.tex
++	(echo "\\def\\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -u -d @$${SOURCE_DATE_EPOCH:-$$(stat --format=%Y crypt.tex)} | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > crypt-deterministic.tex
 +	echo "\\pdfinfo{" >> crypt-deterministic.tex
 +	echo "/CreationDate (\fixedpdfdate)" >> crypt-deterministic.tex
 +	echo "/ModDate (\fixedpdfdate) }" >> crypt-deterministic.tex


signature.asc
Description: PGP signature

Bug#824953: Bug lists show 'pending' for all entries

[Andrey Rahmatullin]

Package: reportbug
Version: 6.6.6
Severity: normal

At least in the GTK interface all bug entries in querybts and reportbug show
'pending' in the tag column.



-- Package-specific info:
** Environment settings:
EDITOR="vim"
DEBEMAIL="w...@debian.org"
DEBFULLNAME="Andrey Rahmatullin"
INTERFACE="gtk2"

** /home/wrar/.reportbugrc:
reportbug_version "4.12.6"
mode expert
ui gtk2
realname "Andrey Rahmatullin"
email "w...@debian.org"

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

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

Versions of packages reportbug depends on:
ii  apt   1.2.12
ii  python-reportbug  6.6.6
pn  python:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail   
ii  debconf-utils1.5.59
ii  debsums  2.1.2
ii  dlocate  1.02+nmu3
pn  emacs23-bin-common | emacs24-bin-common  
ii  file 1:5.25-2
ii  gnupg1.4.20-6
ii  postfix [mail-transport-agent]   3.1.0-3
ii  python-gtk2  2.24.0-4
pn  python-gtkspellcheck 
ii  python-urwid 1.3.1-2+b1
ii  python-vte   1:0.28.2-5+b1
ii  xdg-utils1.1.1-1

Versions of packages python-reportbug depends on:
ii  apt   1.2.12
ii  file  1:5.25-2
ii  python-debian 0.1.27
ii  python-debianbts  2.6.0
pn  python:any

python-reportbug suggests no packages.

-- debconf-show failed

Bug#824884: netbase: should not recommend ifupdown

[Michael Biebl]

Am 20.05.2016 um 21:08 schrieb Marco d'Itri:
> Does anybody see a reason to NOT remove the recommends?

I seems to have been a Depends in the past and was demoted to Recommends
quite a while ago. Why it was added in the first place I can't seem to
find in the debian changelog.
Personally I don't see a compelling reason why netbase should pull in a
specific network configuration system.
So +1 for dropping the Recommends.


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#820010: [PATCH v2] libkmod: Add support for detached module signatures

[Ben Hutchings]

On Sat, 2016-05-21 at 15:31 -0300, Lucas De Marchi wrote:
> On Wed, Apr 13, 2016 at 7:00 AM, Ben Hutchings  wrote:
> > 
> > On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote:
> > > 
> > > Hi,
> > > 
> > > CC'ing Rusty
> > > 
> > > On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings  wrote:
> > > > 
> > > > 
> > > > Debian will not sign modules during the kernel package build, as this
> > > > conflicts with the goal of reproducible builds.  Instead, we will
> > > > generate detached signatures offline and include them in a second
> > > > package.
> > > Is this a decision already? It doesn't look as a good reason - you
> > > would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
> > > anyway for this to work. How is leaving the module signature in
> > > another package be any better than just signing the module?  If you
> > > have the signature, the build is just as reproducible as before.
> > I think we may have different ideas about what reproducibility means.
> > When I say reproducible I mean *anyone* with the right tools installed
> > can reproduce the binary packages (.deb) from the source package (.dsc
> > and tarballs).
> > 
> > The signing key obviously isn't available to everyone, so the source
> > package has to include detached signatures prepared outside of the
> And how is this signature prepared?  Since it needs the compiled
> module it would be a matter of changing the compiler, even minor
> version, to invalidate the argument of reproducible build. It seems
> very fragile to me.

The versions of build tools have to be recorded:
https://reproducible-builds.org/docs/formal-definition/
https://wiki.debian.org/ReproducibleBuilds/BuildinfoSpecification

> > package build process.  But we can't put them in the linux source
> > package, because that results in a dependency loop.
> > 
> > > 
> > > > 
> > > > 
> > > > We could attach the signatures when building this second package or at
> > > > installation time, but that leads to duplication of all modules,
> > > > either in the archive or on users' systems.
> > > > 
> > > > To avoid this, add support to libkmod for concatenating modules with
> > > > detached signatures (files with the '.sig' extension) at load time.
> > > this has the drawback that finit_module() can't be used.
> > So does module compression, but it's still a supported option.
> This is easily fixed by teaching the kernel to handle the fd as a
> compressed file.

This sounds speculative.

> The kernel already has the routines to uncompress
> them anyway. Supporting detached signatures means it can't be fixed
> anymore since we will have to use init_module() rather than
> finit_module().

Why does that matter?  init_module() isn't deprecated.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes instead of old ones.

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

Bug#803096: python-bcrypt: please update python-bcrypt

[Daniel Stender]

On Sat, 21 May 2016 16:47:34 +0200 Vincent Bernat  wrote:
>  ❦ 21 mai 2016 16:32 +0200, Vincent Bernat  :
> 
> >> I have a similar need for Django 1.9 whose test suite currently fails due
> >> to this...
> >>
> >> Except that the package currently tracks py-bcrypt:
> >> https://pypi.python.org/pypi/py-bcrypt
> >>
> >> And the version that seem to be most popular is this one which is
> >> backwards compatible with py-bcrypt:
> >> https://pypi.python.org/pypi/bcrypt
> >
> > It is not compatible. py-bcrypt was providing a kdf() function to get
> > random bytes using a password and a salt. It would have been nice to
> > check reverse dependencies. It's not like they were many of them... I
> > suppose I can reupload the previous one as python-pybcrypt.
> 
> In fact, I can't since they share the same namespace... I have asked if
> it would be possible for the new module to implement such a function,
> but I won't hold my breath:
> 
>  https://github.com/pyca/bcrypt/issues/65
> -- 
> It has long been an axiom of mine that the little things are infinitely
> the most important.
>   -- Sir Arthur Conan Doyle, "A Case of Identity"

New bug on this: #824952

-- 
4096R/DF5182C8
http://www.danielstender.com/blog/

Bug#824931: openbsd-inetd: systemctl stop inetd kills all children of inetdx

[Marco d'Itri]

On May 21, Marc Lehmann  wrote:

> The semantic that debian used before and is used by similar programs (such
> as sshd) is obviously the right one - killing everything that was ever
> started directly or indirectly from inetd is obviously wrong?
I am not sure: if I stop inetd then I want to stop all running daemons, 
not just prevent new connections.

> > Can you better describe your setup? Which kind of shells were you 
> > spawning from inetd?
> Anything gets killed, not just shells - I can start a screen session with
> e.g. "nohup gzip" inside, log out, and systemctl stop inetd
> kills screen, the shell inside, gzip etc.
Yes, this is the whole point of KillMode=control-group.
But how do you start from inetd and then get a shell? Are you starting 
sshd from inetd?
It looks like your setup is a bit unusual, since nobody has noticed this 
since before jessie was released.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#824952: python-bcrypt: pyca/bcrypt not fully compatible with py-bcrypt (lacks kdf)

[Daniel Stender]

Package: python-bcrypt
Version: 2.0.0-1
Severity: important

Like Vincent recently reported on #803096 (python-bcrypt: please update
python-bcrypt, closed) github.com/pyca/bcrypt is not fully downward
compatible with google.com/py-bcrypt[*], which has been packaged before.

[*] https://pypi.python.org/pypi/py-bcrypt/0.4

The new implementation lacks kdf() [key derivation function to transform a
password ans salt into bytes suitable for use a cryptographic key material].

Among the reverse deps, python-asyncssh breaks on this:

ERROR: test_key (tests.test_public_key.TestRSA) [Export OpenSSH private 
(aes256-...@openssh.com)] (keytype=2048)
Check key import and export
--
Traceback (most recent call last):
  File "/<>/tests/test_public_key.py", line 853, in 
check_openssh_private
self.export_openssh_private(cipher)
  File "/<>/tests/test_public_key.py", line 313, in 
export_openssh_private
select_passphrase(cipher), cipher)
  File "/<>/asyncssh/public_key.py", line 352, in write_private_key
f.write(self.export_private_key(*args, **kwargs))
  File "/<>/asyncssh/public_key.py", line 254, in 
export_private_key
key = bcrypt.kdf(passphrase, salt, key_size + iv_size, rounds)
AttributeError: module 'bcrypt' has no attribute 'kdf'

--
Ran 42 tests in 33.277s

FAILED (errors=186, skipped=1)
E: pybuild pybuild:274: test: plugin distutils failed with: exit code=1: 
python3.5 setup.py test 
dh_auto_test: pybuild --test -i python{version} -p 3.5 --dir . returned exit 
code 13
debian/rules:7: recipe for target 'build' failed
make: *** [build] Error 25
dpkg-buildpackage: error: debian/rules build gave error exit status 2


It have been asked upstream if they could reimplement this[*].

[*] https://github.com/pyca/bcrypt/issues/65

DS

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

Kernel: Linux 4.5.0-2-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 python-bcrypt depends on:
ii  libc6 2.22-7
ii  python2.7.11-1
pn  python-cffi-backend-api-9729  
ii  python-six1.10.0-3
pn  python:any

python-bcrypt recommends no packages.

python-bcrypt suggests no packages.

-- no debconf information

Bug#824951: libtomcrypt: please make the build reproducible

[Reiner Herrmann]

Source: libtomcrypt
Version: 1.17-7
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi!

While working on the "reproducible builds" effort [1], we have noticed
that libtomcrypt could not be built reproducibly.
Because of #734109, a patch has been added to fix the reproducibility
of crypt.pdf. It enforces timestamps based on the modification date of
crypt.tex. But because of a newer patch from 2015 (fix-latex-here.patch),
the modification time is changed on each build process, so the pdf file
became unreproducible.

There are now two possible solutions:
- drop the original patch (deterministic-latex.patch), as texlive
  supports SOURCE_DATE_EPOCH since last week, so the pdf would be
  reproducible without the patch.
  Though I saw that the patch has already been applied upstream,
  so alternatively:
- amend the patch to favor SOURCE_DATE_EPOCH over stat, if it is set.
  This is done by the attached patch.

Regards,
 Reiner

[1]: https://wiki.debian.org/ReproducibleBuilds
diff --git a/debian/patches/deterministic-latex.patch b/debian/patches/deterministic-latex.patch
index f9cbb05..b9d426c 100644
--- a/debian/patches/deterministic-latex.patch
+++ b/debian/patches/deterministic-latex.patch
@@ -16,7 +16,7 @@ Index: libtomcrypt/makefile
  	rm -f doc/crypt.pdf $(LEFTOVERS)
 +	cp crypt.tex crypt.bak
 +	touch --reference=crypt.tex crypt.bak
-+	(echo "\\def\\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -d @$$(stat --format=%Y crypt.tex) | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > crypt-deterministic.tex
++	(echo "\\def\\fixedpdfdate{"; date +'D:%Y%m%d%H%M%S%:z' -d @$${SOURCE_DATE_EPOCH:-$$(stat --format=%Y crypt.tex)} | sed "s/:\([0-9][0-9]\)$$/'\1'}/g") > crypt-deterministic.tex
 +	echo "\\pdfinfo{" >> crypt-deterministic.tex
 +	echo "/CreationDate (\fixedpdfdate)" >> crypt-deterministic.tex
 +	echo "/ModDate (\fixedpdfdate) }" >> crypt-deterministic.tex


signature.asc
Description: PGP signature

Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures

[Marco d'Itri]

On May 21, Lucas De Marchi  wrote:

> And how is this signature prepared?  Since it needs the compiled
> module it would be a matter of changing the compiler, even minor
> version, to invalidate the argument of reproducible build. It seems
> very fragile to me.
But this is the whole point of reproducible builds: knowing that if you 
start from the same sources and build enviroment, and distributions do, 
then you will get the same results.
Building gcc is reproducibile as well...
Reproducibility with a different compiler has never been a goal.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#824950: systemd: pam_systemd should not use loginuid (at least not when used by su)

[Michael Biebl]

Control: reassign -1 libpam-systemd
Control: forcemerge -1 732209

Am 21.05.2016 um 20:17 schrieb Alex:
> Package: systemd
> Version: 215-17+deb8u4
> Severity: important
> 
> Dear Maintainer,
> 
> Systemd is causing a full freeze DE MATE Debian (using 100% CPU and memory
> leak). This problem is very old and still not fixed. This also applies to
> Systemd versions stretch: 229-5 and unstable: 229-6
> 
> strace -f $(pidof mate-settings-daemon
> 6240 open("/run/user/1000/dconf/user", O_RDWR|O_CREAT, 0600) = -1 EACCES
> (Permission denied)
> 
> Now even Linux Mint' maintainers tired of this problem and fix it themselves.
> They make a hotfix package systemd: https://github.com/linuxmint/systemd-
> rosa/commit/50d0f45f22494e004b927060bc0fc2d32136dee6
> 
> In Debian it looks like this problem will exist forever. Maybe you want that
> users switch to LinuxMint?

This has nothing to do with loginuid.
In any case this is just another duplicate so merging with existing one(s).
In the end, this should be fixed in su/sudo (which need to clear their
environment), not worked around in libpam-systemd. The patch you pointed
at is not a proper fix.

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#824752: gridengine-client, qtile: error when trying to install together

[Afif Elghraoui]

Control: notfound -1 gridengine/8.1.8+dfsg-5
Control: reassign -1 qtile

على الجمعـة 20 أيار 2016 ‫01:49، كتب Iain R. Learmonth:
> 
> Seems perfectly reasonable to me. Will rename qsh tonight.
> 
> Thanks for the speedy information. (:
> 

Many thanks!
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#820010: [PATCH v2] libkmod: Add support for detached module signatures

[Lucas De Marchi]

On Wed, Apr 13, 2016 at 7:00 AM, Ben Hutchings  wrote:
> On Wed, 2016-04-13 at 01:05 -0300, Lucas De Marchi wrote:
>> Hi,
>>
>> CC'ing Rusty
>>
>> On Mon, Apr 4, 2016 at 9:32 PM, Ben Hutchings  wrote:
>> >
>> > Debian will not sign modules during the kernel package build, as this
>> > conflicts with the goal of reproducible builds.  Instead, we will
>> > generate detached signatures offline and include them in a second
>> > package.
>> Is this a decision already? It doesn't look as a good reason - you
>> would already need to provide a signing key (CONFIG_MODULE_SIG_KEY)
>> anyway for this to work. How is leaving the module signature in
>> another package be any better than just signing the module?  If you
>> have the signature, the build is just as reproducible as before.
>
> I think we may have different ideas about what reproducibility means.
> When I say reproducible I mean *anyone* with the right tools installed
> can reproduce the binary packages (.deb) from the source package (.dsc
> and tarballs).
>
> The signing key obviously isn't available to everyone, so the source
> package has to include detached signatures prepared outside of the

And how is this signature prepared?  Since it needs the compiled
module it would be a matter of changing the compiler, even minor
version, to invalidate the argument of reproducible build. It seems
very fragile to me.

> package build process.  But we can't put them in the linux source
> package, because that results in a dependency loop.
>
>> >
>> > We could attach the signatures when building this second package or at
>> > installation time, but that leads to duplication of all modules,
>> > either in the archive or on users' systems.
>> >
>> > To avoid this, add support to libkmod for concatenating modules with
>> > detached signatures (files with the '.sig' extension) at load time.
>> this has the drawback that finit_module() can't be used.
>
> So does module compression, but it's still a supported option.

This is easily fixed by teaching the kernel to handle the fd as a
compressed file. The kernel already has the routines to uncompress
them anyway. Supporting detached signatures means it can't be fixed
anymore since we will have to use init_module() rather than
finit_module().


Lucas De Marchi

Bug#818873: gcc-5-cross: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Santiago Vila]

Thanks a lot, Andreas, for looking at this!

Would you take a look at this one?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=818872

It's apparently the "same" bug, so most likely the fix for #818873
would also work for #818872 as well.

Thanks.

Bug#824928: letsencrypt.sh: move the default position of the domains file to /etc/letsencrypt.sh/

[Mattia Rizzolo]

On Sat, May 21, 2016 at 07:14:05PM +0200, Daniel Beyer wrote:
> Hi Mattia,
> 
> On Sat, 2016-05-21 at 15:58 +0200, Daniel Beyer wrote:
> > (...)
> >
> > It looks like ${DOMAINS_TXT} can not be set or overridden in config.sh.
> > But it should be rather easy to add this feature to letsencrypt.sh. I'll
> > work on a patch and propose it upstream. In past upstream was very nice
> > with accepting improvements to letsencrypt.sh. I'll let you know about
> > the progress of this.
> 
> I opened a PR for upstream [1], based on the initial work you gave me.
> It might take a bit till upstream reacts to it, but I think chances are
> good it will be accepted.
> [1] https://github.com/lukas2511/letsencrypt.sh/pull/204

Great thanks!

> I started working on updating our packaging in a new branch
> wip/dabe/domains.txt-in-etc. But I have the feeling, that mentioning the
> change in d/NEWS is not enough.

I'd also keep in mind that this package is very young while considering
this.

> So i came up with the following idea (not implemented, yet):
> During upgrade we check if a /var/lib/letsencrypt.sh/domains.txt exists
> and if so add an extra config file in /etc/letsencrypt.sh/conf.d/ to
> automatically reconfigure letsencrypt.sh back to the old location. With
> this we would not break things for our existing users.
> Do you have an other idea or opinion how to deal with this?

That's a nice idea, even if I usually try to avoid having to deal with
maintainer scripts.
Anyway doing this also requires:
* checking that /etc/letsencrypt.sh/config.sh actually has DOMAINS_TXT
  set to the new location (if the user modified it, dpkg won't overwrite
  it with our new copy with our new conf)
* also adding a prerm to remove that file in case of purge


Also, I'd like to not keep that thing forever, e.g. drop this
transitional measure before stretch: I'm usually happier if my packages
don't have maintainer scripts.

> An other question is whether or not we should start shipping
> a /etc/letsencrypt.sh/domains.txt. I would prefer to do that, with a
> small header (lines containing '#' are ignored) outlining the purpose
> and the format of this domains.txt file. What do you think?

Yes :)
Also notice the relative file in the new docs/ directory in the upstream
repo (I'd like to ship all that documentation when a new release will
happen).


In the meantime, I'm going to build from your branch, change some things
in my infra, and test it out.

-- 
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#802924: fmit: No sound is captured, l10n errors

[Evangelos Skarmoutsos]

Package: fmit
Version: 1.0.0-1
Followup-For: Bug #802924

Dear Maintainer,

This bug is probably corrected upstream
https://github.com/gillesdegottex/fmit/issues/34
Since it is an important bug, a newer package should be provided.


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

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

Versions of packages fmit depends on:
ii  freeglut3 2.8.1-2
ii  libasound21.1.0-1
ii  libc6 2.22-7
ii  libfftw3-double3  3.3.4-2+b1
ii  libgcc1   1:6.1.1-3
ii  libgl1-mesa-glx [libgl1]  11.2.2-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-1
ii  libqt4-opengl 4:4.8.7+dfsg-6+b1
ii  libqtcore44:4.8.7+dfsg-6+b1
ii  libqtgui4 4:4.8.7+dfsg-6+b1
ii  libstdc++66.1.1-3

fmit recommends no packages.

fmit suggests no packages.

Bug#824901: [pkg-gnupg-maint] Bug#824901: gnupg: gpg segfaults

[Christoph Egger]

Hi!

Werner Koch  writes:
> however, we don't have debug symbols for Libgcrypt.  I'd suggest to try
> this patch for debugging:

Actually unstable-debug has. Anyway (can give full log if that's needed
as well

> diff --git a/g10/seskey.c b/g10/seskey.c
> index c41a145..d0e6b6f 100644
> --- a/g10/seskey.c
> +++ b/g10/seskey.c
> @@ -347,6 +347,9 @@ encode_md_value (PKT_public_key *pk, gcry_md_hd_t md, int 
> hash_algo)
>  return NULL;
>if ( gcry_md_algo_info (hash_algo, GCRYCTL_GET_ASNOID, asn, ) )
>  BUG();
> +  log_debug ("%s: hash_algo=%d pk=%p\n", __func__, hash_algo, pk);
> +  log_debug ("%s: pk->pkey[0]=%p\n", __func__, pk->pkey[0]);
> +  gcry_log_debugmpi ("pkey[0]", pk->pkey[0]);
>frame = do_encode_md (md, hash_algo, gcry_md_get_algo_dlen (hash_algo),
>  gcry_mpi_get_nbits (pk->pkey[0]), asn, asnlen);
>xfree (asn);

% gdb --args gpg --debug-all --list-sigs 0x3B78A32D98BAD5B0
[...]
gpg: DBG: keydb_search   0: LONG_KID: '28AD32B218CCB8FE'
gpg: DBG: keydb: kid_not_found_p (28ad32b218ccb8fe) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '28AD32B218CCB8FE'
gpg: DBG: keydb: kid_not_found_p (28ad32b218ccb8fe) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '0C70557B5A06513E'
gpg: DBG: keydb: kid_not_found_p (0c70557b5a06513e) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '0C70557B5A06513E'
gpg: DBG: keydb: kid_not_found_p (0c70557b5a06513e) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '0C70557B5A06513E'
gpg: DBG: keydb: kid_not_found_p (0c70557b5a06513e) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '104B1AF0BFFB'
gpg: DBG: keydb: kid_not_found_p (104b1af0bffb) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '104B1AF0BFFB'
gpg: DBG: keydb: kid_not_found_p (104b1af0bffb) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '104B1AF0BFFB'
gpg: DBG: keydb: kid_not_found_p (104b1af0bffb) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '3966A24BEC4D79E7'
gpg: DBG: keydb: kid_not_found_p (3966a24bec4d79e7) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '957952D7CF3401A9'
gpg: DBG: keydb: kid_not_found_p (957952d7cf3401a9) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '957952D7CF3401A9'
gpg: DBG: keydb: kid_not_found_p (957952d7cf3401a9) => not in DB
gpg: DBG: [not enabled in the source] keydb_search leave (not found, cached)
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: LONG_KID: '957952D7CF3401A9'
gpg: DBG: keydb: kid_not_found_p (957952d7cf3401a9) => not in DB
gpg: DBG: [not 

Bug#824949: RFS: twinkle/1:1.9.0+git20160321.0.64a0816+dfsg-2 [RC] -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for the package "twinkle":

  git clone https://anonscm.debian.org/git/pkg-voip/twinkle.git
  cd twinkle && pristine-tar checkout 
../twinkle_1.9.0+git20160321.0.64a0816+dfsg.orig.tar.xz

For verification, these are the current branch heads:

  git show-ref --heads
  9dfe396a7f36751aa2cea8e4c7782e8d304ed5a8 refs/heads/master
  961140e91690333a33b3dd0e7ef5ad1333195f6a refs/heads/pristine-tar
  8916774a5c74898e4bcc5f4f9c9b0e3cd5fd4d5e refs/heads/upstream

It builds these binary packages:

  twinkle - Voice over Internet Protocol (VoIP) SIP Phone

Changes since the last upload:

twinkle (1:1.9.0+git20160321.0.64a0816+dfsg-2) unstable; urgency=high

  * Depend on qml-module-qtquick2 (Closes: #824946).

 -- Peter Colberg   Sat, 21 May 2016 13:31:48 -0400

If you decide to sponsor this package, please upload the source only
so that buildd logs are available for all archs. I will push a release
tag to the git repository after the package has been uploaded.

Regards,
Peter

Bug#819406: RFS: capitan/1.0.3-dfsg-1 [ITP] -- Remake of the classic 80s platform game

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

The package contains embedded libs including libogg and libfreetype2 and
builds them, this must be fixed unless the built libs are not used.
Also, the package doesn't build with current libpng.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#820704: RFS: subuser/0.5.6-3 [ITP]

[Jakub Wilk]

* Andrey Rahmatullin , 2016-05-21, 21:58:

- Add --update option to dev command
- Fix /dev/dri permissions issues
- Fix encoding bug when communicating with Docker daemon
- Improve support for packaging subuser
Putting upstream changelog entries to debian/changelog is not an 
accepted practice either.


For initial release it makes of course little sense, but in general I 
don't think there's anything wrong with including summary of upstream 
changes in Debian changelog. That's what I do in my packages (when I'm 
not overly lazy...), and I know a few other developers do this too. 
Upstream stuff is often the least boring part of apt-listchanges output. 
:-)


--
Jakub Wilk

Bug#824948: Memory exaustion vulnerability in built-in web server

[Enrico Zini]

Package: python3-werkzeug
Version: 0.11.9+dfsg1-1
Severity: normal

Hello,

thank you for maintaining werkzeug.

I have reported this upstream (https://github.com/pallets/werkzeug/issues/936)
and I think it's worth having also here: the built-in web server of
werkzeug has a remotely exploitable DoS vulnerability. Since it is only
intended to be used for development, fixing it is not a high priority.

Hopefully there is no code in Debian that exposes a Werkzeug built-in
server to the internet by default:

$ apt-cache rdepends python-werkzeug
python-werkzeug
Reverse Depends:
  python-werkzeug-doc
  python-django-extensions
  tilestache
  tilelite
  python-werkzeug-doc
  python-httpbin
  python-pytest-localserver
  python-moinmoin
  klaus
  python-flask
  python-flaskext.wtf
  python-aodh
  python-designate
  chaussette
  python-ceilometer
$ apt-cache rdepends python3-werkzeug
python3-werkzeug
Reverse Depends:
  python3-httpbin
  python3-pytest-localserver
  python3-flask
  python3-flaskext.wtf


Enrico


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

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

Versions of packages python3-werkzeug depends on:
ii  libjs-jquery  1.12.3-1
pn  python3:any   

Versions of packages python3-werkzeug recommends:
ii  python33.5.1-3
ii  python3-openssl16.0.0-1
ii  python3-pyinotify  0.9.5-1

Versions of packages python3-werkzeug suggests:
ii  ipython3   2.4.1-1
pn  python-werkzeug-doc
ii  python3-lxml   3.6.0-1
ii  python3-pkg-resources  20.10.1-1

-- no debconf information

Bug#820647: RFS: libretro-gambatte [ITP]

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

From d/copyright, this is not distributable as it combines GPL2 and GPL3+.
But d/copyright is not correct/complete as libgambatte/libretro actually
contains files under several different licenses and not just GPL3+ (and
even files without a license which is bad too), and the only mention of
GPL3 (without +) I could find is in libgambatte/libretro/cc_resampler.h
(this still makes the whole work undistributable though).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#824947: After suspend and subsequent wake-up the contents of scaling_max_freq is disregarded

[Mark]

Package: linux-image-4.5.0-2-amd64
Version: 4.5.3-2

Before suspend and after suspend we had
# for i in `seq 0 7`; do cat 
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_min_freq; done

120
120
120
120
120
120
120
120
# for i in `seq 0 7`; do cat 
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_max_freq; done

120
120
120
120
120
120
120
120

Before suspend, we had around 120 in cpuinfo_cur_freq, but after 
suspend we have:
# for i in `seq 0 7`; do cat 
/sys/devices/system/cpu/cpu$i/cpufreq/cpuinfo_cur_freq; done

2599898
2599898
2599898
2599898
2599898
260
2599898
260

We constantly have
# for i in `seq 0 7`; do cat 
/sys/devices/system/cpu/cpu$i/cpufreq/scaling_governor; done

powersave
powersave
powersave
powersave
powersave
powersave
powersave
powersave

The cooling is noisy, so it's not just a wrong printf. Plz repair!

Bug#823467: RFS: flatbuffers/1.3.0-2 [ITP]

[Andrey Rahmatullin]

On Thu, May 05, 2016 at 11:17:27AM +1000, Jonathon Love wrote:
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> https://mentors.debian.net/debian/pool/main/f/flatbuffers/flatbuffers_1.3.0-2.dsc
This gives 404.
https://mentors.debian.net/package/flatbuffers contains 1.3.0-5 instead.
Note that you shouldn't increase the debian version for pckages that were
not uploaded to Debian.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#810018: procps-base: some additional init-d-script info in the quest...

[Andreas Henriksson]

Hello!

This information is not directly related to procps, but it is
kind of related to the reason why we'd want to introduce procps-base
as there's no big point in doing it if we can't also make sysvinit-utils
non-essential. Also we don't really have a good tracking bug so posting
here to archive the information somewhere before I forget about it

I've looked closer at the users of /lib/init/init-d-script which was
mentioned in a previous post that some packages init script unconditionally
sources. Apparently "new school" init scripts as generated by current
dh-make and as visible in /etc/init.d/skeleton is the reason for these
unconditional sourcing of the file which causes problems if we downgrade
sysvinit-utils (which ships /lib/init/init-d-script) to non-essential.

Given this style of init script is apparently the currently recommended
form, I assume we can see the number of packages using it rise over
time...
The problem should be (partially?) less problematic if the package
using "new school" init script also ships a native systemd unit
file, which should avoid the init script being executed at all...
(Though some people still manually execute init scripts even under
systemd out of old habits and this only works because systemd
ships an LSB hook that catches this and issues systemctl seamlessly.)



a) packages shipping an init script that uses /lib/init/init-d-script according 
to codesearch.d.n
b) if it's not a big practical issue, because the init script will not be used 
under systemd.

pkg has masking systemd unit file

sddmyes
coquelicot  yes
open-iscsi  yes
graphite-apiyes
apache2 no! (only partial snippet to extend 
autoconverted script)
batmand yes
netplan no! (but carries own fallback copy of 
init-d-script!)
courier-authdaemon  yes
uwsgi-emperor   no!
opendnssec-signer   yes
kxd yes
lvm2yes
waagent yes
prometheus  yes
dbabyes (also carries own fallback copy of 
init-d-script!)
prometheus-pgbouncer-exporter   yes
shairport-sync  yes
freeipmi-ipmiseld   no!
knot-resolver   yes
prometheus-mysqld-exporter  yes
hhvmyes
prometheus-pushgateway  no!
courier-mta yes
prometheus-node-exporterno!


The investigation was done using (so might very well be incomplete):

for pkg in  ; do
apt-file show $pkg | grep -e 'init.d' -e 'systemd/system'
done

TODO: Investigate what happens if executing such an init script directly
under systemd where normally systemd-installed LSB hooks would override
it and use systemctl...


Regards,
Andreas Henriksson

Bug#824900: RFS: iroffer-dinoex/3.30-1 [ITP]

[Andrey Rahmatullin]

(Note that I don't intend to sponsor this package)

d/rules:
- why -D_FORTIFY_SOURCE=1? Such things should be documented
- commented out -Wl,--as-needed looks strange, if it doesn't work/isn't
  needed you shouldn't include this line at all
- you can probably replace override_dh_auto_clean with debian/clean
- "dh_make generated override targets" sounds strange. "This is example
  for Cmake (See https://bugs.debian.org/641051 )" sounds even strange,
  especially when looking at that bug. That commented out
  dh_auto_configure is strange too, especially the -DCMAKE_LIBRARY_PATH
  part.

README.source even says "You WILL either need to modify or delete this
  file"

d/control:
- commented out Vcs-* fields should be either removed or uncommented and
  edited
- why this package not only Conflicts but Replaces iroffer? Do you know
  how will apt handle this relationship? Do you intend to do anything with
  the iroffer package itself (it's orphaned ATM)? If you want to replace
  it completely then the replacing procedure is different, see
  https://wiki.debian.org/Renaming_a_Package

d/copyright:
- it says "GPL-2" and "LGPL-2.1" in the short names but "or (at your
  option) any later version" in the texts
- using GPL for debian/ while having MIT and LGPL in the upstream source
  is discouraged and may cause problems if debian/ contains e.g. patches

d/install is empty

iroffer-dinoex.lintian-overrides:
- you shouldn't override P tags
- manpage-has-bad-whatis-entry override says "Upstream manpage" which
  doesn't sound like a valid cause to me

-- 
WBR, wRAR


signature.asc
Description: PGP signature