Bug#1072921: openbox depends on python needlessly

[Jo King]

Package: openbox
Version:  3.6.1-9+deb11u1

In deb11 and 12 (oldstable and stable) python is a 'deps'.

Python is not required by openbox and i avoid installing it. 
In debian10/buster python was 'suggests'. 

Suggested fix: package have python as a 'suggests' only (merely because an 
example pipe-menu uses it).
PS: cifs-utils also affected - python a needless dep since deb11.

Thanks, jo

Bug#1072157: gnome-shell: Log spam: g_closure_unref: assertion 'closure->ref_count > 0' failed

[Jo Drexl]

Package: gnome-shell
Version: 43.9-0+deb12u2
Severity: important

Dear Maintainer,

when switching to the overview (pressing super key or using the active
top left corner), a message is written to the syslog containing

g_closure_unref: assertion 'closure->ref_count > 0' failed

For every extension that is enabled this message seems to be logged too,
but even without an extension it is logged at least once, so with 4
enabled extensions it's 5 messages with every switch to the overview.
When being awakened from sleep/hibernation, this problem is worsening,
with more and more such messages appearing, also leading to severe lag
(multiple seconds). Re-login resets the problem, but it quickly
accumulates again. 

There is an Ubuntu bug (2045632) without solution, pointing to enabled
extensions, but my systems shows at least one message even with all of
them disabled.

I currently have no idea how to give you further information about this,
if you have any clue, I'm happy to assist hunting that bugger down.

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

Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  gir1.2-accountsservice-1.0   22.08.8-6
ii  gir1.2-adw-1 1.2.2-1
ii  gir1.2-atk-1.0   2.46.0-5
ii  gir1.2-atspi-2.0 2.46.0-5
ii  gir1.2-freedesktop   1.74.0-3
ii  gir1.2-gcr-3 3.41.1-1+b1
ii  gir1.2-gdesktopenums-3.0 43.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii  gir1.2-gdm-1.0   43.0-3
ii  gir1.2-geoclue-2.0   2.6.0-2
ii  gir1.2-glib-2.0  1.74.0-3
ii  gir1.2-gnomebluetooth-3.042.5-3
ii  gir1.2-gnomedesktop-3.0  43.2-2
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.22.0-2
ii  gir1.2-gtk-3.0   3.24.38-2~deb12u1
ii  gir1.2-gtk-4.0   4.8.3+ds-2+deb12u1
ii  gir1.2-gweather-4.0  4.2.0-2
ii  gir1.2-ibus-1.0  1.5.27-5
ii  gir1.2-mutter-11 43.8-0+deb12u1
ii  gir1.2-nm-1.01.42.4-1
ii  gir1.2-nma-1.0   1.10.6-1
ii  gir1.2-pango-1.0 1.50.12+ds-1
ii  gir1.2-polkit-1.0122-3
ii  gir1.2-rsvg-2.0  2.54.7+dfsg-1~deb12u1
ii  gir1.2-soup-3.0  3.2.2-2
ii  gir1.2-upowerglib-1.00.99.20-2
ii  gir1.2-webkit2-4.1   2.44.2-1~deb12u1
ii  gnome-backgrounds43.1-1
ii  gnome-settings-daemon43.0-4
ii  gnome-shell-common   43.9-0+deb12u2
ii  gsettings-desktop-schemas43.0-1
ii  gstreamer1.0-pipewire0.3.65-3+deb12u1
ii  libatk-bridge2.0-0   2.46.0-5
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-9+deb12u7
ii  libcairo21.16.0-7
ii  libecal-2.0-23.46.4-2
ii  libedataserver-1.2-273.46.4-2
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgirepository-1.0-11.74.0-3
ii  libgjs0g 1.74.2-1+deb12u1
ii  libgles2 1.6.0-1
ii  libglib2.0-0 2.74.6-2+deb12u2
ii  libglib2.0-bin   2.74.6-2+deb12u2
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-2043.2-2
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.38-2~deb12u1
ii  libgtk-4-1   4.8.3+ds-2+deb12u1
ii  libical3 3.0.16-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-11-0   43.8-0+deb12u1
ii  libnm0   1.42.4-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0 

Bug#1026172: mono: FTBFS on mipsel

[Jo Shields]

What hardware is in the mipsel-osuosl-* machines? Mono has a history of 
triggering hardware bugs in imperfect MIPS implementations, e.g. Loongson 2


On 12/15/22 14:57, Salvatore Bonaccorso wrote:

Source: mono
Version: 6.8.0.105+dfsg-3.2
Severity: serious
Justification: FTBFS
X-Debbugs-Cc: car...@debian.org

Hi

After uploading mono/6.8.0.105+dfsg-3.3 the package FTBFS on mipsel,
it suceeded on mipsel-osuosl-01 but the history of failures is found
at:

https://buildd.debian.org/status/logs.php?pkg=mono=6.8.0.105%2Bdfsg-3.3=mipsel

Regards,
Salvatore

Bug#1007804: amfora: AppArmor policy

[Jo Coscia]

Subject: amfora: AppArmor policy
Package: amfora
X-Debbugs-Cc: j...@jcoscia.com
Version: 1.9.2-2~bpo11+1
Severity: wishlist
Tags: patch

I would like to contribute an AppArmor policy for amfora. I asked the
folks in #apparmor about this, and they recommended going to the Debian
bug tracker.

I tested amfora with the following policy, and all features appear to
work correctly.

#include 

# vim:syntax=apparmor
# AppArmor policy for amfora

/usr/bin/amfora {
   #include 
   #include 
   #include 

   /etc/mime.types r,
   /etc/hosts r,
   /etc/resolv.conf r,
   /etc/nsswitch.conf r,
   /sys/kernel/mm/transparent_hugepage/hpage_pmd_size r,
   network tcp,

   # Allow opening/saving geminitext files; amfora only opens files with
these extensions
   /**.[gG][mM][iI] rw,
   /**.[gG][eE][mM][iI][nN][iI] rw,

   # Allow amfora to make these dirs, if they don't exist
   owner @{HOME}/.cache/ w,
   owner @{HOME}/.config/ w,
   owner @{HOME}/.local/ w,
   owner @{HOME}/.local/share/ w,

   owner @{HOME}/.cache/amfora/ rw,
   owner @{HOME}/.cache/amfora/** rw,
   owner @{HOME}/.config/amfora/ rw,
   owner @{HOME}/.config/amfora/** rw,
   owner @{HOME}/.local/share/amfora/ rw,
   owner @{HOME}/.local/share/amfora/** rw,

   owner @{HOME}/.config/user-dirs.dirs r,

   # Allows browsing/saving to a user-owned directory other than the
default Downloads directory. Supports removable media, etc. Restricting
it to only @{HOME}/Downloads/ would be more secure, but could cause
breakage.
   owner /**/ rw,

   # Allow amfora to open non-gemini URLs in other applications
   /usr/bin/xdg-open Ux,

}

Bug#979067: getting pinta updated in Debian

[Jo Shields]

“source-build” is the project within Microsoft which aims to produce “upstream 
tarballs” in a sufficiently from-source form to satisfy FOSS distributions. 
Fedora has had dotnet for a while as a result, a collaboration between the 
source-build team in Utah and a distributed set of folks at Red Hat (Fedora’s 
from-source requirements are slightly different from the DFSG, but not 
meaningfully so). Roughly speaking, source-build has to reconcile about 30 
separate dotnet repos, in order to produce an upstream-equivalent dotnet SDK.

I know that team has been engaging with someone at Canonical about Ubuntu 
packaging, I can reach out to find out who that is, and see whether that work 
could be uploaded to Debian first as a matter of course

Sent from Mail for Windows

From: Mirco Bauer
Sent: Thursday, March 3, 2022 7:57 PM
To: Mike Gabriel
Cc: debian-de...@lists.debian.org; debian-...@lists.debian.org; 
979...@bugs.debian.org
Subject: Re: getting pinta updated in Debian

Hello Mike,

thanks for your interest in getting pinta updated in Debian. The other day I 
noticed as well that pinta is outdated in Debian and it does not look like 
there is a simple way forward, unfortunately.

Pinta has moved to the dotnet runtime which is not packaged in Debian.

Many years ago I worked on getting the dotnet core runtime into Debian (just as 
I did to get Mono into Debian back then) but I hit hard problems that prevented 
it.
The dotnet runtime could not be build from source which is not compliant with 
the DFSG. Microsoft had shown interest and I have advised them on how to make 
dotnet DFSG compliant so it could be included in Debian and Ubuntu, but it was 
clear it won't happen overnight as building cleanly from source (bootstrapping 
a runtime) isn't trivial and needed a major effort on the upstream side. Later 
this effort deepened between Microsoft and Redhat to make dotnet buildable from 
source, which is great.

I am not sure if you can build dotnet from source at this point, maybe it is 
possible by now. I could never find time to follow-up on this as I started to 
work for demanding startups that leave little to no spare time. If you are 
interested to get dotnet into Debian I am still available for mentoring and 
going in the right direction, I would like to see dotnet packaged still, it is 
a fantastic software development platform. The #debian-cli IRC channel on OFTC 
is the place where the Mono and .NET friends hang out, so feel invited to join 
us.

Best regards,

Mirco Bauer

Chief InfoSec Officer   mirco.ba...@eqonex.com https://group.eqonex.com/
FOSS Hacker             mee...@meebey.net      https://www.meebey.net/
Debian Developer        mee...@debian.org      https://www.debian.org/
GNOME Foundation Member mmmba...@gnome.org     https://www.gnome.org/
.NET Foundation Advisory Council Member        https://www.dotnetfoundation.org/
PGP-Key ID              0x7127E5ABEEF946C8     https://meebey.net/pubkey.asc



On Thu, Mar 3, 2022 at 4:05 AM Mike Gabriel  
wrote:
Hi all,

I am currently looking into requirements of getting pinta in Debian  
updated to the latest upstream version.

My problem: I am not at all a .NET developer or maintainer, so this is  
a piece of work with a steep learning curve for me.

What I found now are AUR packages for pinta (and its dependency  
dotnet-runtime) that are quite up-to-date:

https://archlinux.org/packages/community/any/pinta/
https://archlinux.org/packages/community/x86_64/dotnet-core/

It basically looks like we need to get dotnet-core into Debian and  
then update pinta to latest 2.0.2 upstream release and we are done.

However, dotnet-core seems to be massive and I wonder if that can be  
avoided as its API is provided by something else in Debian. I am  
asking this possibly stupid question because I am astounded that noone  
has ever packaged dotnet-core, filed an RFP or ITP for it, etc.

Furthermore, it seems that dotnet-core has been licensed under a  
DFSG-compliant MIT license variant [1].

Do I miss anything here? Is there a hidden blocker? Or is it just that  
noone has been interested in dotnet-core (and/or a pinta version  
bump), so far / recently?

Thanks for feedback!
Mike

[1] https://github.com/dotnet/core/blob/main/LICENSE.TXT
-- 

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

Bug#995368: oldstable also affected

[Jo Valentine-Cooper]

Can confirm that mailman3 in oldstable/buster also appears affected by this
regression, and the same mitigation (removing the trailing slash from the
ProxyPass directive) works around it. (Found out while trying a fourth time
to finish procrastinating on migrating my mailman2 system to mailman3 in
prep for a procrastinated update to bullseye; the resulting stress was...
not fun. :( )

Same symptoms in the mailman3-web log:
WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//
WARNING 2021-10-17 17:01:08,583 12164 django.request Not Found: /mailman//

Since uwsgi in oldstable, so far as I can tell, hasn't been so much as
glanced at in two and a half years but Apache was security-updated within
the last week or two, that has me wondering about where the bug really
lies...

uswgi versions:
$ dpkg -l | grep uwsgi
ii  uwsgi2.0.18-1 i386
fast, self-healing application container server
ii  uwsgi-core   2.0.18-1 i386
fast, self-healing application container server (core)
ii  uwsgi-plugin-python3 2.0.18-1 i386
WSGI plugin for uWSGI (Python 3)

mailman3 versions:
$ dpkg -l | grep mailman3
ii  mailman3 3.2.1-1  all
   Mailing list management system
ii  mailman3-doc 3.2.1-1  all
   Mailing list management system documentation
ii  mailman3-full3.2.1-1  all
   Full Mailman3 mailing list management suite (metapackage)
ii  mailman3-web 0+20180916-8 all
   Django project integrating Mailman3 Postorius and HyperKitty
ii  python3-django-mailman3  1.2.0-3  all
   Django library to help interaction with Mailman3 (Python 3 version)

apache versions:
$ dpkg -l | grep apache
ii  apache2  2.4.38-3+deb10u6 i386
Apache HTTP Server
ii  apache2-bin  2.4.38-3+deb10u6 i386
Apache HTTP Server (modules and other binary files)
ii  apache2-data 2.4.38-3+deb10u6 all
   Apache HTTP Server (common files)
ii  apache2-utils2.4.38-3+deb10u6 i386
Apache HTTP Server (utility programs for web servers)

Hope this helps.
-jo


-- 
Jo Valentine-Cooper (j...@nwcs.com)
Of course, I don't know how interesting any of this really is,
but now you've got it in your brain cells so you're stuck with it.
--Gary Larson

Bug#947238:

[Jo Goossens]

We see more problems with this package, possibly/probably related error now on 
another machine:

Dec 29 00:00:01 .xxx.com keepalived[28830]: double free or corruption 
(fasttop)

And service crashed, never came back. Seems it's not very stable atm on Buster 
:/

Bug#943860: munin-plugins-core: ntp_states plugin is broken in current package release

[Jo-Jo]

Package: munin-plugins-core
Version: 2.0.49-1

Hello,

As I pointed out here[1] the ntp_states plugins accidentally doesn't
work in this release.

Upstream fixed it with this[2] commit.

Could you please ensure to have this fix in the package as soon as possible?

Thanks for the great work your doing!

Johannes

Refs:
[1] https://github.com/munin-monitoring/munin/issues/1244
[2] 
https://github.com/munin-monitoring/munin/commit/a1738b47356e7582ba96bf73a9e00b20f095611e

Bug#941032: logwatch: dovecot 2.3.x LMTP delivery not recognized by logwatch

[Jo Valentine-Cooper]

Package: logwatch
Version: 7.5.0-1
Severity: normal
Tags: patch

In Dovecot 2.3.4.1 (as shipped in buster), LMTP deliverly log lines have
subtly changed such that the Dovecot service script for logwatch no
longer recognizes them. See diff below for illustrative example and fix.

Hope this helps!
-jo


--- /usr/share/logwatch/scripts/services/dovecot2018-12-30 
04:17:30.0 -0500
+++ /etc/logwatch/scripts/services/dovecot  2019-09-23 13:12:40.938216046 
-0400
@@ -242,6 +242,11 @@
 # dovecot: lmtp(u...@domain.com): 
msgid=<0.0.b.b83.1d385668207af0...@b12.mta01.sendsmaily.info>: saved mail to 
INBOX
   $Deliver{$User}{$Mailbox}++;
 
+# LMTP-based delivery Dovecot 2.3
+} elsif ( ($User, $Mailbox) = ( $ThisLine =~ /^$dovecottag 
lmtp\((.*)\)<.*><.*>: msgid=.*: saved mail to (.*)/ ) ) {
+# dovecot: lmtp(u...@domain.com)<2844>: 
msgid=<20987363.1159.374...@wordpress.com>: saved mail to INBOX
+  $Deliver{$User}{$Mailbox}++;
+
 # LMTP-based Sieve delivery
} elsif (my ($User, $Mailbox) = ( $ThisLine =~ /^$dovecottag lmtp\((?:\d+, 
)?(.*?)\)(?:<[^>]+><[^>]+>)?: .*: sieve: msgid=.*: stored mail into mailbox 
'(.*)'/ ) ) {
   $Deliver{$User}{$Mailbox}++;



-- System Information:
Debian Release: 10.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-5-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages logwatch depends on:
ii  exim4-daemon-heavy [mail-transport-agent]  4.92-8+deb10u1
ii  perl   5.28.1-6

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.76-1
ii  libsys-cpu-perl  0.61-2+b4
ii  libsys-meminfo-perl  0.99-1+b3

logwatch suggests no packages.

-- no debconf information

Bug#934446: 回复: Bug#934446: wsjtx: debian/patches/0001-add-start-script.patch no longer used?

[wu jo]

Hi,
i wonder how to unsubscribe from this list.

发件人: Christoph Berg 
发送时间: 2019年8月13日 8:12
收件人: tony mancill ; 934...@bugs.debian.org 
<934...@bugs.debian.org>
主题: Bug#934446: wsjtx: debian/patches/0001-add-start-script.patch no longer 
used?

Re: tony mancill 2019-08-11 <20190811040218.GA22032@lark>
> I was poking around the packaging for wsjtx (because I'm thinking about
> trying my hand at some local modifications) and noticed that
> debian/patches/0001-add-start-script.patch creates a script that isn't
> installed as part of the current wsjtx binary package.  This script must
> have been needed for an older version of WSJT-X.
>
> I believe the patch can be removed from the package.  If I'm mistaken,
> feel free to close this.

Hi Tony,

thanks for spotting that. There's a lot more cruft in that patches
directory, unfortunately...

If you like, we can also give you commit access to the hamradio group.

Christoph

Bug#932752: apt-get dist-upgrade fails on missing locales

[Jo Drexl]

Package: apt
Version: 1.4.9
Severity: important

Dear Maintainer,

when upgrading a fresh install of Stretch to Buster (German
localization) and having a Gnome desktop environment, libpam0g:amd64
fails to configure due to missing locales:

Preparing to unpack .../libpam0g_1.3.1-5_amd64.deb ...
Unpacking libpam0g:amd64 (1.3.1-5) over (1.1.8-3.6) ...
Setting up libpam0g:amd64 (1.3.1-5) ...
locale: Kann LC_ALL nicht auf die Standard-Lokale einstellen: Datei oder
Verzeichnis nicht gefunden
Checking for services that may need to be restarted...awk: error while
loading shared libraries: libtinfo.so.6: cannot open shared object file:
No such file or directory
Checking init scripts...
awk: error while loading shared libraries: libtinfo.so.6: cannot open
shared object file: No such file or directory
dpkg: error processing package libpam0g:amd64 (--configure):
subprocess installed post-installation script returned error exit
status 127
Errors were encountered while processing:
libpam0g:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

This is resulting in a dependency loop with libtinfo6, that can't be 
resolved by running apt-get install -f, even after regenerating the 
locales by hand (which is possible).

test@debian-test:~$ sudo locale-gen 
Generating locales (this might take a while)...
  de_DE.UTF-8... done
Generation complete.
test@debian-test:~$ sudo apt-get update && sudo apt-get dist-upgrade 
OK:1 http://debian.mirror.lrz.de/debian buster InRelease
OK:2 http://debian.mirror.lrz.de/debian buster-updates InRelease
OK:3 http://security.debian.org/debian-security buster/updates InRelease   
Paketlisten werden gelesen... Fertig   
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
installiert
 libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
Angabe eines Pakets (oder geben Sie eine Lösung an).
test@debian-test:~$ sudo apt-get install -f
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Abhängigkeiten werden korrigiert ... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr 
benötigt:
  guile-2.2-libs libncurses6 libpython3.7-minimal libsasl2-modules libzstd1
  mariadb-common python3.7-minimal
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
The following additional packages will be installed:
  libtinfo6
Die folgenden NEUEN Pakete werden installiert:
  libtinfo6
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 1323 nicht aktualisiert.
47 nicht vollständig installiert oder entfernt.
Es müssen noch 0 B von 325 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 534 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
libpam0g:amd64 (1.3.1-5) wird eingerichtet ...
Checking for services that may need to be restarted...awk: error while loading 
shared libraries: libtinfo.so.6: cannot open shared object file: No such file 
or directory
Checking init scripts...
awk: error while loading shared libraries: libtinfo.so.6: cannot open shared 
object file: No such file or directory
dpkg: Fehler beim Bearbeiten des Paketes libpam0g:amd64 (--configure):
 Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 
zurück
Fehler traten auf beim Bearbeiten von:
 libpam0g:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)

Delaying configuration won't help either:

test@debian-test:~$ sudo apt full-upgrade -o APT::Immediate-Configure=0
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Probieren Sie »apt --fix-broken install«, um dies zu korrigieren.
Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 guile-2.2-libs : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libedit2 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libllvm7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
 libncurses6 : Hängt ab von: libtinfo6 (= 6.1+20181013-2) ist aber nicht 
installiert
 libreadline7 : Hängt ab von: libtinfo6 (>= 6) ist aber nicht installiert
E: Unerfüllte Abhängigkeiten. Versuchen Sie »apt --fix-broken install« ohne 
Angabe eines Pakets (oder geben Sie eine Lösung an).

The issue can be resolved by combining apt --fix-broken install with
configuration delay:

test@debian-test:~$ sudo apt --fix-broken install -o 

Bug#932747: apt-get: AppStream system cache updated, failing on APT::Update::Post-Invoke-Success

[Jo Drexl]

Package: apt
Version: 1.4.9
Severity: normal
Tags: patch

Dear Maintainer,

on running apt-get update, sometimes the AppStream subprocess returns an
error:

The AppStream system cache was updated, but some errors were detected,
which might lead to missing metadata. Refer to the verbose log for more
information.
Paketlisten werden gelesen... Fertig
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if
/usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then
appstreamcli refresh-cache > /dev/null; fi'
E: Sub-process returned an error code

I've seen this error being persistent on some machines, while others
were thrown off repeatedly. A popular suggestion on the internet is to
comment out the test statement and proceed without a refreshed appstream
cache, which seems to work, so I suggest this being rolled out at least
to Debian Stretch.

FYI: Writing this from a freshly installed Debian Stretch, which now
undergoes another dist-upgrade test for me to report the bugs I've seen
on other machines and am able to reproduce here.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-9-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-9-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Periodic "";
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost "0";
APT::Compressor::lz4 "";
APT::Compressor::lz4::Name "lz4";
APT::Compressor::lz4::Extension ".lz4";
APT::Compressor::lz4::Binary "false";
APT::Compressor::lz4::Cost "50";
APT::Compressor::gzip "";
APT::Compressor::gzip::Name "gzip";
APT::Compressor::gzip::Extension ".gz";
APT::Compressor::gzip::Binary "gzip";
APT::Compressor::gzip::Cost "100";
APT::Compressor::gzip::CompressArg "";
APT::Compressor::gzip::CompressArg:: "-6n";
APT::Compressor::gzip::UncompressArg "";
APT::Compressor::gzip::UncompressArg:: "-d";
APT::Compressor::xz "";
APT::Compressor::xz::Name "xz";
APT::Compressor::xz::Extension ".xz";
APT::Compressor::xz::Binary "xz";

Bug#921232: Tracking it down

[Jo Shields]

Seems fixed in cd70e9cf2adc03681dbb919d97063d8ad84b0a4c, will apply this
against Debian packaging & upload

On 15/04/2019 22:55, Joseph Shields wrote:
> This is fine in master, but I can repro it with an otherwise clean upstream 
> git tag w/ our 4 s390x backports. Bisecting.

Bug#924942: www.debian.org: Suggestion; on the new people page, add a welcome message and a photo of the current DPL

[Jo McIntyre]

Package: www.debian.org
Severity: wishlist

Dear Maintainer,

On the people page of the new and improved website, have a photo of the 
current DPL and maybe with a paragraph or 2 just saying 'Hi, my name is 
 I am the Debian Project Leader' and a note welcoming a new person 
to Debian

Bug#921232: mono: Internal compiler error building libsbml on s390x

[Jo Shields]

Neale, can you try building libsbml (http://sbml.org/Software/libSBML)
on s390x against a Mono revision you trust? It could be something bad in
out 5.18 s390x backports, or it could be unrelated to that.

On 07/03/2019 16:16, Petter Reinholdtsen wrote:
> [Adrian Bunk]
>> We dn't have any kind of CI coverage on s390x,
>> it is therefore not obvious whether this is
>> a problem confined to one package or whether
>> Mono is completely broken on s390x.
> I guess that is just another way to say that no-one know if anyone is using
> mono on s390x?  Perhaps it is best to drop mono from s390x until it can
> be confimed to be working there, instead of risking mono to be dropped from
> buster on all the working architectures?

Bug#889509: rebase

[Jo Shields]

I gave rebasing Mihai's patch a shot. Seems to build, no word on 
functionality yet.


>From 051ded3a7694db6fa882fc48c8e0fe8b4d1cadc3 Mon Sep 17 00:00:00 2001
From: Jo Shields 
Date: Tue, 5 Feb 2019 11:55:48 -0500
Subject: [PATCH] Rebase changes for DNF support (Closes: #889509)

---
 debian/control|   1 +
 debian/libsolv0-dev.install   |   2 +-
 debian/libsolv0.symbols   |   2 +
 debian/libsolvext0.symbols|   2 +
 .../patches/1004_cmake-module-path-fix.patch  |  22 --
 ...005_install-cmake-module-into-libdir.patch |  16 +
 ...s-types.patch => 1006_various-typos.patch} |  76 +++--
 ...pool.h_c_debian-style-home-dir-rpmdb.patch | 317 ++
 ...v.ver_add-new-pool-homedir-functions.patch |  16 +
 ...olv.i_add-new-pool-homedir-functions.patch |  20 ++
 ...-misc_add-new-pool-homedir-functions.patch | 123 +++
 debian/patches/series |   8 +-
 debian/rules  |   3 +-
 13 files changed, 553 insertions(+), 55 deletions(-)
 delete mode 100644 debian/patches/1004_cmake-module-path-fix.patch
 create mode 100644 debian/patches/1005_install-cmake-module-into-libdir.patch
 rename debian/patches/{1006_various-types.patch => 1006_various-typos.patch} (69%)
 create mode 100644 debian/patches/3000_ext-repo_rpmdb.c_src_pool.h_c_debian-style-home-dir-rpmdb.patch
 create mode 100644 debian/patches/3010_src-libsolv.ver_add-new-pool-homedir-functions.patch
 create mode 100644 debian/patches/3020_bindings-solv.i_add-new-pool-homedir-functions.patch
 create mode 100644 debian/patches/3030_doc-misc_add-new-pool-homedir-functions.patch

diff --git a/debian/control b/debian/control
index 95b896e..500a697 100644
--- a/debian/control
+++ b/debian/control
@@ -7,6 +7,7 @@ Build-Depends:
  dh-python,
  dpkg-dev (>= 1.16.1.1),
  cdbs,
+ dh-python,
  cmake,
  libexpat1-dev,
  zlib1g-dev,
diff --git a/debian/libsolv0-dev.install b/debian/libsolv0-dev.install
index 8b2eae2..4857af5 100644
--- a/debian/libsolv0-dev.install
+++ b/debian/libsolv0-dev.install
@@ -26,5 +26,5 @@ usr/include/*/solv/testcase.h
 usr/include/*/solv/transaction.h
 usr/include/*/solv/util.h
 usr/lib/*/libsolv.so
-usr/lib/*/cmake/
+usr/lib/*/cmake/libsolv/FindLibSolv.cmake
 usr/lib/*/pkgconfig/libsolv.pc
diff --git a/debian/libsolv0.symbols b/debian/libsolv0.symbols
index ea41865..7f4ec5a 100644
--- a/debian/libsolv0.symbols
+++ b/debian/libsolv0.symbols
@@ -75,6 +75,7 @@ libsolv.so.0 libsolv0 #MINVER#
  pool_freewhatprovides@SOLV_1.0 0.6.5
  pool_get_flag@SOLV_1.0 0.6.5
  pool_get_rootdir@SOLV_1.0 0.6.5
+ pool_get_use_homedir@SOLV_1.1 0.6.30-2~
  pool_id2evr@SOLV_1.0 0.6.5
  pool_id2langid@SOLV_1.0 0.6.5
  pool_id2rel@SOLV_1.0 0.6.5
@@ -105,6 +106,7 @@ libsolv.so.0 libsolv0 #MINVER#
  pool_set_installed@SOLV_1.0 0.6.5
  pool_set_languages@SOLV_1.0 0.6.5
  pool_set_rootdir@SOLV_1.0 0.6.5
+ pool_set_use_homedir@SOLV_1.1 0.6.30-2~
  pool_set_whatprovides@SOLV_1.2 0.6.34
  pool_setarch@SOLV_1.0 0.6.5
  pool_setarchpolicy@SOLV_1.0 0.6.5
diff --git a/debian/libsolvext0.symbols b/debian/libsolvext0.symbols
index 08cdf28..4c36aad 100644
--- a/debian/libsolvext0.symbols
+++ b/debian/libsolvext0.symbols
@@ -1,12 +1,14 @@
 libsolvext.so.0 libsolvext0 #MINVER#
  SOLV_1.0@SOLV_1.0 0.6.5
  pool_findfileconflicts@SOLV_1.0 0.6.5
+ pool_parserpmrichdep@SOLV_1.0 0.6.30
  pool_deb_get_autoinstalled@SOLV_1.0 0.6.10
  repo_add_arch_local@SOLV_1.0 0.6.5
  repo_add_arch_pkg@SOLV_1.0 0.6.5
  repo_add_arch_repo@SOLV_1.0 0.6.5
 #MISSING: 0.6.24-1# repo_add_autopattern@SOLV_1.0 0.6.5
  repo_add_code11_products@SOLV_1.0 0.6.5
+ repo_add_comps@SOLV_1.0 0.6.30-2~
  repo_add_content@SOLV_1.0 0.6.5
  repo_add_cudf@SOLV_1.0 0.6.5
  repo_add_deb@SOLV_1.0 0.6.5
diff --git a/debian/patches/1004_cmake-module-path-fix.patch b/debian/patches/1004_cmake-module-path-fix.patch
deleted file mode 100644
index 6e3f999..000
--- a/debian/patches/1004_cmake-module-path-fix.patch
+++ /dev/null
@@ -1,22 +0,0 @@
-Description: Rename FindLibSolv.cmake to LibSolvConfig.cmake after installation.
-Author: Mike Gabriel 
-
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -1,6 +1,6 @@
- PROJECT (libsolv)
- 
--CMAKE_MINIMUM_REQUIRED (VERSION 2.4)
-+CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
- 
- OPTION (ENABLE_STATIC "Build a static version of the libraries?" OFF)
- OPTION (DISABLE_SHARED "Do not build a shared version of the libraries?" OFF)
-@@ -73,7 +73,7 @@
- 
- # where to look first for cmake modules, before ${CMAKE_ROOT}/Modules/ is checked
- SET (CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/modules)
--INSTALL( FILES ${CMAKE_MODULE_PATH}/FindLibSolv.cmake DESTINATION ${CMAKE_INSTALL_PREFIX}/share/cmake/Modules )
-+INSTALL( FILES ${CMAKE_MODULE_PATH}/FindLibSolv.cmake RENAME LibSolvConfig.cmake DESTINATION ${LIB_INSTALL_DIR}/cmake/LibSolv/ )
- 
- INCLUDE (${CMAKE_SOURCE_DIR}/VERSION.cmake)
- 
diff --git a/debian/patches/1005_install-cmake-m

Bug#920531: marked as done (libmono-system-native.so missing)

[Jo Shields]

Whoops

directhex@bubblegum:~/Projects/pkg-mono/mono$ git push origin master
Counting objects: 15, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (15/15), done.
Writing objects: 100% (15/15), 1.71 KiB | 1.71 MiB/s, done.
Total 15 (delta 11), reused 0 (delta 0)
To salsa.debian.org:dotnet-team/mono.git
   511ad1dddbe..731b958411d  master -> master
directhex@bubblegum:~/Projects/pkg-mono/mono$ git push origin
debian/5.18.0.240+dfsg-2
Counting objects: 1, done.
Writing objects: 100% (1/1), 187 bytes | 187.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0)
To salsa.debian.org:dotnet-team/mono.git
 * [new tag] debian/5.18.0.240+dfsg-2 ->
debian/5.18.0.240+dfsg-2

It's there now

On 26/01/2019 18:00, Paul Hebble wrote:
> The link to the Homebrew issue in my previous email was incorrect, it should 
> be:
>   https://github.com/KSP-CKAN/CKAN/issues/2630
> I'm sorry for the confusion.
> 

Bug#919834: libmono-btls-shared.so: undefined symbols: needs -pthread

[Jo Shields]

I'll try to get around to forwarding this upstream

As you guessed, it's not directly an issue because mono-btls-shared is a
plugin used by /usr/bin/mono-sgen, which is linked adequately.

On 19/01/2019 20:35, Paul Wise wrote:
> Package: mono-runtime-common
> Version: 5.18.0.240+dfsg-1
> Severity: minor
> File: /usr/lib/libmono-btls-shared.so
> User: debian...@lists.debian.org
> Usertags: undefined-symbol adequate
> 
> libmono-btls-shared.so needs to compile and link with -pthread, see the
> output of adequate, symtree and objdump below. I detected this on amd64
> but the Debian build log scanner also detected dpkg-buildpackage
> complaining about it on most architectures, see the w3m/getbuildlog
> output below. In addition dpkg-buildpackage detected underlinking in
> some other files.
> 
> I filed this bug at severity minor since I'm not sure if there are any
> programs using the libmono-btls-shared.so lib or if they already use
> the libpthread symbols and compile and link with -pthread or not.
> 
> This bug report brought to you by adequate:
> 
> http://bonedaddy.net/pabs3/log/2013/02/23/inadequate-software/
> 
> $ adequate mono-runtime-common
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_rdlock
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_init
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_getspecific
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_destroy
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_key_create
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_wrlock
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_once
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_setspecific
> mono-runtime-common: undefined-symbol /usr/lib/libmono-btls-shared.so => 
> pthread_rwlock_unlock
> 
> $ man adequate | grep -A4  undefined-symbol
>undefined-symbol
>The symbol has not been found in the libraries linked with the 
> binary.
>Either the binary either needs to be linked with an additional 
> shared library,
>or the dependency on the shared library package that provides this 
> symbol is too weak.
> 
>References: Debian Policy §3.5, §8.6, §10.2.
> 
> $ lddtree /usr/lib/libmono-btls-shared.so
> libmono-btls-shared.so => /usr/lib/libmono-btls-shared.so (interpreter => 
> none)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
> 
> $ symtree /usr/lib/libmono-btls-shared.so
> /usr/lib/libmono-btls-shared.so
> libc.so.6 => 
> socket,fflush,gmtime_r,gai_strerror,strncmp,__isoc99_sscanf,connect,ftell,strncpy,time,__stack_chk_fail,pthread_mutex_lock,realloc,abort,memchr,strdup,__assert_fail,feof,fgets,calloc,strlen,isxdigit,send,getaddrinfo,memset,__errno_location,fseek,read,memcmp,getsockopt,shutdown,__fprintf_chk,pthread_mutex_unlock,recv,fputs,lseek,memcpy,memcpy,fclose,__vsnprintf_chk,strtoul,setsockopt,malloc,strcasecmp,__ctype_b_loc,getenv,stderr,dup,__memset_chk,strncasecmp,fwrite,fread,gettimeofday,__memcpy_chk,close,open,strchr,qsort,__ctype_tolower_loc,__cxa_finalize,freeaddrinfo,fcntl,__xstat,isdigit,memmove,fopen64,__strcat_chk,strcmp,strerror,ferror,write,free
> WEAK => 
> _ITM_deregisterTMCloneTable,__gmon_start__,_ITM_registerTMCloneTable
> UNRESOLVED => 
> pthread_rwlock_rdlock,pthread_rwlock_init,pthread_getspecific,pthread_rwlock_destroy,pthread_key_create,pthread_rwlock_wrlock,pthread_once,pthread_setspecific,pthread_rwlock_unlock
> 
> $ objdump -T /lib/x86_64-linux-gnu/libpthdl.so.2 | grep -E "($(symtree 
> /usr/lib/x86_64-linux-gnu/libzvbi-chains.so.0.0.0 | sed -n 's/UNRESOLVED 
> => //p' | tr , '|'))$"
> libpthread-2.28.so  libpthread.so.0 
> 
> $ objdump -T /lib/x86_64-linux-gnu/libpthread.so.0 | grep -E "($(symtree 
> /usr/lib/libmono-btls-shared.so | sed -n 's/UNRESOLVED => //p' | tr , 
> '|'))$"
> ced0 gDF .text03cf  GLIBC_2.2.5 
> __pthread_rwlock_wrlock
> f330 gDF .text00ee  GLIBC_2.2.5 
> __pthread_setspecific
> f200 gDF .text0056  GLIBC_2.2.5 
> __pthread_key_create
> c9e0 gDF .text0003  GLIBC_2.2.5 
> __pthread_rwlock_destroy
> d780  w   DF .text01db  GLIBC_2.2.5 
> pthread_rwlock_unlock
> c9a0 gDF .text003a  GLIBC_2.2.5 
> __pthread_rwlock_init
> f2a0 gDF .text0083  GLIBC_2.2.5 
> __pthread_getspecific
> c9e0 gDF .text0003  GLIBC_2.2.5 
> pthread_rwlock_destroy
> f330  w   DF .text00ee  

Bug#919371: mono won't migrate to testing, still b-d on gcc-5

[Jo Shields]

OK, I have a status update on this.

* I can't get a minimal patch set against mono-2018-06 branch (Mono
5.16) which builds the entire release to completion on s390x on versions
of gcc with PIC/PIE by default (Debian gcc-6 or later)
* I picked the version I uploaded, on the basis that it is part of the
`vs` packaging branch on mono-project.com, which mirrors what last went
into a stable release of Visual Studio for Mac (and hopefully should
have something resembling a vendor support story)
* I _can_ get a minimal patch set against mono-2018-08 (Mono 5.18)
* 5.18 Should not cause any major changes at a packaging level, compared
to 5.16 (i.e. it should not go into binary NEW)
* 5.18 is considered "stable" by the Mono runtime team, but not yet by
the Visual Studio for Mac team (the standalone runtime doesn't get QA
before releases, only as part of a larger VSMac release cycle)
* 5.18 might totally break on other architectures! There is no MIPS
testing upstream, so mipsel might be broken on any given release
(upstream builds for i386, armel, armhf, arm64, amd64, and ppc64el)

I don't want to preempt any product announcements, but 5.18 may ship
significantly faster than originally planned, meaning investing too much
time in fixing up 5.16 this week may be wasted, compared to 5.18 closer
to *mumble mumble*. I'll discuss with relevant stakeholders tomorrow.

On 15/01/2019 07:37, Jo Shields wrote:
> Thanks for the tracking bug. I spotted this last night and am working on 
> zelenka to convince the damn thing to build - it's something to do with PIE, 
> and only shows up as a problem with the Runtime crashing in the literal last 
> 30 seconds of the build step 
> 
> Sent from my iPhone
> 
>> On 15 Jan 2019, at 05:45, Matthias Klose  wrote:
>>
>> Package: src:mono
>> Version: 5.16.0.220+dfsg3-2
>> Severity: serious
>> Tags: sid buster
>>
>> mono won't migrate to testing, still b-d on gcc-5 on s390x.
>>
> 

Bug#919371: mono won't migrate to testing, still b-d on gcc-5

[Jo Shields]

Thanks for the tracking bug. I spotted this last night and am working on 
zelenka to convince the damn thing to build - it's something to do with PIE, 
and only shows up as a problem with the Runtime crashing in the literal last 30 
seconds of the build step 

Sent from my iPhone

> On 15 Jan 2019, at 05:45, Matthias Klose  wrote:
> 
> Package: src:mono
> Version: 5.16.0.220+dfsg3-2
> Severity: serious
> Tags: sid buster
> 
> mono won't migrate to testing, still b-d on gcc-5 on s390x.
> 

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Jo Shields]

Another reason this bug makes no sense is there's no 5.18 references at
all in src:mono, and it doesn't depend on anything externally which
could add it.



I'll try a no-change version bump on another computer.

On 12/01/2019 09:42, Ingo Saitz wrote:
> On Fri, Jan 11, 2019 at 09:52:46PM -0500, Jo Shields wrote:
>> Maybe a typo in debian/rules? I do my builds in a chroot, this kind of thing 
>> shouldn't happen 
> 
> I just tried rebuilding mono 5.16.0.220+dfsg3-1 in a clean chroot, and
> the dependencies look good:
> 
> Package: libmono-system4.0-cil
> Source: mono
> Version: 5.16.0.220+dfsg3-1
> Architecture: all
> Maintainer: Debian Mono Group 
> Installed-Size: 3101
> Depends: libc6 (>= 2.28) | libc6.1 (>= 2.28) | libc0.1 (>= 2.28), 
> libmono-corlib4.5-cil (>= 5.16.0.220), libmono-security4.0-cil (>= 4.6.1.3), 
> libmono-system-configuration4.0-cil (>= 4.0.0~alpha1), 
> libmono-system-xml4.0-cil (>= 4.6.1.3), mono-runtime (>= 5.16.0.220), 
> mono-runtime (<< 5.16.0.221)
> Recommends: ca-certificates-mono (= 5.16.0.220+dfsg3-1)
> Suggests: libasound2 (>> 1.0.18), libgamin0
> Section: cli-mono
> Priority: optional
> Homepage: http://www.mono-project.com/
> Description: Mono System libraries (for CLI 4.0)
>  Mono is a platform for running and developing applications based on the
>  ECMA/ISO Standards. Mono is an open source effort led by Xamarin.
>  Mono provides a complete CLR (Common Language Runtime) including compiler and
>  runtime, which can produce and execute CIL (Common Intermediate Language)
>  bytecode (aka assemblies), and a class library.
>  .
>  This package contains the BCL (Base Class Libraries) of Mono for CLI 4.0.
> 
> 
> I'll keep the buildroot around till this bug can be closed, just query
> me if you want additional information about it.
> 
> Ingo
> 

Bug#919031: libmono-system4.0-cil: not installable on amd64

[Jo Shields]

Maybe a typo in debian/rules? I do my builds in a chroot, this kind of thing 
shouldn't happen 

Sent from my iPhone

> On 11 Jan 2019, at 20:03, Ingo Saitz  wrote:
> 
> Package: libmono-system4.0-cil
> Version: 5.16.0.220+dfsg3-1
> Severity: important
> 
> Dear Maintainer,
> 
> libmono-system4.0-cil contains in its dependencies on amd64 a dependency
> on mono-runtime-common 5.18:
> 
> Depends: ..., mono-runtime (>= 5.16.0.220), mono-runtime-common (>= 
> 5.18.0.225), mono-runtime (<< 5.16.0.221)
> 
> This probably will never work, since mono-runtime depends on the exact
> same version of mono-runtime-common. The dependency is not listed in
> debian/control, so it seems it must have been introduced by
> ${misc:Depends} or ${cli:Depends} - was this package built on a system
> with mono 5.18 packages installed?
> 
> 
> -- System Information:
> Debian Release: buster/sid
>  APT prefers unstable
>  APT policy: (800, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.19.12-echse-4.1920181222 (SMP w/2 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
> 
> Versions of packages libmono-system4.0-cil depends on:
> ii  libc62.28-4
> ii  libmono-corlib4.5-cil4.6.2.7+dfsg-2
> ii  libmono-security4.0-cil  4.6.2.7+dfsg-2
> ii  libmono-system-configuration4.0-cil  4.6.2.7+dfsg-2
> ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-2
> ii  mono-runtime 4.6.2.7+dfsg-2
> 
> Versions of packages libmono-system4.0-cil recommends:
> ii  ca-certificates-mono  4.6.2.7+dfsg-2
> 
> Versions of packages libmono-system4.0-cil suggests:
> ii  libasound2  1.1.7-2
> ii  libgamin0   0.1.10-5+b1
> 
> -- no debconf information
> 

Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"

[Jo Shields]

On 11/01/2019 10:22, Mathieu Malaterre wrote:
> However the build failed for me later on, reporting a failure to find
> 'mcs' (*). My G4 is rather slow so let me try again to check there are
> no other build failure later on. Mark do you have a faster ppc machine
> ?
>
> (*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then
> :; else chmod -R +w
> /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi
> cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make
> --no-print-directory -s NO_DIR_CHECK=1
> PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14
>  ' CC='gcc' all-profiles
> mkdir -p -- build/deps
> make[7]: mcs: Command not found


The class library needs a C# compiler, so first it checks whether you
have one in $PATH it can use. It is normal that you wouldn't have one
(and it would likely be too out of date anyway, and get rejected)


> make[7]: *** [build/profiles/basic.make:118:
> build/deps/basic-profile-check.exe] Error 127
> *** The runtime 'mono' doesn't appear to be usable.
> *** Trying the 'monolite-linux/1051600014' directory.


Now it's looking at the bootstrap compiler bundled into the source
package, and checking the version on it.


> Unhandled Exception:
> System.NullReferenceException: Object reference not set to an instance
> of an object
>   at Mono.CSharp.Binary.CreatePointerOperatorsTable
> (Mono.CSharp.BuiltinTypes types) [0x0006b] in
> <9d70195405974ada92fc07fda5c6d57c>:0
> [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException:
> Object reference not set to an instance of an object
>   at Mono.CSharp.Binary.CreatePointerOperatorsTable
> (Mono.CSharp.BuiltinTypes types) [0x0006b] in
> <9d70195405974ada92fc07fda5c6d57c>:0


Here's a real problem - the runtime is totally screwing up the basic
compiler check. Looping in Calvin (HI CALVIN!) - does the above look
familiar, in any of your PowerPC tinkering?


> make[9]: *** [build/profiles/basic.make:118:
> build/deps/basic-profile-check.exe] Error 1
> *** The contents of your 'monolite-linux/1051600014' directory may be
> out-of-date
> *** You may want to try 'make get-monolite-latest'


The build system gives up as it can't find a viable compiler to use.

Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"

[Jo Shields]

Okay, that looks interesting.


We aren't CI-ing on 32-bit PowerPC upstream, currently. I likely have
enough resources spare on my POWER8 server to set up a VM (I'm told I
can get KVM acceleration for big-endian on a little-endian OS?) but I
have no idea how long that will take me to set up. Almost all our
PowerPC maintenance is community-provided, largely by one guy. I don't
know how much real 32-bit PPC testing he's doing.

On 11/01/2019 10:22, Mathieu Malaterre wrote:
> On Fri, Jan 11, 2019 at 4:11 PM Jo Shields  wrote:
>> Hi Mathieu,
>>
>>
>> Are you in a position to test a patch? In theory
>> https://github.com/mono/boringssl/commit/59b78d07a483450a5d2a1c06b83f04a1e64ba68a
>> is sufficient to make it work. I don't want to throw another build at
>> the buildd until this gets through into testing.
> Starring at it it should work. I was about to submit:
>
> @@ -85,6 +85,8 @@ extern "C" {
>  #define OPENSSL_ARM
>  #elif defined(__PPC64__) || defined(__powerpc64__)
>  #define OPENSSL_64_BIT
> +#elif defined(__PPC__) && !defined(__PPC64__)
> +#define OPENSSL_32_BIT
>  #elif defined(__mips__) && !defined(__LP64__)
>  #define OPENSSL_32_BIT
>  #define OPENSSL_MIPS
>
> Since:
>
> $ powerpc-linux-gnu-gcc -m32 -dM -E - < /dev/null | grep PPC
> #define _ARCH_PPC 1
> #define __PPC__ 1
> #define __PPC 1
> #define PPC 1
> mathieu@macbookpro $ powerpc-linux-gnu-gcc -m64 -dM -E - < /dev/null | grep 
> PPC
> #define _ARCH_PPCGR 1
> #define __PPC64__ 1
> #define _ARCH_PPC 1
> #define __PPC__ 1
> #define _ARCH_PPC64 1
>
> Stick to upstream this looks just fine.
>
> However the build failed for me later on, reporting a failure to find
> 'mcs' (*). My G4 is rather slow so let me try again to check there are
> no other build failure later on. Mark do you have a faster ppc machine
> ?
>
> (*)if test -w /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; then
> :; else chmod -R +w
> /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs; fi
> cd /home/mathieu/tmp/debian/mono-5.16.0.220+dfsg3/mcs && make
> --no-print-directory -s NO_DIR_CHECK=1
> PROFILES='binary_reference_assemblies net_4_x xbuild_12 xbuild_14
>  ' CC='gcc' all-profiles
> mkdir -p -- build/deps
> make[7]: mcs: Command not found
> make[7]: *** [build/profiles/basic.make:118:
> build/deps/basic-profile-check.exe] Error 127
> *** The runtime 'mono' doesn't appear to be usable.
> *** Trying the 'monolite-linux/1051600014' directory.
>
> Unhandled Exception:
> System.NullReferenceException: Object reference not set to an instance
> of an object
>   at Mono.CSharp.Binary.CreatePointerOperatorsTable
> (Mono.CSharp.BuiltinTypes types) [0x0006b] in
> <9d70195405974ada92fc07fda5c6d57c>:0
> [ERROR] FATAL UNHANDLED EXCEPTION: System.NullReferenceException:
> Object reference not set to an instance of an object
>   at Mono.CSharp.Binary.CreatePointerOperatorsTable
> (Mono.CSharp.BuiltinTypes types) [0x0006b] in
> <9d70195405974ada92fc07fda5c6d57c>:0
> make[9]: *** [build/profiles/basic.make:118:
> build/deps/basic-profile-check.exe] Error 1
> *** The contents of your 'monolite-linux/1051600014' directory may be
> out-of-date
> *** You may want to try 'make get-monolite-latest'

Bug#918976: include/openssl/base.h:107:2: error: #error "Unknown target CPU"

[Jo Shields]

Hi Mathieu,


Are you in a position to test a patch? In theory
https://github.com/mono/boringssl/commit/59b78d07a483450a5d2a1c06b83f04a1e64ba68a
is sufficient to make it work. I don't want to throw another build at
the buildd until this gets through into testing.


On 11/01/2019 04:09, Mathieu Malaterre wrote:
> Source: mono
> Version: 5.16.0.220+dfsg3-1
> User: debian-powe...@lists.debian.org
> Usertags: powerpc
>
> mono currently fails to compile on powerpc, let's log progress here.
>
> Ref:
> * 
> https://buildd.debian.org/status/fetch.php?pkg=mono=powerpc=5.16.0.220%2Bdfsg3-1=1547184646=0
>

Bug#913652:

[jo . suhter]

Dear Jörg,

thanks for your reply. I totally agree that this is not a severe bug 
because a) the Debian build system calls the autoconf tools 
automatically and b) a "normal user" can call them manually. The 
severity was likely set by the "reportbug" program which I have used for 
the first time.


Also, thank you for mentioning the sbuild and pbuilder programs. I will 
have a look into both of them.


Still, the xsane source package ships with a xsane.INSTALL documentation 
which tells to execute ./configure and a broken configure script. It 
might be better to have no configure script at all, or an 
xsane.INSTALL.Debian which lists the Debian specific build steps.


But OK, search machines now may find this bug report including the 
(manual) solutions, so this might be an acceptable tradeoff.


Thanks for maintaining the xsane program

Johann

Bug#912043: RE: mono: please upload mono v5

[Jo Shields]

Good steps: join #debian-cli on Freenode, and bug Meebey to give you
access to the Salsa group (I don't think I have sufficient rights to do it).

One thing that would help lighten the load is for someone to take care
of the ancillary repos - libgdiplus, mod-mono, mono-vbnc, xsp, fsharp
etc. I can go into more detail on the release process in IRC, if we want
to be sure to pick versions with something approaching "LTS" status.

On 27/10/2018 14:21, Alexandre Viau wrote:
> On 2018-10-27 2:16 p.m., Jo Shields wrote:
>> Mostly https://github.com/mono/mono/issues/7445#issuecomment-409363281
>> is the state of the art on the topic.
> 
> Ah! I found it just after my last post on this bug.
> 
>> I will be spending all of next week working on this, but I have no idea
>> how ftpmaster will react to some of the necessary changes (e.g. BTLS)
> 
> Great! I am very happy to hear this.
> 
> Let me know if I can help in any way.
> 



signature.asc
Description: OpenPGP digital signature

Bug#912043: RE: mono: please upload mono v5

[Jo Shields]

Mostly https://github.com/mono/mono/issues/7445#issuecomment-409363281
is the state of the art on the topic.

I will be spending all of next week working on this, but I have no idea
how ftpmaster will react to some of the necessary changes (e.g. BTLS)

On 27/10/2018 13:27, Alexandre Viau wrote:
> Hello Jo,
> 
> I notice that you are working on Mono's official packaging for Mono v5 here:
>  - https://github.com/mono/linux-packaging-mono
> 
> Is there any reason why you are not uploading to Debian?
> 
> Would you please document your blockers, if any, in this bug?
> 
> I'd love to see Mono v5 in Debian but the packaging looks very
> complicated and I would prefer if somebody with your experienced worked
> on it. However, I might be able to help on some blockers that you may have.
> 
> Thank you in advance,
> 



signature.asc
Description: OpenPGP digital signature

Bug#911658: Please update Debian's Mono suite to current upstream

[Jo Shields]

It's on my list for this sprint but I've been fighting fires 

Sent from my iPhone

> On 23 Oct 2018, at 03:00, Daniel Richard G.  wrote:
> 
> Package: mono-runtime
> Version: 4.6.2.7+dfsg-2
> 
> As of this writing, the current upstream stable release version of Mono
> is 5.16.0. Many changes have been made in Mono since 4.6 and I've run
> into .NET applications that will not run with the existing packaged
> version. Debian's Mono suite is sorely in need of an update.
> 

Bug#899395: [PATCH] mono: FTBFS on various architectures

[Jo Shields]

Thanks, Frédéric

ppc64 benefits from this, but there's still something going on with
s390x - there's a segfault as soon as the runtime starts, and as far as
I can tell, it's in the inline assembly in
https://github.com/mono/mono/blob/mono-4.6.2.7/mono/utils/mono-compiler.h#L132-L172
- specifically I think it's the __PIE__==2 case.

I've asked the s390x porter to talk to DSA about machine access, since
we can't reproduce the issue on our CI systems (which are running much
older OSes): https://github.com/mono/mono/issues/9009

On 20/07/18 12:21, Frédéric Bonnard wrote:
> Tags: patch pending
>
> Dear maintainer,
>
> a similar bug was fixed on redhat/fedora ( 
> https://bugzilla5.redhat.com/show_bug.cgi?id=1484149 ) :
> ---
> * Wed Sep 20 2017 Than Ngo  - 4.8.0-12
> - fixed the build failure on s390x/ppc64/ppc64le/aarch64 against new
>   glibc which drops the tag struct ucontext
> ---
> here is the patch used
> https://src.fedoraproject.org/rpms/mono/raw/master/f/mono-4.8.0.520-glibc-ucontext.patch
>
> I tested it and the package built successfully on ppc64el with 4.6.2.7+dfsg-2 
> .
> Regards,
>
> F.




signature.asc
Description: OpenPGP digital signature

Bug#899395: mono: FTBFS on various architectures

[Jo Shields]

Probably issues w/ GCC being more strict than last time it was built.
Will investigate when I have time.


On 23/05/18 13:56, Sven Joachim wrote:
> Source: mono
> Version: 4.6.2.7+dfsg-2
> Severity: serious
>
> The new mono version FTBFS on four architectures where it has been built
> before, including two release architectures.
>
> On S390x, the error looks like this[1]:
>
> ,
> |   CC   mono-mmap.lo
> | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
> |  -I../../libgc/include -I../../eglib/src -I../../eglib/src 
> -fvisibility=hidden
> |  -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE 
> -D_REENTRANT
> |  -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
> |  -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
> -Wnested-externs
> |  -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
> |  -Wno-unused-value -Wno-attributes -DUSE_COMPILER_TLS -g -O2
> |  -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. 
> -fstack-protector-strong
> |  -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
> |  -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
> |  -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
> |  -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
> |  -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value 
> -Wno-attributes
> |  -mbackchain -D__USE_STRING_INLINES -Werror-implicit-function-declaration 
> -MT
> |  mono-mmap.lo -MD -MP -MF .deps/mono-mmap.Tpo -c mono-mmap.c -fPIC -DPIC -o
> |  .libs/mono-mmap.o
> | In file included from ../../mono/utils/mono-threads.h:14:0,
> |   from mono-mmap.c:37:
> | ../../mono/utils/mono-stack-unwinding.h:96:14: error: field 'ctx' has 
> incomplete type
> |   MonoContext ctx;
> |^~~
> | make[3]: *** [Makefile:841: mono-mmap.lo] Error 1
> `
>
> On ppc64el, ppc64 and powerpc there is a different error[2]:
>
> ,
> |   CC   mono-context.lo
> | libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../mono
> | -I../../libgc/include -I../../eglib/src -I../../eglib/src 
> -fvisibility=hidden
> | -Wdate-time -D_FORTIFY_SOURCE=2 -DGC_LINUX_THREADS -D_GNU_SOURCE 
> -D_REENTRANT
> | -DUSE_MMAP -DUSE_MUNMAP -g -Wall -Wunused -Wmissing-prototypes
> | -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
> -Wnested-externs
> | -Wpointer-arith -Wno-cast-qual -Wwrite-strings -Wno-switch -Wno-switch-enum
> | -Wno-unused-value -Wno-attributes -D__mono_ppc__ -D__mono_ppc64__ -g -O2
> | -fdebug-prefix-map=/<>/mono-4.6.2.7+dfsg=. 
> -fstack-protector-strong
> | -Wformat -Werror=format-security -std=gnu99 -fno-strict-aliasing -fwrapv
> | -DMONO_DLL_EXPORT -Wno-unused-but-set-variable -g -Wall -Wunused
> | -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes
> | -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wno-cast-qual
> | -Wwrite-strings -Wno-switch -Wno-switch-enum -Wno-unused-value 
> -Wno-attributes
> | -mminimal-toc -Werror-implicit-function-declaration -MT mono-context.lo -MD 
> -MP
> | -MF .deps/mono-context.Tpo -c mono-context.c -fPIC -DPIC -o 
> .libs/mono-context.o
> | In file included from mono-context.c:9:0:
> | 
> | mono-context.c: In function 'mono_sigctx_to_monoctx':
> | ../../mono/utils/mono-sigcontext.h:267:58: error: dereferencing pointer to 
> incomplete type 'os_ucontext {aka struct ucontext}'
> |   #define UCONTEXT_REG_NIP(ctx) 
> (((os_ucontext*)(ctx))->uc_mcontext.gp_regs [PT_NIP])
> |   ^
> | mono-context.c:407:16: note: in expansion of macro 'UCONTEXT_REG_NIP'
> |   mctx->sc_ir = UCONTEXT_REG_NIP(uc);
> | ^~~~
> | make[3]: *** [Makefile:841: mono-context.lo] Error 1
> `
>
>
> 1. 
> https://buildd.debian.org/status/fetch.php?pkg=mono=s390x=4.6.2.7%2Bdfsg-2=1526962622=0
> 2. 
> https://buildd.debian.org/status/fetch.php?pkg=mono=ppc64el=4.6.2.7%2Bdfsg-2=1526971899=0
>

Bug#893860: monodevelop: Intent to file Debian removal bug

[Jo Shields]

Much as it saddens me to say it, I think you're absolutely right. 
Realistically, we can't build a DFSG-Free release of a recent MonoDevelop 
without a huge increase in developer headcount (and about 120 new libraries).


Sent from Outlook


From: Jeremy Bicha 
Sent: 23 March 2018 08:52
To: submit
Subject: Bug#893860: monodevelop: Intent to file Debian removal bug

Source: monodevelop
Version: 5.10.0.871-2
Severity: serious
Tags: buster unstable
X-Debbugs-CC: joshi...@microsoft.com

monodevelop hasn't been updated in Debian for 2 years.

Along with a few other apps, it is blocking the complete removal of
the old webkitgtk library from Debian.

If monodevelop is not going to be maintained in Debian, maybe it's
better for it to be removed from Debian and we can point users to
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.monodevelop.com%2Fdownload%2F%23fndtn-download-lin-debian=04%7C01%7Cjoshield%40microsoft.com%7Cb10462b604214630019108d590bd96cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636574066315078900%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=1unq2D4yI1E39J9SSr8Nu%2FjPFwvCBUQ1D5CuHiMyN%2Bs%3D=0

and maybe it will be available in a Flatpak or Snap some day too.

Please let me know if you'd like me to file a Debian removal bug or
what your plan is for Debian.

Thanks,
Jeremy Bicha

Bug#891637: dh_clideps: "ignores" in clideps-override does not work

[Jo Shields]

Package: cli-common-dev
Version: 0.9+nmu1

Dear maintainer,

dh_clideps supports four types of override - suggests, depends, recommends, and 
ignores. It seems logic for ignores is faulty - whilst the override loading 
code acknowledges the override, it doesn't act upon it (i.e. it knows it should 
ignore, and immediately adds a dependency anyway).

The attached patch resolves the issue.


Sent from Outlook
diff --git a/dh_clideps b/dh_clideps
index 18486ed..d10bdc7 100755
--- a/dh_clideps
+++ b/dh_clideps
@@ -535,6 +535,9 @@ sub resolveOverride {
 } else {
   $newpkgref = $pkgref;
 }
+if ($1 eq "ignores") {
+  $newpkgref = "";
+}
   }
   verbose_print("resolved pkgref: $pkgref to $type: $newpkgref");
   $ret{$type} = $newpkgref;

Bug#887598: ITP: jasp -- Offers standard analysis procedures in both their classical and Bayesian form

[jo...@jorisgoosen.nl]

Hi All,

I am new to debian packaging but have tried to follow the guides for new
maintainers in setting up the sources so that it can be converted into a
debian package by simply running a script. Also i've taken care to make
lintian at least scan the package without complaining. It might be the case
that I missed something

@Michael: I will also take a look at the PR some more, we can probably use
some parts to make upstream better suited for debian.

Best regards,
Joris



On 22 January 2018 at 06:37, Michael Hanke <michael.ha...@gmail.com> wrote:

> Hi,
>
> just FYI there is/was a PR on JASP's GitHub with a semi complete
> packaging. It had quite a few TODOs, but they should be detailed in the PR.
> Maybe that is a useful starting point.
>
> Cheers,
>
> Michael
>
>
>
> On Jan 21, 2018 21:35, "Andreas Tille" <andr...@an3as.eu> wrote:
>
>> Hi Joris,
>>
>> thanks for this ITP.  Please consider maintaining the package in Debian
>> Science team.
>>
>> Kind regards
>>
>>   Andreas.
>>
>> On Thu, Jan 18, 2018 at 11:02:34AM +0100, jo...@jorisgoosen.nl wrote:
>> > Package: wnpp
>> > Severity: wishlist
>> > Owner: Joris Goosen <jo...@jorisgoosen.nl>
>> > X-Debbugs-Cc: debian-de...@lists.debian.org
>> >
>> > * Package name: jasp
>> >   Version : 0.8.5
>> >   Upstream Author : JASP-team <j...@jasp-stats.org>
>> > * URL : http://www.jasp-stats.org/
>> > * License : GPL
>> >   Programming Lang: C++, R
>> >   Description : Offers standard analysis procedures in both their
>> > classical and Bayesian form
>> >
>> >  JASP is a cross platform statistical software program with a
>> > state-of-the-art
>> >  graphical user interface. It offers standard analysis procedures in
>> both
>> >  their classical and Bayesian form.
>> >  .
>> >  It was designed with the user in mind: APA-formatted tables can be
>> >  copy-pasted in your word processor, output can be extensively
>> annotated,
>> >  adjustment of input options dynamically changes the output, and
>> selecting
>> >  old output revives the associated input choices for inspection and
>> > adjustment.
>> >  .
>> >  JASP is also statistically inclusive,
>> >  as it offers both frequentist and Bayesian analysis methods.
>> >  Indeed, the primary motivation for JASP is to make it easier for
>> > statistical
>> >  practitioners to conduct Bayesian analyses.
>> >  .
>> >  For more information and tutorials see: https://jasp-stats.org/
>> >
>> > 
>> > This package is useful as it allows scientist, especially in the social
>> > sciences, a friendly interface to state-of-the-art statistics techniques
>> > and is under active development.
>> > I plan to maintain as part of my work as one of the upstream-developers
>> and
>> > aim to make it fully debian compatible from the get-go.
>> >
>> > As far as i've understood the information on the debian-wiki we will
>> need a
>> > sponsor to be able to upload to the debian repositories.
>>
>> --
>> http://fam-tille.de
>>
>>

Bug#887598: ITP: jasp -- Offers standard analysis procedures in both their classical and Bayesian form

[jo...@jorisgoosen.nl]

Package: wnpp
Severity: wishlist
Owner: Joris Goosen <jo...@jorisgoosen.nl>
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: jasp
  Version : 0.8.5
  Upstream Author : JASP-team <j...@jasp-stats.org>
* URL : http://www.jasp-stats.org/
* License : GPL
  Programming Lang: C++, R
  Description : Offers standard analysis procedures in both their
classical and Bayesian form

 JASP is a cross platform statistical software program with a
state-of-the-art
 graphical user interface. It offers standard analysis procedures in both
 their classical and Bayesian form.
 .
 It was designed with the user in mind: APA-formatted tables can be
 copy-pasted in your word processor, output can be extensively annotated,
 adjustment of input options dynamically changes the output, and selecting
 old output revives the associated input choices for inspection and
adjustment.
 .
 JASP is also statistically inclusive,
 as it offers both frequentist and Bayesian analysis methods.
 Indeed, the primary motivation for JASP is to make it easier for
statistical
 practitioners to conduct Bayesian analyses.
 .
 For more information and tutorials see: https://jasp-stats.org/


This package is useful as it allows scientist, especially in the social
sciences, a friendly interface to state-of-the-art statistics techniques
and is under active development.
I plan to maintain as part of my work as one of the upstream-developers and
aim to make it fully debian compatible from the get-go.

As far as i've understood the information on the debian-wiki we will need a
sponsor to be able to upload to the debian repositories.

Bug#883724: mono FTBFS on ia64

[Jo Shields]

https://github.com/mono/mono/commit/e5552e6905fb7f3403e1d164e168eb2dc2a561f9

IA64 is dead upstream.


On 06/12/17 15:53, Jason Duerstock wrote:

Package: mono
Severity: normal
Tags: patch

Dear Maintainer,

Mono fails to build from source on ia64.  At least on initial glance, this 
appears to be because it does
not recognize libatomic-ops-dev on the platform.

See attached patch.

-- System Information:
Debian Release: buster/sid
Architecture: ia64

Kernel: Linux 3.14-0.bpo.2-mckinley (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#871831: mono-tools: Depends on libwebkit1.1-cil which is deprecated

[Jo Shields]

Go ahead and NMU.


The problem with libwebkit2gtk-4.0-37 is it's a wrapper for allowing Gtk2 
plugins in a Gtk3 browser - it's not a way for Gtk2 apps to continue to use 
Webkit


Sent from Outlook<http://aka.ms/weboutlook>


From: Jeremy Bicha <jbi...@debian.org>
Sent: 21 September 2017 14:03:17
To: 871...@bugs.debian.org; Jo Shields
Subject: Re: mono-tools: Depends on libwebkit1.1-cil which is deprecated

Just to be clear, monodoc won't run if it's not built against
webkitgtk (or one of a few other dependencies that aren't in Debian
any more) so we should drop the monodoc package too.

Thanks,
Jeremy Bicha

Bug#810145: EXTREMELY PROOF OF CONCEPT OMG

[Jo Shields]

tags 810145 patch

thanks


This works, IME - no more multi-gig Jenkins logs spamming "cannot umount" over 
and over for days



Sent from Outlook<http://aka.ms/weboutlook>
From af8d0bb037a8ffb294a8c8e6ffb031f3e0ded186 Mon Sep 17 00:00:00 2001
From: Jo Shields <joshi...@microsoft.com>
Date: Thu, 25 May 2017 12:37:49 +0100
Subject: [PATCH] Add --killer flag (Closes: #810145)

---
 pbuilder-checkparams | 5 +
 pbuilder-modules | 8 
 pbuilder.8   | 6 ++
 3 files changed, 19 insertions(+)

diff --git a/pbuilder-checkparams b/pbuilder-checkparams
index 84338cd..0565a27 100755
--- a/pbuilder-checkparams
+++ b/pbuilder-checkparams
@@ -32,6 +32,7 @@ CMDLINE="$@"
 INTERNAL_BUILD_UML=""
 TWICE=""
 CHROOTEXEC=""
+KILLER=""
 OVERRIDE_APTLINES="no"
 OVERRIDE_APTLINES_WARN="" # set this if --override-config option should be set.
 BINARY_ARCH="any"  # can be one of 'any', 'all', 'binary'
@@ -332,6 +333,10 @@ while [ -n "$1" ]; do
 TWICE="yes"
 shift;
 ;;
+--killer)
+KILLER="yes"
+shift;
+;;
 --) # end of processing for this
 shift;
 break;
diff --git a/pbuilder-modules b/pbuilder-modules
index fb1fba6..805066b 100644
--- a/pbuilder-modules
+++ b/pbuilder-modules
@@ -81,6 +81,7 @@ pbuilder main options:
  --debug
  --debootstrapopts [debootstrap options]
  --save-after-login/--save-after-exec
+ --killer
 
 pdebuild-specific pbuilder options:
  --auto-debsign
@@ -247,6 +248,13 @@ function umount_one () {
 if [ "$ignore_umount_error" != "yes" ]; then
 log.w "Retrying to unmount $1 in 5s"
 sleep 5s
+if [ "${KILLER}" = "yes" ]; then
+log.w "I AM A KILLER :O"
+for i in $(ls -ld /proc/*/root | grep "${BUILDPLACE}" | awk '{print $9}' | awk 'BEGIN{FS="/";}{print $3}'); do
+log.w "BRUTALLY MURDERING PID $i"
+kill $i
+done
+fi
 while ! umount "$BUILDPLACE/$1"; do
 sleep 5s
 cat <

Bug#863247: java-package: ARM support bitrotted

[Jo Shields]

Package: java-package
Version: 0.62
Severity: important

Dear Maintainer,

ARM support in make-jpkg is busted.

1) soft float is no longer provided (for JDK8) - only hard float, or aarch64

2) Download names are no longer arm-vfp-hflt - they're arm{32,64}-vfp-hflt

3) Hardcoding soft-float dependencies in oracle-jdk.sh is no longer relevant

4) javase.sh doesn't support ARM architectures at all, and makes bad folder
name choices as a result



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-52-generic (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 java-package depends on:
ii  build-essential  12.1ubuntu2
ii  debhelper9.20160115ubuntu3
ii  dpkg-dev 1.18.4ubuntu1.2
ii  fakeroot 1.20.2-1ubuntu1
ii  libasound2   1.1.0-0ubuntu1
ii  libfontconfig1   2.11.94-0ubuntu1.1
ii  libgl1-mesa-glx  12.0.6-0ubuntu0.16.04.1
ii  libgtk2.0-0  2.24.30-1ubuntu1
ii  libx11-6 2:1.6.3-1ubuntu2
ii  libxslt1.1   1.1.28-2.1ubuntu0.1
ii  libxtst6 2:1.2.2-1
ii  libxxf86vm1  1:1.1.4-1
ii  unzip6.0-20ubuntu1

java-package recommends no packages.

Versions of packages java-package suggests:
pn  openjdk-7-jre  

-- no debconf information

Bug#810145: pbuiler: find a way to mount /run/shm even if some other process is accessing it

[Jo Shields]

This is especially painful with the Jenkins Chroot plugin, which uses 
`pbuilder execute` to run things - a stray process from a failed CI test 
leads to gigs of "target is busy" messages in the build logs, which need 
manually killing.


This doesn't seem inordinately difficult to resolve - lsof can filter on 
BUILDPLACE, add a flag to kill stray processes, and just kill all the 
detected processes when that's turned on

Bug#857370: git-buildpackage: No support for dch option --local, -lsuffix

[Jo Shields]

On 13/03/17 17:50, Guido Günther wrote:
> There is -S (bump version) and -R (drop snapshot suffix) and -N (set
> version). For everything else you can still invoke dch directly so I I
> fail to see what _exactly_ you're looking for. gbp-dch doesn't aim to be
> a full dch replacement but a tool to generate changelogs from git
> commits. If you don't like the way the extra version is calculated we
> could make the more configurable than it currently is.


I'm trying to generate useful changelogs for packages on a public repo.

I want the version number to increment with our suffix, following the
behaviour of `dch -l foo`, i.e.:

the top changelog entry is for packagename 1.0-0foo1

I run `gbp dch --some-combination-of-flags`

I now have a changelog entry for packagename 1.0-0foo2

I don't want -0foo1ubun1u, I don't want -1, I don't want
0foo1ubuntu1~1.gbpec359a, I don't want to hand-craft an incremented
version number to pass to -N. I just want -0foo2. As I get from `dch -l foo`

Right now it's looking like the lowest effort (!) option is some shell
scripting to tie together `dch`'s correct version number handling, and
`gbp dch`'s changelog entries.

Bug#806879: xsp: FTBFS when built with dpkg-buildpackage -A (dh_clideps fails)

[Jo Shields]

On 26/03/17 05:18, tony mancill wrote:
> Package: src:xsp
> Followup-For: Bug #806879
> 
> Hi Debian Mono Group,
> 
> The workaround patch works fine.  Is there anything preventing an
> upload?  Would the team be okay with an NMU?

NMU is fine

Sorry, I've been hugely busy & unable to spend much time on Debian stuff



signature.asc
Description: OpenPGP digital signature

Bug#857370: git-buildpackage: No support for dch option --local, -lsuffix

[Jo Shields]

On 12/03/17 11:10, Guido Günther wrote:
> On Fri, Mar 10, 2017 at 03:57:50PM +0000, Jo Shields wrote:
>> Package: git-buildpackage
>> Version: 0.8.13
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> It seems I can't use gbp dch to programatically define the version number 
>> suffix of a build with gbp-dch, but I can with regular dch, via -l.
>>
>> For example, if I have a changelog entry for "foo 1.0-1testing6", I can
>> pass "-l testing" to dch and get "1.0-1testing7" in the changelog, whereas
>> without the -l flag, I get "1.0-1testing6ubuntu1".
>>
>> I tried abusing the snapshot versioning scheme to achieve the same effect,
>> but still ended up needing to post-process the changelog to make it useful.
> 
> The snapthot mechanism (adding ~,gbp) should do that. Can
> you elaborate why you need to postprocess? Maybe making the "gbp" part
> in the version number would help?
> Cheers,

Okay, so some practical examples:

With dch, I can pass "-v 1.1-0foo1" to get that exact version number
embedded in the changelog - no sha1, no ~ modifier, no extra text in the
changelog warning that it's a snapshot. It just uses the version I tell
it to.

Then, later, if I use "-l foo", it increments the version number as
expected, i.e. "1.1-0foo2", "1.1-0foo3" etc, with no calculation needed
on my side.

With gbp-dch I can use -N for the first scenario, but there's no
mechanism to increment that "foo" suffix the way dch's -l flag does

Bug#857370: git-buildpackage: No support for dch option --local, -lsuffix

[Jo Shields]

Package: git-buildpackage
Version: 0.8.13
Severity: wishlist

Dear Maintainer,

It seems I can't use gbp dch to programatically define the version number 
suffix of a build with gbp-dch, but I can with regular dch, via -l.

For example, if I have a changelog entry for "foo 1.0-1testing6", I can
pass "-l testing" to dch and get "1.0-1testing7" in the changelog, whereas
without the -l flag, I get "1.0-1testing6ubuntu1".

I tried abusing the snapshot versioning scheme to achieve the same effect,
but still ended up needing to post-process the changelog to make it useful.

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-66-generic (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 git-buildpackage depends on:
ii  devscripts2.16.2ubuntu3
ii  git   1:2.7.4-0ubuntu1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  20.7.0-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  pbuilder 0.223
ii  pristine-tar 1.33
ii  python-requests  2.9.1-3

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.16-0ubuntu1.3
ii  unzip  6.0-20ubuntu1

-- no debconf information

Bug#808676: [pkg-mono-group] Bug#808676: libgdiplus: Add powerpc architecture

[Jo Shields]

You'll have to smile sweetly at release@ if you want this in testing,
now we're frozen


On 13/02/17 07:17, Mathieu Malaterre wrote:
> user debian-powe...@lists.debian.org
> usertags 808676 powerpc
> thanks
> 
>> libgdiplus is only useful for Mono, and Mono doesn't work at all on
>> 32-bit big-endian PowerPC any more.
> 
> Ping.
> 
> Thanks much
> 
> ___
> pkg-mono-group mailing list
> pkg-mono-gr...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mono-group
> 

Bug#852630: inadyn: --drop-privs option causes inadyn to terminate with exit code 112 (daemon fails)

[Jo Valentine-Cooper]

Package: inadyn
Version: 1.99.4-1
Severity: important


On armel (possibly other archs, but I haven't tested them), the
--drop-privs option for inadyn does not work; it causes inadyn to
terminate with exit code 112:

$ sudo inadyn --config /etc/inadyn.conf --drop-privs
debian-inadyn:debian-inadyn ; echo $?
112

This is a problem because the init script for inadyn makes use of this
option in its DAEMON_ARGS. The practical upshot of this is that inadyn
fails to start at all as a daemon on my armel system unless
/etc/init.d/inadyn is edited to remove that argument.

Hope this helps!



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

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

Versions of packages inadyn depends on:
ii  adduser  3.113+nmu3
ii  libc62.19-18+deb8u7

inadyn recommends no packages.

inadyn suggests no packages.

-- Configuration Files:
/etc/default/inadyn changed:
RUN_DAEMON="yes"
RUN_IPUP="no"
USER="debian-inadyn"
GROUP="debian-inadyn"

/etc/inadyn.conf [Errno 13] Permission denied: u'/etc/inadyn.conf'

-- no debconf information

Bug#851052: abiword: Work area flickers up to 30 thimes on every Charachter input

[jo]

Package: abiword
Version: 3.0.2-2
Severity: important

Dear Maintainer,

After starting, the work area flickers up to 30 times. The flickering repeats 
itself with 
every character input and moust mouse actions. It seems that the upper part of 
the
work area gets redrawn 30 times in about half a minute.

We could verify this behavior on an Intel core duo, an AMD E350 as well as in
a Virtual Box intallation.
I'm using Xfce4

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

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

Versions of packages abiword depends on:
ii  abiword-common  3.0.2-2
ii  gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3
ii  libabiword-3.0  3.0.2-2
ii  libc6   2.24-8
ii  libdbus-1-3 1.10.14-1
ii  libdbus-glib-1-20.108-1
ii  libgcc1 1:6.2.1-5
ii  libgcrypt20 1.7.5-2
ii  libglib2.0-02.50.2-2
ii  libgnutls30 3.5.7-3
ii  libgoffice-0.10-10  0.10.32-1.1
ii  libgsf-1-1141.14.41-1
ii  libgtk-3-0  3.22.5-1
ii  libjpeg62-turbo 1:1.5.1-2
ii  libloudmouth1-0 1.5.3-2
ii  libots0 0.5.0-2.3
ii  libpng16-16 1.6.26-6
ii  librdf0 1.0.17-1.1
ii  libreadline77.0-1
ii  librevenge-0.0-00.0.4-6
ii  libsoup2.4-12.56.0-2
ii  libstdc++6  6.2.1-5
ii  libtelepathy-glib0  0.24.1-1.1
ii  libtidy51:5.2.0-2
ii  libwmf0.2-7 0.2.8.4-10.6
ii  libwpd-0.10-10  0.10.1-5
ii  libwpg-0.3-30.3.1-3
ii  libxml2 2.9.4+dfsg1-2.1
ii  zlib1g  1:1.2.8.dfsg-4

Versions of packages abiword recommends:
ii  abiword-plugin-grammar  3.0.2-2
ii  aspell-de [aspell-dictionary]   20161207-1
ii  aspell-de-1901 [aspell-dictionary]  1:2-31
ii  fonts-liberation1:1.07.4-2
ii  poppler-utils   0.48.0-2

abiword suggests no packages.

-- no debconf information

Bug#845183: mono-gac: missing nunit assemblies prevent installation

[Jo Shields]

On 21/11/16 08:25, Stephen Kitt wrote:
> Package: mono-gac
> Version: 4.6.1.3+dfsg-8
> Severity: normal
> 
> Dear Maintainer,
> 
> This might be a variant of #671607, but just in case: upgrading mono
> failed for me today with
> 
> Setting up mono-gac (4.6.1.3+dfsg-8) ...
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-core2.6.3-cil/policy.2.6.nunit.core.dll
>  does not exist
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-core-interfaces2.6.3-cil/policy.2.6.nunit.core.interfaces.dll
>  does not exist
> ! Assembly 
> /usr/share/cli-common/policies.d/libnunit-framework2.6.3-cil/policy.2.6.nunit.framework.dll
>  does not exist
> 
> There are no nunit files in /usr/share/cli-common/policies.d.
> 
> Installing libnunit-core2.6.3-cil and libnunit-framework2.6.3-cil
> fixes the issue.

I think I know what the bug might be here.
/var/lib/dpkg/info/libnunit-core2.6.3-cil.postrm should be part of
/var/lib/dpkg/info/libnunit-core2.6.3-cil.prerm - as-is, the postrm
*could* get called in an order where /usr/share/cli-common/policy-remove
fails (e.g. when uninstalling all of mono), so the `rm
/usr/share/cli-common/packages.d/$POLICY.installcligac` never gets
called due to the `set -e`

This bug could well be 10 years old. Huh.

Bug#844082: monodoc-base should depend on libmono-corlib4.5-cil

[Jo Shields]

On 12/11/16 10:21, Adrian Bunk wrote:
> Package: monodoc-base
> Version: 4.6.1.3+dfsg-7
> Severity: serious
> 
> $ mdassembler  
> The assembly mscorlib.dll was not found or could not be loaded.
> It should have been installed in the `/usr/lib/mono/4.5/mscorlib.dll' 
> directory.
> $ 
> 
> 
> The libmono-corlib4.5-cil dependency is present in 4.2.1.102+dfsg2-8
> in testing, but missing in 4.6.1.3+dfsg-7 in unstable.

This isn't the first time I've observed something similar, I thought it
was a one-off.

Will investigate.

Bug#840185: mono-complete: Error "Project does not support framework" comes up after creating a new console project

[Jo Shields]

On 09/10/16 12:32, Pr0metheus wrote:
> Package: mono-complete
> Version: 4.6.1.3+dfsg-4
> Severity: important
> 
> Dear Maintainer,
> 
>* What led up to the situation?
> 
> After creating a new console project the program shows a red circle with a
> white cross next to the project name, displays an error message and does not
> allow to build the solution.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
> Open MonoDevelop, create a new solution and pick Console Project (VB.NET)
> Type a name and specify the location and hit Create
> Receive the error message saying:
> 
> Error while trying to load the project '/blah/blah/Test.vbproj": Project does
> not support framework '.NETFramework,Version=v4.5'.
> 
> Next to the project name there is a red circle with a white cross and it is 
> not
> possible to view the project files.
> 
> It is logical cause i have 4.6 and 4.6.1 but if i change it with a text editor
> in the vbproj file, this will not work.
> 
>* What outcome did you expect instead?
> 
> A new, ready to build project.

Fixed upstream in 2521927db594bc4d2814a9fa5391128e048e6a53, consider a
backport

Bug#839753: [pkg-mono-group] Bug#839753: mono-devel: mkbundle generates invalid binaries

[Jo Shields]

On 04/10/16 16:13, Salvo Tomaselli wrote:
> Package: mono-devel
> Version: 4.2.1.102+dfsg2-8
> Severity: normal
> 
> Dear Maintainer,
> 
> I tried creating a simple hello world program in mono
> 
> using System;
> 
> public class HelloWorld
> {
>static public void Main ()
>{
>Console.WriteLine ("Hello world");
>}
> }
> 
> Then compiled it with mcs hello.cs, which produces an executable
> that correctly prints.
> 
> However, when trying to use mkbundle on that executable, the result is always
> something like the one attached.
> 
> I tried with different flags (static, deps) but the result is always the same.
> 
> Also, the manpage talks about a mkbundle2, but there is no such binary
> in debian.

Confirmed

This should be fine in Mono 4.6 (in NEW).


directhex@flame:/tmp$ mkbundle hello.exe
OS is: Linux
Sources: 1 Auto-dependencies: False
   embedding: /tmp/hello.exe
AS = as (default)
[execute cmd]: as -o temp.o temp.s
Compiling:
CC = cc (default)
[execute cmd]: cc -ggdb -o 'a.out' -Wall temp.c `pkg-config --cflags
--libs mono-2`  temp.o
Done
directhex@flame:/tmp$ ./a.out
Hello world

Bug#821831: ca-certificates-mono: unowned files after purge (policy 6.8, 10.8): /etc/mono/certstore/certs/Trust/*.cer and the /etc/mono/certstore/ tree

[Jo Shields]

Mono 4.8 (due early next year) should remove the need for a separate
cert store entirely, so I'm not going to spend much time on this unless
it gets really close to release & is still a problem.

Bug#819402: mono: dllmap for non-linux arches

[Jo Shields]

Can you being this up on an upstream pull request? The change seems sane
in general

Bug#819711: Fails to build mono when PPC_64K_PAGES is set

[Jo Shields]

On 01/10/16 13:50, Mathieu Malaterre wrote:
> I am building also on PowerMac G4 ATM to
> double check any possible regression.

Let me know. I intend to upload 4.6 next week, which already includes
your changes. You might want to try throwing
http://download.mono-project.com/repo/debian/pool/main/m/mono/mono_4.6.1.3-0xamarin1.dsc
at a builder or two, to see if there are any new nasty surprises on PPC

Relatedly, if you know of any way to put powerpc/ppc64/ppc64el into our
upstream CI without paying Softlayer a thousand dollars a month or an
IBM vendor ten thousand up front, it might give us a better early
warning on breakage

Bug#836578: spl-dkms: post_install script cause faults

[Jo Blow]

I also encountered this bug.

I think this might be due to the new behavior in dkms 2.2.1.0 which seems
to remove the build directory.

The postinstall script set in dkms.conf tries to copy files from the build
directory which does not exist.

Changing the phase that the copy occurs in seems to fix it.


--- usr/src/spl-0.6.5.7/dkms.conf   2016-05-25 15:42:03.0 +1000
+++ usr/src/spl-0.6.5.7/dkms.conf.orig  2016-09-09 10:37:43.482388086 +1000
@@ -20,7 +20,7 @@
  esac)
   --with-linux-obj=${kernel_source_dir}
 "
-POST_INSTALL="cp
+POST_BUILD="cp
   ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/spl_config.h
   ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/build/module/Module.symvers
   ${dkms_tree}/${PACKAGE_NAME}/${PACKAGE_VERSION}/${kernelver}/${arch}/

Bug#826103: git-buildpackage: No depends/recommends/suggests on pristine-tar

[Jo Shields]

Package: git-buildpackage
Version: 0.7.2
Severity: normal

Dear Maintainer,

If a user does not have pristine-tar installed, and uses gnp import-orig, 
they get an unhelpful error:

gbp:error: Couldn't commit to 'pristine-tar' with upstream 'upstream-nightly': 
Execution failed: [Errno 2] No such file or directory

If pristine-tar is needed, it ought to be at least a Suggests: if not 
Recommends:


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-22-generic (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 git-buildpackage depends on:
ii  devscripts2.16.2ubuntu3
ii  git   1:2.7.4-0ubuntu1
ii  man-db2.7.5-1
ii  python-dateutil   2.4.2-1
ii  python-pkg-resources  20.7.0-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  pbuilder 0.223
ii  pristine-tar 1.33
ii  python-requests  2.9.1-3

Versions of packages git-buildpackage suggests:
pn  python-notify  
ii  sudo   1.8.16-0ubuntu1.1
ii  unzip  6.0-20ubuntu1

-- no debconf information

Bug#819711: PPC_64K_PAGES (Re: Running Mono on 32bits-big endian PowerPC)

[Jo Shields]

On 11/04/16 09:18, Mathieu Malaterre wrote:
> # set patch tag at least to get some attention, may need some tweaking
> # since pagesize on buildd machine != user installed one
> Control: tags -1 patch
> 
> On Thu, Mar 31, 2016 at 2:37 PM, Mathieu Malaterre  wrote:
>> Dear all,
>>
>> I am currently trying to resurrect Mono debian package on PowerPC (32bits 
>> BE).
>>
>> I have two questions:
>>
>> - Is there a released version I should consider to start with if I
>> want to make mono work son PowerPC again ?
>>
>> - I see some big changes here at:
>> 99902cec93dfbc9e18e3fb6fa07b8770a3bd9adc so I am wondering if version
>> 4.2.1.102 (current debian package) is not a bit too old so get things
>> back in shape.
> 
> Answering my own post.
> 
> So the bug was really within sgen implementation details:
> ARCH_MIN_MS_BLOCK* definitions.
> 
> Within debian infrstratucture, our buildd machines are setup using
> default debian kernel, and the default kernel logical page size was
> changed recently:
> 
> [debian/config/kernelarch-powerpc/config-arch-64: Set PPC_64K_PAGES.]
> https://anonscm.debian.org/cgit/kernel/linux.git/commit/?id=aed63a56b189d771116f2d4b8fe10bbec528e6a2
> 
> The ppc32 buildd machine is setup on a ppc64 kernel. For some obscure
> details (at least to me), one cannot run a debian ppc32 kernel on
> ppc64 arch. Which means that the basic `mono` compiler is compiled
> using ppc32 user space, but at C# compile time is executed on ppc64
> kernel.
> 
> I am guessing another simple patch would be to run the bootstrap
> process with gc=none and keep the default sgen 4K setting for ppc32
> machine.
> 
> It would be nice that mono detect any incoherence at runtime, this
> would make tracking this bug in the future *so* much easier.

Is this patch against 4.2.whateversinsid sufficient to get the build
working fine on the porterbox?

Bug#789771: mono: please add arm64

[Jo Shields]

I've added ARM64 to debian/ for upstream CI packages, but we don't have
any ARM64 hardware hooked up yet (we're in the process of buying some)

Bug#789771: mono: please add arm64

[Jo Shields]

This support is only in git master (and was missing one ftbfs fix commit
when I checked last night).

directhex@asachi:~/mono$ ./mono/mini/mono --version
Mono JIT compiler version 4.5.0 (arm64/5f05c5f Thu Mar 31 16:47:38 UTC 2016)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
www.mono-project.com
TLS:   __thread
SIGSEGV:   normal
Notifications: epoll
Architecture:  arm64
Disabled:  none
Misc:  softdebug
LLVM:  supported, not enabled.
GC:sgen

Bug#813700: ITP: mono-reference-assemblies -- Mono runtime - compiler compatibility for older .NET releases

[Jo Shields]

Package: wnpp
Severity: wishlist
Owner: Jo Shields <direct...@apebox.org>

* Package name: mono-reference-assemblies
  Version : 3.12.1
  Upstream Author : Xamarin Inc
* URL : http://www.mono-project.com/
* License : (Mostly MIT, a few others, see debian/copyright)
  Programming Lang: (C#)
  Description : Mono runtime - compiler compatibility for older .NET 
releases

 Mono is a platform for running and developing applications based on the
 ECMA/ISO Standards. Mono is an open source effort led by Xamarin.
 Mono provides a complete CLR (Common Language Runtime) including compiler and
 runtime, which can produce and execute CIL (Common Intermediate Language)
 bytecode (aka assemblies), and a class library.
 
 These packages contains files required to compile applications against an
 older version of .NET, using Mono 4.0 or above, which only include the latest
 version of the class library as-is. This is important for producing apps for
 wider distribution

 This is essentially a re-upload of an obsolete Mono version, as a new source
 package - the files generated here are bundled as binary blobs in upstream
 Mono releases, and we are simply regenerating them cleanly from source for
 inclusion in the Debian archive - this is similar to libstdc++5/gcc-3.3
 still being in the archive

Bug#811090: [pkg-mono-group] Bug#811090: libgdiplus: cannot install package

[Jo Shields]

On 15/01/16 15:20, Sami Kallio wrote:
> Package: libgdiplus
> Version: 3.12-0xamarin1
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> I tried to install simple drawing program "Pinta", which depends on (among
> others) libgdiplus.
> 
> * What exactly did you do (or not do) that was effective (or ineffective)?
> I typed "sudo aptitude install pinta" to terminal emulator, but aptitude
> refused to install pinta as it
> depends on libgdiplus, which couldn't be installed, because libgdiplus depends
> on libjpeg8 (>= 8c), which  doesn't seem to exist in Debian repositories.
> 
> * What was the outcome of this action?
> Pinta was not installed
> 
> * What outcome did you expect instead?
> That pinta would be installed

apt-cache policy libgdiplus

Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 20:33, Jo Shields wrote:
> 
> 
> On 31/12/15 18:48, Julien Cristau wrote:
>> 3 packages from the mono-tools source break due to a dep on 
>> libmono-cecil-private-cil (<< 3.2.9): gendarme, mono-tools-devel,
>>  mono-tools-gui.  AFAICT that needs a sourceful upload of 
>> mono-tools.
> 
>> I might go ahead and force this in anyway, and fix up the
>> leftover pieces afterwards.
> 
> Break it.
> 
> I need a new upstream tag of mono-tools to fix this (it's not just
> a rebuild of what we have, and I don't see the point in
> backporting dozens of commits against what's in Sid), and the
> upstream release manager for Mono open source stuff is off on
> paternity leave. And his cover for the next month appears to be off
> celebrating new year. Next week, with any luck.

FYI i have just uploaded mono-tools 4.2, which builds fine on Sid.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWiT7CAAoJEMkPnLkOH60MDx0H/ivaWUBjyKWWWMW/q/fO6pen
p9bbLGjXXbu+SDN3na503hvtR8hB8UzLRqcpmO32ngz9CqiUotwuhNXIawM3REOX
HTSOnBmIeRPiE/mAsHoLDjTMCaTFjvxalNjq31Z6Kmst+dTo+r6k8Bjyt1LLUXZI
v/v7NNY6i34BTQr8fIQw6soaDcEEUlFUvjUtR4pNNKqBQmAdB9CQDN0MvA+lCGGp
rbVA3f5n/ByoUPlwy7u01v6yTTr0O5GdzXSJOJZHDzuf5vkdLLSY1Ws9Aho9PeQM
aHWzyQk/0HizedIc5tWaskmh4oRt3MFYf/aEuwhegpvODbrwZs587PYo5M4qYOI=
=F5Ao
-END PGP SIGNATURE-

Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 18:48, Julien Cristau wrote:
> 3 packages from the mono-tools source break due to a dep on 
> libmono-cecil-private-cil (<< 3.2.9): gendarme, mono-tools-devel, 
> mono-tools-gui.  AFAICT that needs a sourceful upload of
> mono-tools.
> 
> I might go ahead and force this in anyway, and fix up the leftover 
> pieces afterwards.

Break it.

I need a new upstream tag of mono-tools to fix this (it's not just a
rebuild of what we have, and I don't see the point in backporting
dozens of commits against what's in Sid), and the upstream release
manager for Mono open source stuff is off on paternity leave. And his
cover for the next month appears to be off celebrating new year. Next
week, with any luck.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWhZErAAoJEMkPnLkOH60MvH0H/3As3e5i+K3sva4dmThxONp5
AdMlNlxvxSSaPdI9MbNLkFDZoxIlA4iFcYYPRxUDawI1ECBluK1gGUCtioGWBFd9
bVxvFku+5kGTa/KhR36Cb/h5LZg8KDCB8kEk1eEhDYfCpeA/98OKPbwElkApwibk
sJz24ETP4pQFkcVL3zwytBD1typ7YZLFPn3wVrocIuMOclBT3id7C7/CC8SL+/cV
fONXZSdd4ABvV7Qp0GH03HGkWdxSXhwE4Yx3rPSwZfIQKUhpJCW7I8c5gR4484iS
rYp8PHk7u7h/tvCsja8iKRtuoZ8zX/+n2BqdNiI0M9RxfDeceLSqEOH9hfbSgmY=
=kakV
-END PGP SIGNATURE-

Bug#796345: [pkg-mono-group] Bug#796345: Status report on perl 5.22 transition readiness (30th Sept)

[Jo Shields]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 31/12/15 18:48, Julien Cristau wrote:
> On the mono side I end up with remove
> nrefactory/5.3.0+20130718.73b6d0f-2
> mono-debugger-libs/0+20131201.3459502-1 sdb/1.2-1

Just pushed a fix for this to Sid
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWhY6vAAoJEMkPnLkOH60MBIkIAL3c0ywig1INqGbrPmNUNMjE
yRp2Ky8KUuoFHvpjCEwkmAK88sYt7CpN5ZEaChPQSrP+lihUTMzE1oU7cesBCEdU
XebZ0VBAVdO8K/t5G1nSbcNOQV7vkg3TMmYWFukh96Ob30URE7qACSU6EyKw6h1w
cE2UW/Q3zAzCCTAjcVcHL9UlBJGi0Xy2whNXqv2+FMMaOKbBQN0+p/GM6aGYXFC7
l/zsLJZBaVTJJkX96Yeg3BbY71v9m9ujCRCnY6I8Pqqba219x4GzLSzuOb5t7JNA
Kws3/GshLccQr2Lh3oJ8X7ObPfSUlnn1SEfMKy13wohb9lH//kHUGPTfiUVPhF0=
=TlOr
-END PGP SIGNATURE-

Bug#808502: cairo-dock-dbus-plug-in-interface-mono: Please refresh list of architectures for Mono in Unstable

[Jo Shields]

Source: cairo-dock-plug-ins
Version: 3.4.0-1.3
Followup-For: Bug #808502

Dear Maintainer,

Apologies, my fix in 3.4.0-1.3 was incomplete. Attached going to DELAYED/5.

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-22-generic (SMP w/12 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)
diff -Nru cairo-dock-plug-ins-3.4.0/debian/changelog cairo-dock-plug-ins-3.4.0/debian/changelog
--- cairo-dock-plug-ins-3.4.0/debian/changelog	2015-12-21 09:51:42.0 +
+++ cairo-dock-plug-ins-3.4.0/debian/changelog	2015-12-22 18:13:54.0 +
@@ -1,3 +1,12 @@
+cairo-dock-plug-ins (3.4.0-1.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * The architectures list is in two places? Of course it is. Make the
+rule conditional upon the existence of a file only installed if
+on a Mono platform, so it only needs maintaining in one place.
+
+ -- Jo Shields <direct...@apebox.org>  Tue, 22 Dec 2015 18:12:32 +
+
 cairo-dock-plug-ins (3.4.0-1.3) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cairo-dock-plug-ins-3.4.0/debian/rules cairo-dock-plug-ins-3.4.0/debian/rules
--- cairo-dock-plug-ins-3.4.0/debian/rules	2014-10-23 06:26:55.0 +0100
+++ cairo-dock-plug-ins-3.4.0/debian/rules	2015-12-22 18:12:22.0 +
@@ -17,11 +17,8 @@
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/cmake.mk
 
-CLI_ARCH=zamd64z zarmelz zi386z zkfreebsd-i386z \
-		 zkfreebsd-amd64z zpowerpcz zs390xz
-
 common-binary-predeb-arch::
-ifneq (,$(findstring z$(DEB_HOST_ARCH)z, $(CLI_ARCH)))
-	dh_clifixperms
-	dh_clideps -d
-endif
+	if [ -e /usr/share/mono/mono-archs.make ] ; then \
+		dh_clifixperms ; \
+		dh_clideps -d ; \
+	fi

Bug#808676: [pkg-mono-group] Bug#808676: libgdiplus: Add powerpc architecture

[Jo Shields]

On 21/12/15 18:41, Michael Terry wrote:
> Package: libgdiplus
> Version: 4.2-1
> Severity: normal
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu xenial ubuntu-patch
> 
> Dear Maintainer,
> 
> In Ubuntu, the attached patch was applied to add powerpc back to the
> architecture list.  It was dropped in 4.2-1.  But it compiles fine in Ubuntu.
> Was there a reason for it being dropped?

libgdiplus is only useful for Mono, and Mono doesn't work at all on
32-bit big-endian PowerPC any more.

If you can get the package in Debian building on powerpc again, then
I'll gladly re-add it.

Bug#808481: Acknowledgement (kamailio-mono-modules: Please refresh list of architectures to reflect current Mono)

[Jo Shields]

Uploaded to DELAYED/5, to fix release-critical bug
diff -Nru kamailio-4.3.4/debian/changelog kamailio-4.3.4/debian/changelog
--- kamailio-4.3.4/debian/changelog 2015-11-26 21:08:45.0 +
+++ kamailio-4.3.4/debian/changelog 2015-12-21 10:15:06.0 +
@@ -1,3 +1,10 @@
+kamailio (4.3.4-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Refresh list of architectures supported by Mono (Closes: #808481)
+
+ -- Jo Shields <direct...@apebox.org>  Mon, 21 Dec 2015 10:14:23 +
+
 kamailio (4.3.4-1) unstable; urgency=medium
 
   * [3ca01af] Imported Upstream version 4.3.4 ( Closes: #806244 )
diff -Nru kamailio-4.3.4/debian/control kamailio-4.3.4/debian/control
--- kamailio-4.3.4/debian/control   2015-11-26 21:08:45.0 +
+++ kamailio-4.3.4/debian/control   2015-12-21 10:07:37.0 +
@@ -26,7 +26,7 @@
libldap2-dev,
liblua5.1-0-dev,
libmemcached-dev,
-   libmono-2.0-dev [!ia64 !mips],
+   libmono-2.0-dev [amd64 armel armhf i386 mipsel kfreebsd-amd64 
kfreebsd-i386 powerpc ppc64 ppc64el s390x],
libmysqlclient-dev,
libncurses5-dev,
libpcre3-dev,
diff -Nru kamailio-4.3.4/debian/rules kamailio-4.3.4/debian/rules
--- kamailio-4.3.4/debian/rules 2015-11-26 21:08:45.0 +
+++ kamailio-4.3.4/debian/rules 2015-12-21 10:14:17.0 +
@@ -46,16 +46,12 @@
 # module groups to be packaged onto kamailio-extra-modules
 EXTRA_GROUPS=gzcompress uuid ev jansson
 
-# mono not on ia64 or sparc
-ifeq ($(DEB_HOST_ARCH),ia64)
-   override EXCLUDED_MODULES += mono
-else ifeq ($(DEB_HOST_ARCH),sparc)
-   override EXCLUDED_MODULES += mono
-else ifeq ($(DEB_HOST_ARCH),mips)
-override EXCLUDED_MODULES += mono
+# mono not on all arches
+ifneq ("$(wildcard /usr/share/mono/mono-archs.make)","")
+override PACKAGE_GROUPS+= mono
 else
-   override PACKAGE_GROUPS+= mono
-endif
+override EXCLUDED_MODULES += mono
+endif  
 
 # FTBFS on powerpcspe because of AltiVec assumption #729635
 ifeq ($(DEB_HOST_ARCH),powerpcspe)

Bug#808502: Acknowledgement (cairo-dock-dbus-plug-in-interface-mono: Please refresh list of architectures for Mono in Unstable)

[Jo Shields]

Uploading to DELAYED/5 as attached (also fixes a FTBFS)
diff -Nru cairo-dock-plug-ins-3.4.0/debian/changelog 
cairo-dock-plug-ins-3.4.0/debian/changelog
--- cairo-dock-plug-ins-3.4.0/debian/changelog  2015-11-18 12:52:05.0 
+
+++ cairo-dock-plug-ins-3.4.0/debian/changelog  2015-12-21 09:33:30.0 
+
@@ -1,3 +1,13 @@
+cairo-dock-plug-ins (3.4.0-1.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/use_correct_csharp_compiler.patch:
+Debian now has Mono 4.0+, which means "gmcs" no longer exists
+  * debian/control: Updated list of architectures supported by Mono (Closes:
+#808502)
+
+ -- Jo Shields <direct...@apebox.org>  Mon, 21 Dec 2015 09:32:11 +
+
 cairo-dock-plug-ins (3.4.0-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cairo-dock-plug-ins-3.4.0/debian/control 
cairo-dock-plug-ins-3.4.0/debian/control
--- cairo-dock-plug-ins-3.4.0/debian/control2015-11-18 12:51:40.0 
+
+++ cairo-dock-plug-ins-3.4.0/debian/control2015-12-21 09:27:31.0 
+
@@ -6,7 +6,7 @@
  Youhei SASAKI <uwab...@gfd-dennou.org>
 Build-Depends: cdbs, debhelper (>= 7), cmake(>= 2.8.0), dpkg-dev (>= 1.16.1~),
  cairo-dock-dev (>= 3.4.0),
- cli-common-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
+ cli-common-dev [amd64 armel armhf i386 mipsel kfreebsd-any ppc64 ppc64el 
s390x],
  libasound2-dev [linux-any],
  libcairo2-dev (>= 1.8.0),
  libcurl4-gnutls-dev,
@@ -16,7 +16,7 @@
  libetpan-dev,
  libexif-dev,
  libgl1-mesa-dev | libgl-dev,
- libglib2.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
+ libglib2.0-cil-dev [amd64 armel armhf i386 mipsel kfreebsd-any ppc64 ppc64el 
s390x],
  libglib2.0-dev,
  libglu1-mesa-dev | libglu-dev,
  libgnome-menu-3-dev,
@@ -25,8 +25,8 @@
  libical-dev,
  libido3-0.1-dev,
  libindicator3-dev,
- libdbus-glib2.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
- libdbus2.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
+ libdbus-glib2.0-cil-dev [amd64 armel armhf i386 mipsel kfreebsd-any ppc64 
ppc64el s390x],
+ libdbus2.0-cil-dev [amd64 armel armhf i386 mipsel kfreebsd-any ppc64 ppc64el 
s390x],
  libpango1.0-dev,
  libpulse-dev,
  librsvg2-dev,
@@ -39,8 +39,7 @@
  libxtst-dev,
  libxxf86vm-dev,
  libzeitgeist-2.0-dev,
- mono-devel [amd64 armel i386 kfreebsd-any powerpc s390x],
- mono-gmcs [amd64 armel i386 kfreebsd-any powerpc s390x],
+ mono-devel [amd64 armel armhf i386 mipsel kfreebsd-any ppc64 ppc64el s390x],
  python,
  python3,
  ruby,
@@ -210,7 +209,7 @@
  This package provides library of Cairo-Dock D-Bus interface for ruby.
 
 Package: cairo-dock-dbus-plug-in-interface-mono
-Architecture: amd64 armel i386 kfreebsd-any powerpc s390x
+Architecture: amd64 armel armhf i386 mipsel kfreebsd-any ppc64 ppc64el s390x
 Depends: cairo-dock-plug-ins (>= ${source:Version}), ${misc:Depends}, 
${cli:Depends}
 Description: library of D-Bus interface for mono of Cairo-dock
  A collection of official plug-ins and applets for cairo-dock.
diff -Nru cairo-dock-plug-ins-3.4.0/debian/patches/series 
cairo-dock-plug-ins-3.4.0/debian/patches/series
--- cairo-dock-plug-ins-3.4.0/debian/patches/series 2015-11-18 
12:49:25.0 +
+++ cairo-dock-plug-ins-3.4.0/debian/patches/series 2015-12-21 
09:29:21.0 +
@@ -3,3 +3,4 @@
 ruby-vendor-dir.patch
 0004-Add-CMake-check-for-vte-2.91-and-fix-VTE_CHECK_VERSI.patch
 0005-Use-dbus-sharp-not-unmaintained-NDesk.patch
+use_correct_csharp_compiler.patch
diff -Nru 
cairo-dock-plug-ins-3.4.0/debian/patches/use_correct_csharp_compiler.patch 
cairo-dock-plug-ins-3.4.0/debian/patches/use_correct_csharp_compiler.patch
--- cairo-dock-plug-ins-3.4.0/debian/patches/use_correct_csharp_compiler.patch  
1970-01-01 01:00:00.0 +0100
+++ cairo-dock-plug-ins-3.4.0/debian/patches/use_correct_csharp_compiler.patch  
2015-12-21 09:29:44.0 +
@@ -0,0 +1,16 @@
+Index: cairo-dock-plug-ins-3.4.0/CMakeLists.txt
+===
+--- cairo-dock-plug-ins-3.4.0.orig/CMakeLists.txt
 cairo-dock-plug-ins-3.4.0/CMakeLists.txt
+@@ -565,9 +565,9 @@ enable_if_not_defined (enable-mono-inter
+ if (enable-mono-interface)
+   message (STATUS " * Mono:")
+   #find_package (Mono)
+-  find_program (GMCS_EXECUTABLE gmcs)
++  find_program (GMCS_EXECUTABLE mcs)
+   if (NOT GMCS_EXECUTABLE OR NOT EXISTS ${GMCS_EXECUTABLE})
+-  message (STATUS "Could not find Mono compiler gmcs, won't build 
Mono interface.")
++  message (STATUS "Could not find Mono compiler mcs, won't build 
Mono interface.")
+   else()
+   pkg_check_modules (MONO_PACKAGE glib-sharp-2.0 dbus-sharp-2.0 
dbus-sharp-glib-2.0)
+   if (NOT MONO_PACKAGE_FOUND)

Bug#808475: src:gdcm: Please refresh architectures relating to Mono (powerpc out, ppc64el in)

[Jo Shields]

Package: src:gdcm
Version: 2.6.1-1
Severity: important

Dear Maintainer,

gdcm is a package which produces both Mono and non-Mono binaries, via 
architecture-conditional build-deps in debian/control. This list comes
from /usr/share/mono/mono-archs.make.

The latest Mono package in Debian Unstable has removed support for
big-endian 32-bit PowerPC, and added it for little-endian 64-bit PowerPC.

Please refresh your debian/control and reupload - this is blocking transition
of the new Mono to testing.

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808481: kamailio-mono-modules: Please refresh list of architectures to reflect current Mono

[Jo Shields]

Package: kamailio-mono-modules
Version: 4.3.4-1
Severity: important

Dear Maintainer,

Your package builds both on Mono and non-Mono architectures, via conditional
build-dependencies in debian/control. The list of architectures being built
on/for does not reflect the current Mono package in Debian Unstable, which is
blocking its transition to Debian Testing.

Please update the dependencies of kamailio-mono-modules (and 
build-dependencies of src:kamailio) to reflect this. A current list can be
found in /usr/share/mono/mono-archs.make

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808502: cairo-dock-dbus-plug-in-interface-mono: Please refresh list of architectures for Mono in Unstable

[Jo Shields]

Package: cairo-dock-dbus-plug-in-interface-mono
Version: 3.4.0-1.2
Severity: important

Dear Maintainer,

cairo-dock-plug-ins builds both Mono and non-Mono packages from the same
source package, via conditional entries in debian/control.

Please update the list of achitectures to reflect currently supported
architectures in Debian Unstable. As-is, you are blocking a transition to
Testing. A current list is at /usr/share/mono/mono-archs.make

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808477: src:libsbml: Please follow Debian CLI library packaging guidelines (missing dependencies)

[Jo Shields]

Package: src:libsbml
Version: 5.10.0+dfsg-1
Severity: normal

Dear Maintainer,

libsbml5-cil does not have any valid dependencies, because it is not correctly
setting them. Please see:

http://pkg-mono.alioth.debian.org/cli-policy/ch-appendix.html#s-dh_clideps

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808500: gnome-todo: Please fix faulty dependency on libgio3.0-cil-dev

[Jo Shields]

Package: gnome-todo
Version: 3.18.1-1
Severity: important

Dear Maintainer,

It appears your package build-depends on libgio3.0-cil-dev even though it is
not in any way CLI-related or written in C#

Judging by configure.ac, maybe you meant libglib2.0-dev? That's the package
containing gio-2.0.pc.

This issue is blocking a transition of Mono from Unstable to Testing.

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808507: uwsgi-plugin-mono: Please refresh architectures list for current Mono in Unstable

[Jo Shields]

Package: uwsgi-plugin-mono
Version: 2.0.11.2-5
Severity: serious

Dear Maintainer,

Your package produces both Mono and non-Mono packages, via conditional
build-dependencies in debian/control. Please update this list to reflect
the currently supported architectures in Mono in Unstable. As-is, you
are blocking transition to Testing.

A current list can be found at /usr/share/mono/mono-archs.make

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808497: libgpod-cil: Please refresh list of architectures for current Mono

[Jo Shields]

Package: libgpod-cil
Version: 0.8.3-1.1
Severity: important

Dear Maintainer,

This source package builds both Mono and non-Mono packages, via conditional
build-dependencies in debian/control. This list does not reflect the currently
supported architectures for Mono in Debian Unstable, which is blocking
transition to Debian Testing.

A current list can be found in /usr/share/mono/mono-archs.make

-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#808477: src:libsbml: Please follow Debian CLI library packaging guidelines (missing dependencies)

[Jo Shields]

On 20/12/15 16:40, Andreas Tille wrote:
> +include /usr/share/cli-common/cli.make
> +
>  ### let's do it ###
>  
>  DEB_COMPRESS_EXCLUDE = .pdf
> 
> 
> which leads to
> 
> 
> dh_makeshlibs: warning: ignored unknown options in DH_OPTIONS
>dh_shlibdeps -O--with-python2 -O--dbg-package=libsbml5-dbg
> Unknown option: with

We're fixing the documentation for dh7 (which changed its format for
external sequences a while back - sorry!) - rather than the include at
the top, you should use "dh --with cli"

`--with` takes a comma-separated list of debhelper sequences found in
/usr/share/perl5/Debian/Debhelper/Sequence/ (i.e. you probably want
`--with cli,python2` instead of `--with-python2`)


> dh_clideps: Error: Could not resolve moduleref: libsbmlcs for: libsbmlcsP.dll!
> dh_clideps: Error: unresolvable module references or missing shlibs entries, 
> please check above errors!

This means libsbmlcsP.dll includes a link to an external non-.NET
library called "libsbmlcs", but can't find a file with this name in the
same directory, or in a directory served up by ld.so

The easiest fix IMHO would be to include a file libsbmlcsP.dll.config in
your debian/ which gets installed next to libsbmlcsP.dll:


  


If you have any GUI apps installed, take a look at
/usr/lib/cli/gtk-sharp-2.0/gtk-sharp.dll.config as a real-world example

Alternative solutions include patching your source to change every
`DllImport("libsbmlcs")` to `DllImport("libsbmlcs.so")`, or adding an
override_dh_clideps rule to debian/rules if you want to handle the
dependency by hand:

override_dh_clideps:
dh_clideps --exclude-moduleref=libsbmlcs

Bug#808477: src:libsbml: Please follow Debian CLI library packaging guidelines (missing dependencies)

[Jo Shields]

On 20/12/15 18:58, Andreas Tille wrote:
> I tried this and commited it to
> 
>ssh://git.debian.org/git/debian-med/libsbml.git
> 
> Unfortunately this ends up in
> 
> ...
>dh_clideps -O--dbg-package=libsbml5-dbg
> dh_clideps: Error: Could not resolve moduleref: libsbmlcs for: libsbmlcsP.dll!
> dh_clideps: Error: unresolvable module references or missing shlibs entries, 
> please check above errors!
> debian/rules:39: recipe for target 'binary' failed
> make: *** [binary] Error 2
> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 
> 2
> 
> 
> I'd be happy if you could provide (or directly commit since any DD has
> commit permissions) another helpful patch.

Pushed. Seems to build okay. That's not a fast or lightweight build, is it?

 Depends: libbz2-1.0, libc6 (>= 2.14), libgcc1 (>= 1:3.0), libstdc++6
(>= 5.2), libxml2 (>= 2.7.4), zlib1g (>= 1:1.1.4), libmono-corlib4.5-cil
(>= 4.2.0), libsbml5-dev

Bug#808252: RM: xsp -- NBS; .NET 2.0 packages no longer produced

[Jo Shields]

Package: ftp.debian.org
Severity: normal


Please remove from unstable:

mono-xsp2-base (3.8-2.1)
mono-apache-server2 (3.8-2.1)
mono-fastcgi-server2 (3.8-2.1)
mono-xsp2 (3.8-2.1)

Please do not remove any 4.2-2 packages, which are correct.

Bug#807688: RM: mono [powerpc] -- ANAIS; Architecture no longer well-maintained, FTBFS

[Jo Shields]

Package: ftp.debian.org
Severity: normal

Sadly I was unable to resolve outstanding issues with PowerPC 32-bit 
big-endian on Mono. It's time to get rid of this arch from this package.

PPC64el has some proper support, including upstream CI.

Bug#798280: transition: mono

[Jo Shields]

On 09/12/15 19:21, Emilio Pozuelo Monfort wrote:
> Hey Jo,
> 
> On 02/12/15 16:21, Jo Shields wrote:
>> Related note: I've uploaded a fixed version of src:fsharp to Experimental, so
>> all the issues reported on 
>> https://release.debian.org/transitions/html/mono.html
>> are accounted for, in bugs which are all on the FTP team (including the minor
>> ABI bump in an F# library, making it binary NEW).
> 
> What is the plan for opentk and fsgateway?

opentk is suffering from some archive cruft issues, I think -
https://packages.debian.org/sid/libopentk1.1-cil seems fine to me, but
the old ABI https://packages.debian.org/sid/libopentk1.0-cil package is
still showing up in a few places. I was leaving it a day or two to see
if some cron job fixed it up.

fsgateway is blocking on
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803057 (Mono removes
its bundled antique version of the PostgreSQL .NET client in 4.0, so
I've had to introduce a standalone PostgreSQL .NET client package)

Bug#798280: transition: mono

[Jo Shields]

On 09/12/15 19:51, Adam D. Barratt wrote:
> On Wed, 2015-12-09 at 19:27 +0000, Jo Shields wrote:
>> opentk is suffering from some archive cruft issues, I think -
>> https://packages.debian.org/sid/libopentk1.1-cil seems fine to me, but
>> the old ABI https://packages.debian.org/sid/libopentk1.0-cil package is
>> still showing up in a few places. I was leaving it a day or two to see
>> if some cron job fixed it up.
> 
> The cruft report says:
> 
> * package libopentk1.0-cil in version 1.0.20101006+dfsg1-1 is no longer built 
> from source
>   - suggested command:
> dak rm -m "[auto-cruft] no longer built from source" -s unstable -a all 
> -p -R -b libopentk1.0-cil
>   - broken Depends:
> monogame: libmonogame-cil
> 
> So either monogame needs to be updated (or removed from unstable) or
> ftp-master need to be asked for a manual decruft which explicitly breaks
> monogame.

Okay, looking at 765120, I think the manual decruft (and forcibly
broken) monogame is best for now. I intend to fix it, but I don't think
I can realistically do that without it causing serious delays to this
transition (and the required update to MonoDevelop is a big job).

File a bug against ftp.d.o?

Bug#806890: libnunit-framework2.6.3-cil: The GAC reference version breaks compatibility with Windows.

[Jo Shields]

On Wed, 02 Dec 2015 10:05:45 -0500 Chris Capon  wrote:
> When the major/minor version numbers are the same, the Debian GAC 
reference
> MUST match the one released by NUnit.org or you break software 
compatibility

> across systems.

We're not touching this. The version number is defined in the source 
code, and does not include a revision. See 
https://github.com/nunit/nunitv2/blob/master/src/CommonAssemblyInfo.cs


This sounds more like an error upstream - for some reason, they're not 
building from the same source code they're distributing.

Bug#806896: libnunit-framework2.6.3-cil: Please provide previous versions of the framework as well as current.

[Jo Shields]

On Wed, 02 Dec 2015 10:45:14 -0500 Chris Capon  wrote:
> Package: libnunit-framework2.6.3-cil
> Version: 2.6.3+dfsg-1
> Severity: wishlist
>
> Dear Maintainer,
>
> When a .NET project that references the nunit.framework is compiled, the
> specific version number, culture and public key token are built in to the
> application.
>
> If that specific version is not found in the GAC when the application 
is run,

> it will fail.
>
> When considering source code portability between systems, projects that
> reference specific versions of the nunit.framework can also not be 
compiled if

> that version is not found.
>
> Under Windows, it is possible to have many different versions of NUnit
> installed concurrently in the GAC by installing from the many packages
> available on NUnit.org download site.
>
> With Debian (Testing), only the latest version is provided (currently 
2.6.3).
> This places a requirement on all .NET applications to be compiled 
with the same
> nunit.framework reference. In addition, that reference must be 
updated with

> each major release of the framework.
>
> Since different applications may reference different versions of the
> nunit.framework, it should be possible to install multiple versions 
of the

> nunit.framework.
>
> Would it be possible to provide an installation package for each of the
> historical versions of the NUnit framework in addition to the most 
current?

> This way package references do not need to be changed unnecessarily.
>
> It is also significant that these historical versions must all register
> references in the GAC which are compatible with their matching 
releases on

> NUnit.org.

This is actually a huge amount of work. In the general case, I'd suggest 
using NuGet for including NUnit in your own projects, rather than 
relying on what's in the distribution - we cannot rely on internet 
connectivity when building packages, so need to have packages, but we 
try to avoid packaging libraries we don't use in applications, and 
multiple parallel versions of NUnit would certainly come under that heading.

Bug#806979: mono-apache-server4: Adding sites using mono-server4-admin does not set required permissions.

[Jo Shields]

On 03/12/15 17:40, Chris Capon wrote:

A simple fix for mono-server4-update would be to add:

 print TEMPHOST "Require all granted";

to the end of  sub write_tempxsphostfile {

but I'm not sure if more advanced permission management wouldn't be better.


It would be better... but for now, your workaround is awesome. I'll get 
that added & uploaded along with pending translation updates, in about a 
week.

Bug#798280: transition: mono

[Jo Shields]

On 01/12/15 23:44, Emilio Pozuelo Monfort wrote:

On 30/11/15 20:35, Jo Shields wrote:


On 30/11/15 18:56, Emilio Pozuelo Monfort wrote:

On 27/11/15 17:54, Jo Shields wrote:

I think this is close to startable, if a transition slot will be available soon.

Of the 17 "bad" packages on the release tracker, 2 FTBFS for other reasons (and
are removed from Testing anyway). 3 are in DELAYED and should land this weekend.
2 are waiting on another DELAYED upload to land this weekend, which should make
them RMable. 1 is in binary NEW, 2 are blocking on a package in NEW. The rest
already have RM bugs against ftp.debian.org.

Can you make those bugs block this?

Assuming I didn't fuck it up, done.


In terms of *actual* work remaining, fsharp needs a new upstream release
uploading (which is only awkward due to the need to +dfsg it), and xsp needs
some upstream work to tag/ship a compatible version (i.e. remove the attempt to
build the old ABI entirely), both of which I can deal with on Monday.

Good.

I've uploaded a compatible transition-friendly release of xsp to
experimental, it seems to be doing okay on buildd.debian.org


The only slight wrinkle in the transition is the removal of powerpc as an
architecture, requiring some massaging of the archive before transitioning would
be possible.

It'd be good to get that done before the transition starts. Can you ask the ftp
team to do that?

Can I do that without doing a sourceful upload with powerpc removed from
the arch list? It was my understanding that the package would end up
getting rebuilt on that arch

Yes, but the current version would FTBFS anyway, right?


Not until I upload the version in Experimental to Sid.


Anyway it's not such a big deal. That can happen once the new version has been
uploaded.


Related note: I've uploaded a fixed version of src:fsharp to 
Experimental, so all the issues reported on 
https://release.debian.org/transitions/html/mono.html are accounted for, 
in bugs which are all on the FTP team (including the minor ABI bump in 
an F# library, making it binary NEW).


It's possible (actually pretty probable) that monodevelop from sid will 
FTBFS after the transition, so I'll look at that, but in the general 
case, I think that's every box on the transition tracker dealt with or 
assigned.

Bug#798280: transition: mono

[Jo Shields]

On 30/11/15 18:56, Emilio Pozuelo Monfort wrote:
> On 27/11/15 17:54, Jo Shields wrote:
>> I think this is close to startable, if a transition slot will be available 
>> soon.
>>
>> Of the 17 "bad" packages on the release tracker, 2 FTBFS for other reasons 
>> (and
>> are removed from Testing anyway). 3 are in DELAYED and should land this 
>> weekend.
>> 2 are waiting on another DELAYED upload to land this weekend, which should 
>> make
>> them RMable. 1 is in binary NEW, 2 are blocking on a package in NEW. The rest
>> already have RM bugs against ftp.debian.org.
> 
> Can you make those bugs block this?

Assuming I didn't fuck it up, done.

>> In terms of *actual* work remaining, fsharp needs a new upstream release
>> uploading (which is only awkward due to the need to +dfsg it), and xsp needs
>> some upstream work to tag/ship a compatible version (i.e. remove the attempt 
>> to
>> build the old ABI entirely), both of which I can deal with on Monday.
> 
> Good.

I've uploaded a compatible transition-friendly release of xsp to
experimental, it seems to be doing okay on buildd.debian.org

>> The only slight wrinkle in the transition is the removal of powerpc as an
>> architecture, requiring some massaging of the archive before transitioning 
>> would
>> be possible.
> 
> It'd be good to get that done before the transition starts. Can you ask the 
> ftp
> team to do that?

Can I do that without doing a sourceful upload with powerpc removed from
the arch list? It was my understanding that the package would end up
getting rebuilt on that arch

Bug#806548: RM: ndesk-dbus-glib -- ROM; Unmaintained & deprecated

[Jo Shields]

Package: ftp.debian.org
Severity: normal

Please remove this package from the archive, it's unneeded and defiitely 
unwanted.

The last build-dep should be gone, with cairo-dock-plug-ins 3.4.0-1.2

Bug#806549: RM: ndesk-dbus -- ROM; Unmaintained & unneeded

[Jo Shields]

Package: ftp.debian.org
Severity: normal

This is dead upstream, and should no longer be needed as of cairo-dock-plug-ins 
3.4.0-1.2

Bug#798280: transition: mono

[Jo Shields]

On Wed, 30 Sep 2015 01:03:23 +0200 Emilio Pozuelo Monfort 
<po...@debian.org> wrote:

> On 07/09/15 18:28, Jo Shields wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Mono requires a (hopefully minor) transition, when the pending 
version in
> > Experimental uploads to Unstable. The ABI on the core library was 
bumped back
> > with Mono 3.0.6+dfsg2-1 in 2012 and the old one deprecated - now 
the old

> > version has been removed too.
> >
> > More than half the existing archive packages are already 
post-transition (any

> > that were built with Mono 3.0.6+dfsg2-1 or later, in theory).
> >
> > The pending upload is important because it fixes GCC5 FTBFS, and 
compiler

> > reproducible output support.
> >
> > I am aware of the PowerPC build failure on the package in 
Experimental, I
> > wouldn't look to do the upload before that is fixed (but would like 
to get the
> > Ben tracker in place so I can track both issues in parallel). The 
PPC build
> > failures are Debian buildd/porterbox-specific - they don't 
reproduce locally,

> > which makes it very awkward to repro/fix.
>
> OK, please ping us when you're ready for an upload.

I think this is close to startable, if a transition slot will be 
available soon.


Of the 17 "bad" packages on the release tracker, 2 FTBFS for other 
reasons (and are removed from Testing anyway). 3 are in DELAYED and 
should land this weekend. 2 are waiting on another DELAYED upload to 
land this weekend, which should make them RMable. 1 is in binary NEW, 2 
are blocking on a package in NEW. The rest already have RM bugs against 
ftp.debian.org.


In terms of *actual* work remaining, fsharp needs a new upstream release 
uploading (which is only awkward due to the need to +dfsg it), and xsp 
needs some upstream work to tag/ship a compatible version (i.e. remove 
the attempt to build the old ABI entirely), both of which I can deal 
with on Monday.


The only slight wrinkle in the transition is the removal of powerpc as 
an architecture, requiring some massaging of the archive before 
transitioning would be possible.

Bug#806212: monodevelop: Program will not start

[Jo Shields]

It's unrelated. MD needs a version update to work properly with Mono 4.0 
(and 4.2). Generally, MonoDevelop releases happen in sync with Mono, and 
they should be upgraded in lockstep (MD 5.10 for Mono 4.2).


I haven't yet done it for MonoDevelop, as there's a bunch of peripheral 
work that needs doing, which is not so easy to resolve. But I should get 
it sorted in the not too distant future.

Bug#804660: NMU

[Jo Shields]

I have prepared an NMU for this fix (attached), and uploaded to DELAYED/10
diff -u coco-cs-20110419/debian/changelog coco-cs-20110419/debian/changelog
--- coco-cs-20110419/debian/changelog
+++ coco-cs-20110419/debian/changelog
@@ -1,3 +1,10 @@
+coco-cs (20110419-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for CLR 4.5 transition (Closes: #804660)
+
+ -- Jo Shields <direct...@apebox.org>  Wed, 18 Nov 2015 12:32:33 +
+
 coco-cs (20110419-5) unstable; urgency=low
 
   * Switched to CLR 4.0 (Closes: #656690)

Bug#805461: libavahi1.0-cil: Rebuild required for Mono transition

[Jo Shields]

Package: libavahi1.0-cil
Version: 0.6.19-4.2
Severity: important

Dear Maintainer,

As part of the mono transition, a rebuild of avahi-sharp is required.



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#805461: NMU

[Jo Shields]

I have prepared an NMU for this issue, and uploaded it to DELAYED/10

Attached is the difference from the previous upload.
diff -u avahi-sharp-0.6.19/debian/changelog avahi-sharp-0.6.19/debian/changelog
--- avahi-sharp-0.6.19/debian/changelog
+++ avahi-sharp-0.6.19/debian/changelog
@@ -1,3 +1,9 @@
+avahi-sharp (0.6.19-4.3) unstable; urgency=medium
+
+  * Rebuild for CLR 4.5 transition (Closes: #805461)
+
+ -- Jo Shields <direct...@apebox.org>  Wed, 18 Nov 2015 11:56:22 +
+
 avahi-sharp (0.6.19-4.2) unstable; urgency=low
 
   * Non-maintainer upload.

Bug#805464: libkarma-cil: Requires rebuild for CLR 4.5 transition

[Jo Shields]

Package: libkarma-cil
Version: 0.1.2-2.3
Severity: important

Dear Maintainer,

libkarma requires a rebuild, to pick up on the change from libmono-
corlib4.0-cil to libmono-corlib4.5-cil.



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-18-generic (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 libkarma-cil depends on:
pn  libkarma0  
ii  libmono-corlib4.0-cil  4.3.0.2050-0nightly1
ii  libmono-posix4.0-cil   4.3.0.2050-0nightly1

libkarma-cil recommends no packages.

libkarma-cil suggests no packages.

Bug#804537: Fixed patch

[Jo Shields]

My previous patch missed a CMakeLists.txt and broke the build, because I
am very smart
Index: cairo-dock-plug-ins-3.4.0/CMakeLists.txt
===
--- cairo-dock-plug-ins-3.4.0.orig/CMakeLists.txt
+++ cairo-dock-plug-ins-3.4.0/CMakeLists.txt
@@ -569,11 +569,11 @@ if (enable-mono-interface)
 	if (NOT GMCS_EXECUTABLE OR NOT EXISTS ${GMCS_EXECUTABLE})
 		message (STATUS "Could not find Mono compiler gmcs, won't build Mono interface.")
 	else()
-		pkg_check_modules (MONO_PACKAGE glib-sharp-2.0 ndesk-dbus-1.0 ndesk-dbus-glib-1.0)
+		pkg_check_modules (MONO_PACKAGE glib-sharp-2.0 dbus-sharp-2.0 dbus-sharp-glib-2.0)
 		if (NOT MONO_PACKAGE_FOUND)
-			message (STATUS "Could not find glib-sharp-2.0, ndesk-dbus-1.0 or ndesk-dbus-glib-1.0; won't be built Mono interface.")
-			message (WARNING "These modules are required to compile DBus applet with Mono interface: glib-sharp-2.0, ndesk-dbus-1.0 and ndesk-dbus-glib-1.0")
-			set (MODULES_MISSING "${MODULES_MISSING} glib-sharp-2.0 ndesk-dbus-1.0 ndesk-dbus-glib-1.0")
+			message (STATUS "Could not find glib-sharp-2.0, dbus-sharp-2.0 or dbus-sharp-glib-2.0; won't be built Mono interface.")
+			message (WARNING "These modules are required to compile DBus applet with Mono interface: glib-sharp-2.0, dbus-sharp-2.0 and dbus-sharp-glib-2.0")
+			set (MODULES_MISSING "${MODULES_MISSING} glib-sharp-2.0 dbus-sharp-2.0 dbus-sharp-glib-2.0")
 		else()
 			set (MONO_FOUND TRUE)
 			set (with_mono yes)
Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CDApplet.cs
===
--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/CDApplet.cs
+++ cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CDApplet.cs
@@ -29,7 +29,7 @@ using System;  // Environment
 using System.IO;  // Path, Directory
 using System.Reflection;
 using GLib;
-using NDesk.DBus;
+using DBus;
 using CairoDock.Applet;
 
 //namespace CairoDock.Applet
@@ -258,8 +258,8 @@ public class CDApplet
 	
 	private void _connect_to_dock ()
 	{
-		NDesk.DBus.BusG.Init();
-		NDesk.DBus.Bus bus = NDesk.DBus.Bus.Session;
+		DBus.BusG.Init();
+		DBus.Bus bus = DBus.Bus.Session;
 		this.icon = bus.GetObject ("org.cairodock.CairoDock", new ObjectPath (this.cBusPath));
 		this.icon.on_click 			+= new OnClickEvent (on_click);
 		this.icon.on_middle_click 	+= new OnMiddleClickEvent (on_middle_click);
Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/IApplet.cs
===
--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/IApplet.cs
+++ cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/IApplet.cs
@@ -1,6 +1,6 @@
 using System;
 using System.Collections.Generic;  // Dictionnary
-using NDesk.DBus;
+using DBus;
 
 namespace CairoDock.Applet
 {
@@ -27,7 +27,7 @@ namespace CairoDock.Applet
 		Left
 	}
 
-	[NDesk.DBus.Interface("org.cairodock.CairoDock.applet")]
+	[DBus.Interface("org.cairodock.CairoDock.applet")]
 	public interface IApplet
 	{
 		object Get(string cProperty);
Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/ISubApplet.cs
===
--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/ISubApplet.cs
+++ cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/ISubApplet.cs
@@ -1,6 +1,6 @@
 using System;
 using System.Collections.Generic;  // Dictionnary
-using NDesk.DBus;
+using DBus;
 
 namespace CairoDock.Applet
 {
Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CMakeLists.txt
===
--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/CMakeLists.txt
+++ cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CMakeLists.txt
@@ -3,7 +3,7 @@
 
 execute_process(COMMAND ${GMCS_EXECUTABLE}
 	-target:library
-	-pkg:glib-sharp-2.0 -pkg:ndesk-dbus-1.0 -pkg:ndesk-dbus-glib-1.0
+	-pkg:glib-sharp-2.0 -pkg:dbus-sharp-2.0 -pkg:dbus-sharp-glib-2.0
 	-out:${CMAKE_CURRENT_BINARY_DIR}/CDApplet.dll
 	${CMAKE_CURRENT_SOURCE_DIR}/CDApplet.cs ${CMAKE_CURRENT_SOURCE_DIR}/ISubApplet.cs ${CMAKE_CURRENT_SOURCE_DIR}/IApplet.cs)
 ### find how to register to GAC ...

Bug#804537: NMU

[Jo Shields]

I have prepared an NMU to fix this issue (attached) and uploaded to
DELAYED/10
diff -Nru cairo-dock-plug-ins-3.4.0/debian/changelog 
cairo-dock-plug-ins-3.4.0/debian/changelog
--- cairo-dock-plug-ins-3.4.0/debian/changelog  2015-10-16 15:29:38.0 
+0100
+++ cairo-dock-plug-ins-3.4.0/debian/changelog  2015-11-18 12:52:05.0 
+
@@ -1,3 +1,11 @@
+cairo-dock-plug-ins (3.4.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * d/p/0005-Use-dbus-sharp-not-unmaintained-NDesk.patch, debian/control: 
+Use dbus-sharp instead of ndesk-dbus (Closes: #804537)
+
+ -- Jo Shields <direct...@apebox.org>  Wed, 18 Nov 2015 12:49:35 +
+
 cairo-dock-plug-ins (3.4.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru cairo-dock-plug-ins-3.4.0/debian/control 
cairo-dock-plug-ins-3.4.0/debian/control
--- cairo-dock-plug-ins-3.4.0/debian/control2015-10-16 15:25:32.0 
+0100
+++ cairo-dock-plug-ins-3.4.0/debian/control2015-11-18 12:51:40.0 
+
@@ -25,8 +25,8 @@
  libical-dev,
  libido3-0.1-dev,
  libindicator3-dev,
- libndesk-dbus-glib1.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
- libndesk-dbus1.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
+ libdbus-glib2.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
+ libdbus2.0-cil-dev [amd64 armel i386 kfreebsd-any powerpc s390x],
  libpango1.0-dev,
  libpulse-dev,
  librsvg2-dev,
diff -Nru 
cairo-dock-plug-ins-3.4.0/debian/patches/0005-Use-dbus-sharp-not-unmaintained-NDesk.patch
 
cairo-dock-plug-ins-3.4.0/debian/patches/0005-Use-dbus-sharp-not-unmaintained-NDesk.patch
--- 
cairo-dock-plug-ins-3.4.0/debian/patches/0005-Use-dbus-sharp-not-unmaintained-NDesk.patch
   1970-01-01 01:00:00.0 +0100
+++ 
cairo-dock-plug-ins-3.4.0/debian/patches/0005-Use-dbus-sharp-not-unmaintained-NDesk.patch
   2015-11-18 14:50:16.0 +
@@ -0,0 +1,90 @@
+Index: cairo-dock-plug-ins-3.4.0/CMakeLists.txt
+===
+--- cairo-dock-plug-ins-3.4.0.orig/CMakeLists.txt
 cairo-dock-plug-ins-3.4.0/CMakeLists.txt
+@@ -569,11 +569,11 @@ if (enable-mono-interface)
+   if (NOT GMCS_EXECUTABLE OR NOT EXISTS ${GMCS_EXECUTABLE})
+   message (STATUS "Could not find Mono compiler gmcs, won't build 
Mono interface.")
+   else()
+-  pkg_check_modules (MONO_PACKAGE glib-sharp-2.0 ndesk-dbus-1.0 
ndesk-dbus-glib-1.0)
++  pkg_check_modules (MONO_PACKAGE glib-sharp-2.0 dbus-sharp-2.0 
dbus-sharp-glib-2.0)
+   if (NOT MONO_PACKAGE_FOUND)
+-  message (STATUS "Could not find glib-sharp-2.0, 
ndesk-dbus-1.0 or ndesk-dbus-glib-1.0; won't be built Mono interface.")
+-  message (WARNING "These modules are required to compile 
DBus applet with Mono interface: glib-sharp-2.0, ndesk-dbus-1.0 and 
ndesk-dbus-glib-1.0")
+-  set (MODULES_MISSING "${MODULES_MISSING} glib-sharp-2.0 
ndesk-dbus-1.0 ndesk-dbus-glib-1.0")
++  message (STATUS "Could not find glib-sharp-2.0, 
dbus-sharp-2.0 or dbus-sharp-glib-2.0; won't be built Mono interface.")
++  message (WARNING "These modules are required to compile 
DBus applet with Mono interface: glib-sharp-2.0, dbus-sharp-2.0 and 
dbus-sharp-glib-2.0")
++  set (MODULES_MISSING "${MODULES_MISSING} glib-sharp-2.0 
dbus-sharp-2.0 dbus-sharp-glib-2.0")
+   else()
+   set (MONO_FOUND TRUE)
+   set (with_mono yes)
+Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CDApplet.cs
+===
+--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/CDApplet.cs
 cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/CDApplet.cs
+@@ -29,7 +29,7 @@ using System;  // Environment
+ using System.IO;  // Path, Directory
+ using System.Reflection;
+ using GLib;
+-using NDesk.DBus;
++using DBus;
+ using CairoDock.Applet;
+ 
+ //namespace CairoDock.Applet
+@@ -258,8 +258,8 @@ public class CDApplet
+   
+   private void _connect_to_dock ()
+   {
+-  NDesk.DBus.BusG.Init();
+-  NDesk.DBus.Bus bus = NDesk.DBus.Bus.Session;
++  DBus.BusG.Init();
++  DBus.Bus bus = DBus.Bus.Session;
+   this.icon = bus.GetObject ("org.cairodock.CairoDock", 
new ObjectPath (this.cBusPath));
+   this.icon.on_click  += new OnClickEvent 
(on_click);
+   this.icon.on_middle_click   += new OnMiddleClickEvent 
(on_middle_click);
+Index: cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/IApplet.cs
+===
+--- cairo-dock-plug-ins-3.4.0.orig/Dbus/interfaces/mono/IApplet.cs
 cairo-dock-plug-ins-3.4.0/Dbus/interfaces/mono/IApplet.c

Bug#805464: NMU

[Jo Shields]

I have prepared an NMU to fix this problem (attached), and uploaded to
DELAYED/10
diff -Nru libkarma-0.1.2/debian/changelog libkarma-0.1.2/debian/changelog
--- libkarma-0.1.2/debian/changelog 2012-01-18 22:12:07.0 +
+++ libkarma-0.1.2/debian/changelog 2015-11-18 12:29:04.0 +
@@ -1,3 +1,10 @@
+libkarma (0.1.2-2.4) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for CLR 4.5 transition (Closes: #805464)
+
+ -- Jo Shields <direct...@apebox.org>  Wed, 18 Nov 2015 12:22:18 +
+
 libkarma (0.1.2-2.3) unstable; urgency=low
 
   * Non-maintainer upload

Bug#805360: libkitware-mummy-runtime1.0-cil: Please rebuild for libmono-corlib4.{0, 5}-cil transition

[Jo Shields]

Package: libkitware-mummy-runtime1.0-cil
Version: 1.0.3-2
Severity: important

Dear Maintainer,

Your package depends on libmono-corlib4.0-cil, which is going away soon.

A no-change rebuild is enough to resolve the issue - some architectures which
your package was built on more recently already have the newer dependency on
libmono-corlib4.5-cil.



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#805361: libactiviz.net-cil: Please rebuild for libmono-corlib4.{0,5}-cil transition

[Jo Shields]

Package: libactiviz.net-cil
Version: 1:1.0~git20111214-3
Severity: important

Dear Maintainer,

Your package depends on libmono-corlib4.0-cil, which is going away soon.

A no-change rebuild is enough to resolve the issue - some architectures which
your package was built on more recently already have the newer dependency on
libmono-corlib4.5-cil.



-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#805356: RM: semweb -- ROM; Unmaintained unused library package

[Jo Shields]

Package: ftp.debian.org
Severity: normal

Another "I have no idea what this was ever even used for" library, but I see no
rdeps.