Bug#886098: bios/mbr.bin: No such file or directory

[Maksym Komar]

Package: clonezilla
Version: 3.27.16-1
Severity: normal

Dear Maintainer,

I put usb with FAT and run:

$ sudo ocs-makeboot /dev/sde1
This program will write Debian Live and DRBL/Clonezilla programs onto this 
device. The MBR of this device will be overwritten (partition table will be 
kept)! Be careful when you use it! The device is:: /dev/sdf1
This is the disk usage status:
Disk /dev/sdf: 1.9 GiB, 2004877312 bytes, 3915776 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6794003a

Device Boot Start End Sectors  Size Id Type
/dev/sdf12048 3915775 3913728  1.9G 83 Linux
Are you sure you want to continue?
[y/N] y
OK, let's do it!
Finding the filesystem in /dev/sdf1... FAT, use syslinux as boot loader.
Now put boot files...
Install MBR first by: cat /usr/share/drbl/pkg/syslinux//bios/mbr.bin > /dev/sdf
cat: /usr/share/drbl/pkg/syslinux//bios/mbr.bin: No such file or directory
Set /dev/sdf1 as bootable...

hang there for a long time and then:

Installing boot loader by: syslinux -s /dev/sdf1
Making kernel re-read the partition table of /dev/sdf... 
Creating syslinux.cfg... Adding syslinux menus for Clonezilla live...
/usr/sbin/ocs-live-boot-menu: line 82: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 103: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 112: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 144: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 147: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 173: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 267: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 292: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
/usr/sbin/ocs-live-boot-menu: line 294: 
/tmp/ocs-usb-dev.jbxsQE/syslinux//syslinux.cfg: No such file or directory
done!



-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

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

Versions of packages clonezilla depends on:
ii  bc  1.06.95-9+b3
ii  dialog  1.3-20160828-2
ii  drbl2.20.11-1
ii  file1:5.30-1+deb9u1
ii  gdisk   1.0.1-1
ii  pigz2.3.4-1
ii  util-linux  2.29.2-1

Versions of packages clonezilla recommends:
pn  partclone  
pn  partimage  

Versions of packages clonezilla suggests:
ii  cifs-utils  2:6.7-1
ii  openssh-client  1:7.6p1-2
pn  sshfs   
pn  udpcast 

-- no debconf information

Bug#879854: 4.14 patch review

[Christian Ehrhardt]

On Fri, Dec 29, 2017 at 3:55 PM, Luca Boccassi  wrote:
> On Mon, 2017-12-18 at 07:40 +0100, Christian Ehrhardt wrote:
>> On Sun, Dec 17, 2017 at 4:48 PM, Luca Boccassi 
>> wrote:
>> > On Thu, 30 Nov 2017 13:56:42 +0100 Christian Ehrhardt
>> > > > d...@canonical.com> wrote:
>> > > Hi,
>> > > the patch seems to do more than just 4.14 which is good but needs
>> >
>> > some
>> > > discussion.
>> > > I'll try to do some tests based upon it later on, but for now I
>> >
>> > wanted
>> > > to say that dropping the iproute transitionals requires fixing
>> > > the
>> > > following old dependencies first.
>> > >
>> > > ipkungfu :Depends: iptables (>= 1.2.7), iproute, kmod, libc6 (>=
>> >
>> > 2.2.5)
>> > > apf-firewall :Depends: iptables, lsb-base, wget, iproute
>> > > arno-iptables-firewall :Depends: iptables, gawk, debconf |
>> > > cdebconf,
>> > > debconf (>= 0.5) | debconf-2.0, iproute
>> > >
>> > > --
>> > > Christian Ehrhardt
>> > > Software Engineer, Ubuntu Server
>> > > Canonical Ltd
>> >
>> > Hello,
>> >
>> > (Small world :-P )
>> >
>> > FYI as agreed with Alexander, the iproute2 maintainer, I've
>> > volunteered
>> > to help. [1]
>>
>> Indeed, hi Luca :-)
>>
>> On the Ubuntu Side I couldn't wait so I already did some work and you
>> can take a look what of that you want to pick up.
>> This [1] includes suggested changes in this and other Debian bugs, as
>> well as myself adding a autopkgtest case.
>> In fact the latter already has a follow on fix in queue to make it
>> work on non x86 [2].
>>
>> I hope that will help you when you get to 4.14.x
>>
>> cu
>> Christian
>
> Hi,
>
> 4.14 is now in testing and unstable, I've started doing a couple of
> packaging fixes.

Thanks Luca!

> I've imported the autopkgtest and patch for urandom (thanks!). Any
> chance you could send that patch upstream?

This change is by me and of course I should send it upstream, I punted
it on the pre-Christmas sprint :-)
Thanks for reminding, see [1]

> Also what's the story with those VXLAN Ubuntu patches? Are they going
> to be sent upstream?

Those are required to [2] only which AFAIK for now is Ubuntu only and
therefore not upstreamed.
Keep in mind that - just as you - I'm a drive-by-helper on this
package, so I might lack some past context :-)

[1]: https://marc.info/?l=linux-netdev=151487814431958=2
[2]: https://wiki.ubuntu.com/FanNetworking

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#886097: ITP: node-progressjs -- JavaScript progress bar library

[Daniel Ring]

Package: wnpp
Severity: wishlist
Owner: Daniel Ring 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-progressjs
  Version : 0.1.0
  Upstream Author : Afshin Mehrabani 
* URL : https://github.com/usablica/progress.js
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript progress bar library

 ProgressJs is a JavaScript and CSS3 library that helps developers create and
 manage progress bars for every object on the page.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#885423: [Pkg-opencl-devel] Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

[Rebecca N. Palmer]

On 01/01/18 22:38, Achim Schaefer wrote:

Here I see something different:
displacement_map_element()    [SUCCESS]
compiler_mandelbrot()utest_run:
/build/beignet-ydQSQk/beignet-1.3.2/utests/utest_helper.cpp:713: void
cl_write_bmp(const int*, int, int, const char*): Assertion `fp' failed.
     Interrupt signal (SIGABRT) received.


That's not a self-test failure: it's a failure to create a file, 
possibly due to running the tests in a directory the current user 
doesn't have permission to write to.


Does the original error (in darktable) still exist?

Bug#858736: xul-ext-gcontactsync: Depends on icedove or iceape but not thunderbird

[Carsten Schoenert]

Control: severity -1 serious

Dear maintainers of xul-ext-gcontactsync

On Sat, Mar 25, 2017 at 12:48:04PM -0700, Brian Vaughan wrote:
> Package: xul-ext-gcontactsync
> Version: 2.0.5-1
> Severity: normal
> 
> Dear Maintainer,
> 
> icedove is now a transitional package for thunderbird. xul-ext-gcontactsync
> works with thunderbird without issue; however the dependency information does
> not list thunderbird, so the icedove transitional package must be installed in
> order to use xul-ext-gcontactsync with thunderbird.
> 
> Provides: gcontactsync, iceape-gcontactsync, icedove-gcontactsync
> Depends: icedove (>= 17.0) | iceape (>= 2.14)
> Breaks: iceape (>> 2.35+), iceape (<< 2.14), icedove (<< 17.0)
> Enhances: iceape, icedove
> 
> Also, many of the files for this package are installed under
> '/usr/lib/icedove/extensions'.

starting with uploading src:thunderbird 1:52.5.0-1 there no transitional
packages like icedove* or iceowl* buils anymore. So the package
xul-ext-gcontactsync is depending on a binary package icedove which
isn't existing any longer in unstable.

I raised the severity for xul-ext-gcontactsync to serious as this
prevents now the migration of thunderbird packages to testing. Please
upload a rebuild package with adjusted description as mentioned by
Brain of xul-ext-gcontactsync. I guess you can also drop the patch from
the debian/patches folder.

Thanks
Carsten

Bug#886096: lintian: Emit warnings for Alioth URLs in packaging (migration to Salsa)

[Axel Beckert]

Package: lintian
Version: 2.5.67
Severity: wishlist

According to https://wiki.debian.org/Salsa/Doc all packaging projects
hosted on Alioth need to be moved away, preferably to Salsa.

This at least affects:

* ${VCS}.debian.org and anonscm.debian.org in Vcs-* headers and
  debian/upstream/metadata (with ${VCS} in at least git, svn, hg, bzr,
  darcs, arch, and cvs).

* http(s)://*.alioth.debian.org/ in Homepage headers,
  debian/upstream/metadata, and maybe also debian/copyright.

IMHO these should emit a tag at at least warning/normal level.

According to https://wiki.debian.org/Alioth/MailingListContinuation the
urgency for changing Maintainer fields, etc. which point to Alioth
mailing lists is lower. Hence for now, I suggest to also emit a
(separate) tag for these, but with severity informational/minor:

* lists.alioth.debian.org in the Maintainer and Uploaders fields

* Maybe also lists.alioth.debian.org elsewhere in packaging,
  e.g. Mailing list archives in debian/upstream/metadata,
  debian/copyright or so.

Additionally, some currently emitted tags can be probably removed or
replaced with according salsa.debian.org-based tags:

* vcs-field-not-canoncial

Then there's another set which might need updates, too:

* vcs-field-bitrotted
* vcs-field-uses-not-recommended-uri-format
* vcs-git-uses-invalid-user-uri

Feel free to clone this bug report in case these things won't be
implemented at the same time.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.01-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
ii  binutils-multiarch 2.29.1-12
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information

Bug#886095: RFS: gnubik/2.4.3-2 [ITA]

[Innocent De Marchi]

Package: sponsorship-requests
Severity: normal

  Dear mentors,

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

 * Package name: gnubik
   Version : 2.4.3-2
   Upstream Author : John Mark Darrington 
 * URL : http://ftp.gnu.org/gnu/gnubik/
 * License : GPL-3+
   Section : games

  It builds those binary packages:

gnubik - 3D Rubik's cube game

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

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


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

dget -x
https://mentors.debian.net/debian/pool/main/g/gnubik/gnubik_2.4.3-2.dsc


  Changes since the last upload:

  * New Maintainer (Closes: #826916).
  * Update to Standard-Version 4.1.3:
+ Bumped to compat level 10.
+ Changed debian/rules to dh $@.
+ Added automake to Build-Depends field.
  * Changed debian/watch uri to secure uri format.
  * Updated debian/copyright.
  * Migrated to guile-2.2 (Closes: #885194)
+ Added migrated-to-guile-2-2.patch file.


  Regards,
   Innocent De Marchi

Bug#857792: icedove-bidiui needs to become thunderbird-bidiui

[Carsten Schoenert]

Control: severity -1 serious

Dear maintainers of icedove-bidiui,

Thunderbird 52.5.2 has entered unstable a few days ago and the source
isn't building any transitional packages (e.g. icedove* or iceowl*)
since 1:52.5.0-1.
By this the package icedove-bidiui is now also preventing the migration
of the src:thunderbird packages from unstable to testing. As written
earlier I raise the severity for icedove-bidiui to serious.

Please update icedove-bidiui so both packages can be used.

On Wed, Sep 20, 2017 at 10:00:32PM +0200, Carsten Schoenert wrote:
> Dear Maintainers of bidiui,
> 
> On Wed, Mar 15, 2017 at 12:44:20AM -0400, Jonathan Joseph Chiarella wrote:
> > Package: icedove-bidiui
> > Version: 0.9.7-1
> > 
> > Debian is returning to the upstream branding of Mozilla's Firefox and
> > Thunderbird.
> > 
> > Most Thunderbird packages have been renamed from "icedove" to
> > "thunderbird" (and from "iceowl" plugin to "lightning"), but one
> > remaining package is icedove-bidiui, which needs to be renamed as
> > "thunderbird-bidiui.
> 
> your package is referencing to Icedove within short and long
> description. The package has also a Depends on icedove >= 2.0 which will
> be unresolvable with a upload of thunderbird packages 1:52.5.0-1 as we
> planning to remove the currently existing transitional packages starting
> with this version in unstable/testing.
> While writing this report the version in unstable/testing of thunderbird
> is 1:52.3.0-4. Mozilla is planning to release Firefox (Thunderbird)
> 52.5.0 on 2017-11-14.
> 
> https://wiki.mozilla.org/RapidRelease/Calendar
> 
> Please rework the control file for src:bidiui to get the package still
> available in testing.
> 
> I plan to raise the importance to important after preparing and pushing
> Thunderbird 52.4.0 to unstable and to serious with 52.5.0.
> 
> Regards and Thanks
> Carsten (on behalf of maintaining src:icedove)

Regards
Carsten

Bug#886093: Patch for #886093

[Joseph Nuthalapati]

Dear maintainer,

Please find the attached patch for the bug.

Submitted the same patch to the upstream.
Added appropriate headers to the patch for tracking the upstream bug.

-- 
Regards
Joseph Nuthalapati

From bdc803e185e1a7bb14892405a2c0c840ba6e0fe1 Mon Sep 17 00:00:00 2001
From: Joseph Nuthalapati 
Date: Tue, 19 Dec 2017 13:04:18 +0530
Bug-debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886093
Forwarded: https://github.com/asciimoo/searx/pull/1124
Reviewed-by: Sunil Mohan Adapa 
Subject: [PATCH] Make Python 3 able to read settings files with Unicode
 characters

SearX currently doesn't start up when run with Python 3 as it tries to parse the
settings.yml file with ASCII codecs.
There are similar problems with engines_languages.json and currencies.json
Python 3 requires that files with Unicode characters be read with a 'b' flag.
This also works with Python 2 and hence can be integrated into the main source
code.

Tested with the latest Python 3.6.4rc1 on Debian unstable.

Signed-off-by: Joseph Nuthalapati 
---
 searx/__init__.py | 2 +-
 searx/engines/__init__.py | 2 +-
 searx/engines/currency_convert.py | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/searx/__init__.py b/searx/__init__.py
index a57588c..84a377d 100644
--- a/searx/__init__.py
+++ b/searx/__init__.py
@@ -50,7 +50,7 @@ if not settings_path:
 raise Exception('settings.yml not found')
 
 # load settings
-with open(settings_path) as settings_yaml:
+with open(settings_path, 'rb') as settings_yaml:
 settings = load(settings_yaml)
 
 '''
diff --git a/searx/engines/__init__.py b/searx/engines/__init__.py
index 7a9cc56..bec8de3 100644
--- a/searx/engines/__init__.py
+++ b/searx/engines/__init__.py
@@ -36,7 +36,7 @@ engines = {}
 
 categories = {'general': []}
 
-languages = loads(open(engine_dir + '/../data/engines_languages.json').read())
+languages = loads(open(engine_dir + '/../data/engines_languages.json', 'rb').read())
 
 engine_shortcuts = {}
 engine_default_args = {'paging': False,
diff --git a/searx/engines/currency_convert.py b/searx/engines/currency_convert.py
index 1bb4e60..34a9af6 100644
--- a/searx/engines/currency_convert.py
+++ b/searx/engines/currency_convert.py
@@ -94,7 +94,7 @@ def load():
 global db
 
 current_dir = os.path.dirname(os.path.realpath(__file__))
-json_data = open(current_dir + "/../data/currencies.json").read()
+json_data = open(current_dir + "/../data/currencies.json", 'rb').read()
 
 db = json.loads(json_data)
 
-- 
2.15.1



signature.asc
Description: OpenPGP digital signature

Bug#885704: liblept5 negatively plays with paths in /tmp when opening TIFFs

[Jeff Breidenbach]

Will investigate.

Bug#886094: conserver-server: logrotate config should use sharedscripts

[cheetah]

Package: conserver-server
Version: 8.2.1-1+b1
Severity: normal

conserver-server's logrotate config should use the "sharedscripts" keyword
in its stanza, otherwise every time it rotates, lots of errors come out due
to the pid file getting invalidated from the first restart from the first
logfile, but not having been rewritten yet for the subsequent logfiles (I
think?):


/etc/cron.daily/logrotate:
/etc/init.d/conserver-server: 71: kill: No such process

error: error running non-shared postrotate script for 
/var/log/conserver/thing1.log of '/var/log/conserver/*.log '
/etc/init.d/conserver-server: 71: kill: No such process

error: error running non-shared postrotate script for 
/var/log/conserver/thing2.log of '/var/log/conserver/*.log '
/etc/init.d/conserver-server: 71: kill: No such process

error: error running non-shared postrotate script for 
/var/log/conserver/thing3.log of '/var/log/conserver/*.log '

...etc

-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 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: systemd (via /run/systemd/system)

Versions of packages conserver-server depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.61
ii  libc6  2.24-11+deb9u1
ii  libpam0g   1.1.8-3.6
ii  libssl1.0.21.0.2l-2+deb9u2
ii  libwrap0   7.6.q-26
ii  lsb-base   9.20161125

conserver-server recommends no packages.

conserver-server suggests no packages.

-- debconf information excluded

Bug#886093: searx: Fails to start when using Python 3

[Joseph Nuthalapati]

Package: searx
Version: 0.13.1+dfsg1-3
Severity: grave


SearX currently doesn't start up when run with Python 3 as it tries to parse 
the settings.yml file with ASCII codecs. The file has a list of languages which 
are in Unicode characters.





signature.asc
Description: OpenPGP digital signature

Bug#885976: flatpak: fails to run on symlinked path locations

[Ritesh Raj Sarraf]

On Mon, 2018-01-01 at 11:20 +, Simon McVittie wrote:
> On Mon, 01 Jan 2018 at 10:51:13 +0530, Ritesh Raj Sarraf wrote:
> > It seems flatpak has very fragile path assumptions. I have a basic
> > setup
> > with 2 HDDs, where in I have my /var/tmp/ as a symlink pointing to
> > a
> > secondary location. This shouldn't be tagged an unusual setup.
> 
> I would recommend preferring bind-mounts over symlinks when
> redirecting
> paths that are significant to the OS to some other drive. Flatpak is
> not
> the only tool that benefits from this: anything that uses a
> rearranged
> view of the filesystem (mostly container technologies) will be
> simpler
> and more reliable if it can rely on directories being directories.
> 

Thanks for the suggestion. The Skype flatpak worked after switch to a
bind mount.

> > bwrap: Can't make symlink at /var/tmp: File exists
> 
> This is trying to create a symlink as the sandbox's /var/tmp, not in
> your real system's filesystem namespace; but Flatpak always creates a
> /var/tmp directory anyway, so that symlink creation fails.
> 
> What's in
> ~/.local/share/flatpak/app/${app_id}/current/active/metadata
> or /var/lib/flatpak/app/${app_id}/current/active/metadata for the app
> in question?
> 

rrs@priyasi:~$ cat
~/.local/share/flatpak/app/com.skype.Client/current/active/metadata  
[Application]
name=com.skype.Client
runtime=org.freedesktop.Platform/x86_64/1.6
sdk=org.freedesktop.Sdk/x86_64/1.6
command=skype

[Context]
shared=network;ipc;
sockets=x11;pulseaudio;
devices=all;
filesystems=xdg-download;home:ro;

[Session Bus Policy]
org.kde.StatusNotifierWatcher=talk
org.freedesktop.secrets=talk
org.gnome.GConf=talk
org.gtk.Notifications=talk
org.freedesktop.Notifications=talk

[System Bus Policy]
org.freedesktop.NetworkManager=talk
org.bluez=talk

[Environment]
XDG_CURRENT_DESKTOP=Unity

[Extra Data]
name=skypeforlinux-64.deb
checksum=2ad7bea3cb42735d140df48e3ca15c3dea31b91452aa45298c2ace40f67548
f9
size=72297826
uri=https://repo.skype.com/deb/pool/main/s/skypeforlinux/skypeforlinux_
8.13.76.4_amd64.deb

[Extension com.skype.Client.Debug]
directory=lib/debug
autodelete=true
no-autodownload=true
10:55 ♒♒♒   ☺


> smcv
-- 
Ritesh Raj Sarraf | http://people.debian.org/~rrs
Debian - The Universal Operating System

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

Bug#886024: [Pkg-emacsen-addons] Bug#886024: emacs deb package install is hanging forever (locked file)

[H.-Dirk Schmitt]

The problem occurs with  emacs24  24.5+1-8 

I don't think that the problem is specifi
The from
> d...@computer42.org (H.-Dirk Schmitt) writes:
> 
> > 
> > > Wrote /root/.breadcrumb …ing-c-adaptive-history locked by root@vt
> > > -xenia… (pid 5423): (s, q, p, ?)?
> 
> If you have it, the complete, unedited prompt/error-message would be
> helpful.

As written in the report, no error message is shown during normally
processing with apt-get or dpkg.

The error message was only shown by manually invoke:
`emacs24 -q -batch -l package --eval (add-to-list 'package-directory-
list "/usr/share/emacs/site-lisp/elpa-src") -f package-initialize -f
batch-byte-compile markdown-mode-autoloads.el markdown-mode-pkg.el
markdown-mode.el`

As I understand the problem is that the elisp install procedure is
flawed.  I experienced the problem here with elpa-markdown-mode 2.1-1,
but think the problem is related to many elisp packages following the
same installation pattern.

The problem chain I debugged was:
- /var/lib/dpkg/info/elpa-markdown-mode.postinst
-  \
  --postinst elpa-markdown-mode
- /usr/lib/emacsen-common/packages/install/elpa-markdown-mode
-  ${FLAVOR} -q -batch -l package \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
-f package-initialize -f batch-byte-compile *.el > Install.log 2>&1

The last statement assume that emacs will process the --eval … stuff,
but here comes the race condition, that emacs found a locked file from
a dirty exited emacs session (e.g. reboot occurred).

So the non-interactive script is waiting for the user to answer the
question what to do with the locked file.
Due to the redirection to the „Install.log“ nothing is visible for the
user and no answer is generated. So the installation process is hanging
  for this and all future call of apt-get/dpkg.

The root cause – the locked file - is outside the scope of the emacs
packages, so a „purge and reinstall“ approach will fail and the
situation will break the whole debian/ubuntu/… package update
processing till the next time emacs is invoked by root as „interactive“
 editor. 

A first mitigation of the problem could be to replace the 
'&> Install.log' redirection by '|& tee Install.log' 

In this case the 'locked by root@…' message will be visible to the
admin user who called 'apt-get/dpkg'.

Bug#866632: bibledit-gtk: depends on libwebkitgtk-1.0-0 which is deprecated

[Matthew A. Postiff]

  
  
Hi Jeremy, Roberto, Teus,

Thank you for your help. I have taken over the development on
  this project, though I will admit I'm not much of a developer :-)
  Thus what I say below may seem very unlearned. Any guidance you
  can provide will be received gratefully on my part.
I have managed to fix the configure.ac like so:
PKG_CHECK_MODULES(WEBKIT, webkit2gtk-4.0 >= 2.18.3,,...)
However, in the WEBKIT_LIBS in the Makefile, configure now
  includes -lgtk-3 -lgdk-3. Right now our package is running on
  gtk2, and I didn't anticipate upgrading both webkit and gtk at the
  same time. I was hoping to do webkit first, and then sometime
  later the gtk. Is that approach possible, or should I just bite
  the bullet now and upgrade both dependencies?
Thanks,

Matt

  

Bug#886092: ITP: node-knockout-transformations -- Live transform methods for Knockout observable arrays

[Daniel Ring]

Package: wnpp
Severity: wishlist
Owner: Daniel Ring 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-knockout-transformations
  Version : 2.1.0
  Upstream Author : One.com
* URL : https://github.com/One-com/knockout-transformations
* License : Apache-2.0
  Programming Lang: JavaScript
  Description : Live transform methods for Knockout observable arrays

 This plugin adds observable map, filter, indexBy and sortBy features to
 Knockout.js observable arrays, so you can transform collections in arbitrary
 ways and have the results automatically update whenever the underlying source
 data changes.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#885436: [Aptitude-devel] Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[Axel Beckert]

Hi,

David Kalnischkies wrote:
> On Thu, Dec 28, 2017 at 12:45:14AM +0100, Manuel A. Fernandez Montecelo wrote:
> > > In the extremely rare (I think) case where an upgrade (or downgrade)
> > > replaces a specific architecture package with an architecture all
> > > package, or vice versa,
[…]
> The architecture for a package in apt is never 'all' as this isn't
> a property of the package for preciously the reason Marvin outlines as
> "extremely rare" case – it just isn't that rare.

Indeed. I can tell you one such case by mind (because I created it):

→ apt-cache show wml | egrep '^(Package|Version|Architecture|$)'
Package: wml
Version: 2.4.1ds1-2
Architecture: all

Package: wml
Version: 2.0.12ds1-10+b2
Architecture: amd64

(That's wml in unstable/testing and experimental currently.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#886091: RM: gnome-orca -- RoM; cruft, superseded by orca source pkg

[Jeremy Bicha]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: gnome-o...@packages.debian.org, elb...@debian.org

The gnome-orca source package has been renamed to orca in testing and
unstable. A transitional package is provided. gnome-orca doesn't show
on the cruft report because it is arch: all and that isn't handled
very well yet.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886090: solr-jetty: Doesn't work out-of-the-box anymore; required symlink is missing

[J.P. Larocque]

Package: solr-jetty
Version: 3.6.2+dfsg-10
Severity: normal

Hi,

I'm using Solr to provide full-text indexing services for Dovecot,
which uses it to index e-mail bodies.  I've only barely scratched the
surface of Java, and know nothing about Java web application
development or deployment.

I installed Solr on my mail server when it was running Jessie or an
earlier release of Debian.  I seem to recall that the setup process at
that point in time was pretty straightforward.  Recreating the
scenario on a fresh Jessie system now, I see that all I needed to do
to get Jetty responding with Solr-generated responses was to install
solr-jetty, edit /etc/default/jetty8 to set NO_START=0, and restart
jetty8.

When I upgraded my mail server to Debian Stretch, Solr stopped
working.  Jetty responded with status 404 instead:

$ curl --verbose http://localhost:8080/solr/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /solr/ HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.52.1
> Accept: */*
> 
< HTTP/1.1 404 Not Found
< Content-Type: text/html; charset=ISO-8859-1
< Cache-Control: must-revalidate,no-cache,no-store
< Content-Length: 289
< Server: Jetty(9.2.21.v20170120)
< 



Error 404 Not Found

HTTP ERROR 404
Problem accessing /solr/. Reason:
Not FoundPowered by Jetty://



* Curl_http_done: called premature == 0
* Connection #0 to host localhost left intact

Because of my lack of experience with the Java and Jetty ecosystem, it
was a confusing and frustrating process to get Solr working again.  It
seemed like the symlink /etc/jetty9/contexts/solr.xml ->
../../solr/solr-jetty.xml was supposed to be doing something, but it
apparently wasn't.  (On my Jessie test system, a similar symlink in
/etc/jetty8/contexts/ seems to be the piece that configures Jetty for
Solr.)

It seems like some configuration methods changed between Jetty 8
(Jessie) and Jetty 9 (Stretch).  Eventually, I found a helpful message
on jetty-users [1], and a pointer to the right part of the Jetty
documentation [2].  I created this symlink:

$ sudo ln -s /etc/solr/solr-jetty.xml /var/lib/jetty9/webapps/solr.xml

After restarting Jetty, Jetty responded to /solr URLs again, and Solr
worked with my existing configuration and application as it did
previously.

If this symlink is always the right thing to do for an upgrade or a
new installation, would you please consider including it in the
package or having it created upon installation?  If it's not the right
thing to do in all cases, could you please add some instructions or
hints to README.Debian?

1. https://dev.eclipse.org/mhonarc/lists/jetty-users/msg05035.html
2. 
https://www.eclipse.org/jetty/documentation/current/deployment-architecture.html#default-web-app-provider

Thanks,

-J.P. Larocque

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages solr-jetty depends on:
ii  default-jdk [java5-sdk]2:1.8-58
ii  jetty9 9.2.21-1
ii  libjetty9-extra-java   9.2.21-1
ii  openjdk-8-jdk [java5-sdk]  8u151-b12-1~deb9u1
ii  solr-common3.6.2+dfsg-10

solr-jetty recommends no packages.

solr-jetty suggests no packages.

-- no debconf information

-- 
J.P. Larocque 

Bug#886082: foxtrotgps: Depends on gconf

[Paul Wise]

On Mon, 2018-01-01 at 21:10 -0500, Jeremy Bicha wrote:

> Your package depends or build-depends on gconf, but gconf will be
> removed from Debian soon.

I've started working on this upstream.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#886089: r-cran-hms: new upstream version available

[Rogério Brito]

Package: r-cran-hms
Version: 0.3-1
Severity: wishlist

Hi! Happy New Year!

A new version of the package (0.4.0) is available. Can it be packaged,
please?


Thanks,

Rogério.

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

Kernel: Linux 4.15.0-041500rc5-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.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)

Versions of packages r-cran-hms depends on:
ii  r-base-core   3.4.3-1
ii  r-cran-pkgconfig  2.0.1-2
ii  r-cran-rlang  0.1.4-1

r-cran-hms recommends no packages.

r-cran-hms suggests no packages.

-- no debconf information

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Bug#886088: aisleriot: Depends on gconf

[Jeremy Bicha]

Source: aisleriot
Version: 1:3.22.4-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster
Forwarded: https://bugzilla.gnome.org/show_bug.cgi?id=662759

I think Debian should follow Ubuntu's lead and drop the gconf support
from aisleriot. Maybe we could add a NEWS.Debian to let people know
that their high scores will be lost upon upgrading. (aisleriot never
got gsettings support.)

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

Thanks,
Jeremy Bicha

Bug#885778: swami: Depends on libgnomecanvas

[Element Green]

Thank you for the info.  Should give me enough time to do the port.

Best regards,

Element


On Mon, Jan 1, 2018 at 11:47 AM, Jaromír Mikeš  wrote:

>
>
> 2018-01-01 18:34 GMT+01:00 Element Green :
>
>> Hello Mira,
>>
>> While I do plan on porting Swami to GTK3 at some point, it is not a
>> trivial task and I haven't had much time for it.  I'll definitely keep this
>> in mind in regards to Debian removing it if it isn't ported and prioritize
>> this accordingly.  When would a port need to be completed in order to
>> continue to be a part of Debian?
>>
>> Best regards,
>>
>> Element
>>
>
> ​Hello Joshua,
>
> thank you for reply ... release date for Buster wasn't set yet but I guess
> it will be sometime about June 2019 ...
> so there is a time.
>
> best regards
>
> mira​
>
>

Bug#886087: alarm-clock-applet: Depends on gconf

[Jeremy Bicha]

Source: alarm-clock-applet
Version: 0.3.4-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886086: camorama: Depends on gconf

[Jeremy Bicha]

Source: camorama
Version: 0.19-5
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886084: comix: Depends on gconf

[Jeremy Bicha]

Source: comix
Version: 4.0.4-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886085: cbrpager: Depends on gconf

[Jeremy Bicha]

Source: cbrpager
Version: 0.9.22-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886082: foxtrotgps: Depends on gconf

[Jeremy Bicha]

Source: foxtrotgps
Version: 1.2.0-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886083: eclipse-platform: Depends on gconf

[Jeremy Bicha]

Source: eclipse-platform
Version: 3.8.1-10
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886081: gbatnav: Depends on gconf

[Jeremy Bicha]

Source: gbatnav
Version: 1.0.4cvs20051004-5
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886080: gbonds: Depends on gconf

[Jeremy Bicha]

Source: gbonds
Version: 2.0.3-11
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886079: gmotionlive: Depends on gconf

[Jeremy Bicha]

Source: gmotionlive
Version: 1.0-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886077: RM: smokeqt [kfreebsd-i386,kfreebsd-amd64] -- ROM; NBS, but not in cruft report

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

The following binaries are no longer built, but because kfreebsds are not
currently building packages, they haven't been dropped:

libsmokeqsci3 libsmokeqtdbus4-3 libsmokeqthelp4-3 libsmokeqtopengl4-3 
libsmokeqtscript4-3 libsmokeqtsql4-3 libsmokeqtsvg4-3 libsmokeqtuitools4-3 
libsmokeqtxmlpatterns4-3 libsmokephonon3 libsmokeqimageblitz3

Bug#886078: gnome-breakout: Depends on gconf

[Jeremy Bicha]

Source: gnome-breakout
Version: 0.5.3-5
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886076: gnome-commander: Depends on gconf

[Jeremy Bicha]

Source: gnome-commander
Version: 1.4.8-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886075: gnome-mastermind: Depends on gconf

[Jeremy Bicha]

Source: gnome-mastermind
Version: 0.3.1-2
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886074: gnome-phone-manager: Depends on gconf

[Jeremy Bicha]

Source: gnome-phone-manager
Version: 0.69-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886072: gnome-xcf-thumbnailer: Depends on gconf

[Jeremy Bicha]

Source: gnome-xcf-thumbnailer
Version: 1.0-1.2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886073: debian-dad: option to print diff of updates instead of applying them

[Paul Wise]

Package: debian-dad
Severity: wishlist
Control: affects -1 check-all-the-things
X-Debbugs-CC: check-all-the-thi...@packages.debian.org
User: check-all-the-thi...@packages.debian.org
Usertags: new-check

I would like to add a check to check-all-the-things that runs
debian-dad and prints out the diff of the changes. This would
be made easier if debian-dad supported this out of the box.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#886070: grhino: Depends on gconf

[Jeremy Bicha]

Source: grhino
Version: 0.16.1-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886071: grdesktop: Depends on gconf

[Jeremy Bicha]

Source: grdesktop
Version: 0.23+d040330-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886069: gstm: Depends on gconf

[Jeremy Bicha]

Source: gstm
Version: 1.2-8.1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886068: gtk-theme-config: Depends on gconf

[Jeremy Bicha]

Source: gtk-theme-config
Version: 1.2.2-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

This should be pretty simple to fix since I don't think any desktop in
Debian uses gconf any more so you should be able to just drop the gconf
code.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886067: gtkwave: Depends on gconf

[Jeremy Bicha]

Source: gtkwave
Version: 3.3.86-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster
X-Debbugs-CC: aelmahmo...@users.sourcefoge.net

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886066: gxneur: Depends on gconf

[Jeremy Bicha]

Source: gxneur
Version: 0.20.0-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886065: gyrus: Depends on gconf

[Jeremy Bicha]

Source: gyrus
Version: 0.3.10-3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885556: udeb uninstallability trend: worse (+20/-0)

[Don Armstrong]

On Mon, 01 Jan 2018, Don Armstrong wrote:
> On Mon, 01 Jan 2018, Cyril Brulebois wrote:
> > udeb uninstallability watcher  (2018-01-01):
> > > Newly-broken packages in testing
> > >   multipath-udeb   amd64 arm64 armel armhf i386 
> > > mips mips64el mipsel ppc64el s390x
> > >   partman-multipathamd64 arm64 armel armhf i386 
> > > mips mips64el mipsel ppc64el s390x
> > 
> > I'm wondering how this is possible with an RC bug filed against the
> > multipath-udeb udeb (#885556). For some reason, it's listed as found in
> > multipath-tools/0.7.4-2 on the BTS side, without a version graph; and
> > it isn't listed by tracker or by the old PTS. I'm suspecting there's
> > something fishy on the BTS side so britney didn't notice the RC bug
> > and let it migrate?
> 
> Yeah, this definitely looks like a BTS mistake. It seems to know that
> the right versions are in unstable, but they're not showing up on the
> graph.

OK. Found the issue. Apparently, packages in the */debian-installer
components were being skipped when the BTS was figuring out what was in
which distribution. I've fixed that now, and the versions database is
being updated with that information.

The underlying issue should show up as fixed once the version graph for
this bug looks sane. [Probably in another 10-20 minutes.]


-- 
Don Armstrong  https://www.donarmstrong.com

Every gun that is made, every warship launched, every rocket fired
signifies [...] a theft from those who hunger and are not fed, those
who are cold and are not clothed. This world in arms is not spending
money alone. It is spending the sweat of its laborers, the genius of
its scientists, the hopes of its children. [...] This is not a way of
life at all in any true sense. Under the cloud of threatening war, it
is humanity hanging from a cross of iron. [...] [I]s there no other
way the world may live?
 -- President Dwight D. Eisenhower, April 16, 1953

Bug#851400: closed by Michael Biebl <bi...@debian.org> (Re: systemd: Going into suspend yust after waking up)

[Michael Fritscher]

Hi,

sorry, didn't see the last replay :-(
It is not related to the lid switch - it happened also if the laptop was
open all the time. The problem was also when stretch got stable, but
didn't try it again in the last three months or so. I'll retest it in a
few days.

Best regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#886024: [Pkg-emacsen-addons] Bug#886024: emacs deb package install is hanging forever (locked file)

[David Bremner]

d...@computer42.org (H.-Dirk Schmitt) writes:

>
>> Wrote /root/.breadcrumb …ing-c-adaptive-history locked by root@vt-xenia… 
>> (pid 5423): (s, q, p, ?)?

If you have it, the complete, unedited prompt/error-message would be
helpful. It looks like it is related to the package anything-el. So it
would be useful to know what version of that package you have installed.

Looking at anything.el, I'm puzzled how it should be activated with
emacs -q. Can you attach /etc/emacs/site-start.d/50anything-el.el ?

Bug#868408: xnee: Please drop the (build-)dependency against gnome-vfs

[Andreas Henriksson]

Hej Henrik, Vincent,

On Tue, Jan 02, 2018 at 12:11:16AM +0100, Henrik Sandklef wrote:
> I have removed deps to gnomeui (gconf had already been removed) from Xnee
> sources.

Vincent, please see the attached debdiff that incorporates Henriks
change as a patch in debian/patches/ for your convenience.
(You might also want to look into upgrading to a non-deprecated
debhelper compat level (apparently 5 is currently used while anything
before 9 is deprecated), etc. See also other lintian warnings.)

> 
> Can I assist you in any way?

Thanks for the offer! From my point of view it's really up to Vincent
how he wants to handle this - I just wanted to remind and point out
the urgency of this issue being resolved in any way.
Hopefully Vincent will get in touch with you if he has something
to discuss.

While poking around I noticed a couple of things which I'm just
mentioning in case it'll interest you:
- Is it true CVS is still used? (Or else I've probably looked at the
wrong upstream location)
- I guess $(libgnomeui_LIBS) and $(libgnomeui_CFLAGS) can now also
  be dropped from gnee/src/Makefile.am (and possibly other places?)
- Apparently configure(.in) has no check for pkg-config modules actually
  exiting (which I ran into while having pkg-config itself, but not
  gtk+-2.0.pc since the libgtk2.0-dev build-dependency was missing in
  the debian xnee package). A more obvious error message could have
  been produced by explicitly checking
  if ! $PKGCONF --exists $GTK2_MODULE >= GTK2_VERSION and erroring out.
  Even better though... (see below).
- directly invoking pkg-config is not cross compilation safe (as lintian
  points out). It would probably be better to replace all pkg-config
  usage with PKG_CHECK_MODULES macro usage instead. (And gtk-config is
  long gone so you can probably retire that code path while at it.)
  This should also give a more modern and fool-proof configure process.

The lintian report might also give you useful information:
https://lintian.debian.org/maintainer/ber...@debian.org.html#xnee_3.19-1

Med vänlig hälsning,
Andreas Henriksson
diff -Nru xnee-3.19/debian/changelog xnee-3.19/debian/changelog
--- xnee-3.19/debian/changelog	2014-05-23 01:33:06.0 +0200
+++ xnee-3.19/debian/changelog	2018-01-02 01:14:24.0 +0100
@@ -1,3 +1,15 @@
+xnee (3.19-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Add debian/patches/upstream_libgnomui-only-for-applets.patch
+- upstream commit/revision 1.134->1.135 to not require
+  libgnomeui unless building applets (which is disabled here).
+  * Drop libgnomeui-dev build-dependency. (Closes: #885738)
+  * Add missing build-dependencies on pkg-config and libgtk2.0-dev
+- previously implicitly pulled in via libgnomeui-dev
+
+ -- Andreas Henriksson   Tue, 02 Jan 2018 01:14:24 +0100
+
 xnee (3.19-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru xnee-3.19/debian/control xnee-3.19/debian/control
--- xnee-3.19/debian/control	2014-05-23 01:33:06.0 +0200
+++ xnee-3.19/debian/control	2018-01-02 01:14:24.0 +0100
@@ -7,9 +7,10 @@
 debhelper (>= 5),
 cdbs,
 dh-autoreconf,
+pkg-config,
+libgtk2.0-dev,
 libxtst-dev,
 imagemagick,
-libgnomeui-dev,
 dia,
 texi2html,
 texlive-base,
diff -Nru xnee-3.19/debian/patches/series xnee-3.19/debian/patches/series
--- xnee-3.19/debian/patches/series	2014-05-23 01:33:06.0 +0200
+++ xnee-3.19/debian/patches/series	2018-01-02 01:13:16.0 +0100
@@ -2,3 +2,4 @@
 manpages-fix.patch
 fix-docdir.patch
 dont-compile-dvi.patch
+upstream_libgnomui-only-for-applets.patch
diff -Nru xnee-3.19/debian/patches/upstream_libgnomui-only-for-applets.patch xnee-3.19/debian/patches/upstream_libgnomui-only-for-applets.patch
--- xnee-3.19/debian/patches/upstream_libgnomui-only-for-applets.patch	1970-01-01 01:00:00.0 +0100
+++ xnee-3.19/debian/patches/upstream_libgnomui-only-for-applets.patch	2018-01-02 01:14:24.0 +0100
@@ -0,0 +1,117 @@
+--- a/configure.in	2014/05/06 14:13:59	1.134
 b/configure.in	2018/01/01 23:06:56	1.135
+@@ -382,62 +382,63 @@
+ fi
+ 
+ 
+-GNOMEUI2_MODULE="libgnomeui-2.0"
+-GNOMEUI2_VERSION="2.0.0"
+-
+-
+-if `$PKGCFG --exists  $GNOMEUI2_MODULE >= $GNOMEUI2_VERSION`
+-then	
+-	GTK_MODULES="$GTK_MODULES $GNOMEUI2_MODULE" 
+-	GTK_ERR=1
+-fi
+-
+-libgnomeui_CFLAGS=`$PKGCFG --cflags $GNOMEUI2_MODULE `
+-libgnomeui_LIBS=`$PKGCFG --libs $GNOMEUI2_MODULE `
+-
+-
+-AC_SUBST(libgnomeui_CFLAGS)
+-AC_SUBST(libgnomeui_LIBS)
+-
+ PIXMAP_DIR=pixmap
+ 
+-
+-if test x$buildgapplet = xtrue ; 
++if test x$buildgapplet = xtrue; 
+ then   
+-
+-  if test x$GTKCONF = x ; 
+-  then
+-  	echo "  "
+-  	echo " * WARNING, missing program: gtk-config *"
+-  	echo "  "
+-  	echo ""
+-  	echo " On Debian 

Bug#886032: markdown: Please make /usr/bin/markdown exit with a non-zero exit code if cannot open input file

[Matt Kraai]

Hi,

On Mon, Jan 01, 2018 at 08:41:12PM +, Chris Lamb wrote:
>   $ markdown does-not-exist 
>   Can't open does-not-exist: No such file or directory at /usr/bin/markdown 
> line 221.
>   Use of uninitialized value $text in substitution (s///) at 
> /usr/bin/markdown line 248.
>   Use of uninitialized value $text in substitution (s///) at 
> /usr/bin/markdown line 249.
> 
>   $ echo $?
>   0
> 
> This would appear to violate UNIX principles, etc. Instead, please make
> /usr/bin/markdown exit with a non-zero exit code if cannot open the input
> file.
> 
> Patch attached.

Thanks for the suggestion and patch.  I've uploaded a new version
which contains the patch.

-- 
Matt

Bug#886024: [Pkg-emacsen-addons] Bug#886024: emacs deb package install is hanging forever (locked file)

[David Bremner]

d...@computer42.org (H.-Dirk Schmitt) writes:

> Package: emacsen-common, markdown-mode
> Severity: important
> Tags: security

Could you please either use reportbug, or gather the information that
reportbug would gather by hand. We need at least

- the version of Debian you are talking about
- the installed versions of

  - emacs
  - emacs24
  - emacs25
  - emacsen-common
  - markdown-mode
  - elpa-markdown-mode

Bug#818377: improve courier-maildrop compatibility

[Josip Rodin]

On Sun, Dec 31, 2017 at 10:09:22AM +0900, Osamu Aoki wrote:
> | AC_DEFINE_UNQUOTED(HAVE_COURIER,1,
> | [ Whether this version of maildrop is part of Courier ])

All of those changes related to HAVE_COURIER sound like something that
should be possible to figure out on runtime. For example, it could detect
some Courier-specific config file somewhere in /etc/, and then make those
few subtle changes in behavior.

> But in the courier MTA use case, the upstream apparently had need to keep
> this program setUID root and added some extra codes to take advantage
> (code before the quoted section seems to be for such purpose) of it and to
> limit it privilege as quoted in the above.

I still don't see a rationale for that. The existence of those measly few
lines about the HAVE_COURIER define, that we then have to interpret and
reverse-engineer and whatnot - simply don't constitute a valid rationale
for adding back a binary with suid root by default.

I think we need to ask Sam to document this properly, and only then proceed
with any further considerations.

-- 
 2. That which causes joy or happiness.

Bug#883869: e2fsprogs: debugfs doesn't write group descriptor with block bitmap checksum modified

[Theodore Ts'o]

On further examination, there is a ext2fs library bug fix that will
address your issue.  The problem is that if there aren't any pending
superblock or block group descriptors changes that need to be written,
when we write out the bitmap blocks, we update the in-memory checksum
fields but they don't actually get written out to disk.

   - Ted

commit 0cdda6cb753657fcd92f2c02198137bd2a65787a
Author: Theodore Ts'o 
Date:   Mon Jan 1 18:59:16 2018 -0500

libext2fs: when writing bitmaps mark the fs as dirty if necessary

If any checksum fields are updated in the block group descriptors, we
need to set the EXT2_FLAG_DIRTY flag so that the block group
descriptors are written to disk.

Addresses-Debian-Bug: #883869

Signed-off-by: Theodore Ts'o 

diff --git a/lib/ext2fs/rw_bitmaps.c b/lib/ext2fs/rw_bitmaps.c
index ae593d494..9db76eb94 100644
--- a/lib/ext2fs/rw_bitmaps.c
+++ b/lib/ext2fs/rw_bitmaps.c
@@ -94,6 +94,7 @@ static errcode_t write_bitmaps(ext2_filsys fs, int do_inode, 
int do_block)
if (retval)
return retval;
ext2fs_group_desc_csum_set(fs, i);
+   fs->flags |= EXT2_FLAG_DIRTY;
 
blk = ext2fs_block_bitmap_loc(fs, i);
if (blk) {
@@ -125,6 +126,7 @@ static errcode_t write_bitmaps(ext2_filsys fs, int 
do_inode, int do_block)
if (retval)
goto errout;
ext2fs_group_desc_csum_set(fs, i);
+   fs->flags |= EXT2_FLAG_DIRTY;
 
blk = ext2fs_inode_bitmap_loc(fs, i);
if (blk) {

Bug#885968: lintian: extra-license-file should ignore sphinx _sources/license.txt

[Stuart Prescott]

On Monday, 1 January 2018 14:39:20 AEDT Chris Lamb wrote:
> tags 885968 + pending
> thanks
> 
> Fixed in Git:
> 
>  
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=990d13bd660af
> 78cd8c3e781cfbee2c70bb90cff

+# Sphinx includes license files
+and not $fname =~ m,/_sources/license\.rst(\.txt)?$,o

BTW this should include license.txt too from sphinx before 1.6(ish).


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

Bug#854209: Rewritting the license is not relicencing

[Mike Hommey]

On Fri, Mar 17, 2017 at 11:29:58PM +0100, Bastien ROUCARIES wrote:
> On Thu, Mar 16, 2017 at 5:56 PM, Luke W Faraone  wrote:
> > On Sun, 12 Mar 2017 21:28:30 +0100 Bastien ROUCARIES 
> >  wrote:
> >> Mike Hommey ask me to remove a lintian warning about a unicode file.
> >>
> >> I appear that chrome chan
> > ge the license text because unicode changed
> >> the license of distribued files.
> >>
> >> But the relicense is not retroactive and unicde consorcium removed
> >> before relicencing the offending file.
> >
> > Can you clarify which files specifically are in question?
> >
> > Just to make sure I understand, the order of operations was:
> 
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823100
> 
> > 1. Unicode distributed a project under a non-free license
> Yes it was base/ConvertUTF.c andbase/ConvertUTF.h. But whole
> project was non free in this epoc.
> 
> License was:
> 
>  This source code is provided as is by Unicode, Inc. No claims are made
>as to fitness for any particular purpose. No warranties of any kind are
>expressed or implied. The recipient agrees to determine applicability
>of information provided. If this file has been purchased on magnetic or
>optical media from Unicode, Inc., the sole remedy for any claim will be
>exchange of defective media within 90 days of receipt.
>.
>Limitations on Rights to Redistribute This Code
>.
>Unicode, Inc. hereby grants the right to freely use the information
>supplied in this file in the creation of products supporting the
>Unicode Standard, and to make copies of this file in any form for
>internal or external distribution as long as this notice remains
>attached.
> 
> At the very least, this license does not grant any permission
> to modify the files (thus failing DFSG#3). Moreover, the license grant
> seems to attempt to restrict use to "products supporting the Unicode
> Standard" (thus failing DFSG#6).
> 
> > 2. Unicode removed some of those files from the project
> Yes unicode removed this file
> 
> 
> Unfortunately, upstream seems to have _dropped_ the code due to being
> buggy and unmaintained since 2004, according to
> http://unicode.org/forum/viewtopic.php?f=9=90 - summarized at
> http://stackoverflow.com/questions/2685004/why-does-unicode-org-no-longer-offer-a-reference-utf-8-16-32-converter
> 
> 
> > 3. Unicode changed the license of the project to be DFSG-free
> 
> Yes but only to file offered to be downloaded on unicode website (and
> well after 2004):
> If Unicode Inc has published new versions of the two files in
> more recent times, the updated versions should be under the
> current unicode.org public license, as explained in
> http://www.unicode.org/copyright.html#Exhibit1
> 
> Therefore both files wer  not relicenced

See https://bugs.chromium.org/p/google-breakpad/issues/detail?id=270#c6

Moreover, the license agreement for data files and software was added in
2004: 
https://web.archive.org/web/20040402165154/http://www.unicode.org:80/copyright.html
and the files have been available (so under the new agreement) until 2009:
https://web.archive.org/web/20090529064329/http://www.unicode.org:80/Public/PROGRAMS/CVTUTF/

Mike

Bug#886064: iptux: Depends on gconf

[Jeremy Bicha]

Source: iptux
Version: 0.6.4-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#878811: dummy interface in bridge sticks in "configuring", leading to degraded system

[Michael Biebl]

Control: tags -1 + moreinfo

On Mon, 16 Oct 2017 21:57:15 +0200 Marc Haber
 wrote:
> Package: systemd
> Version: 235-2.0~zgSID+1
> Severity: normal
> Tags: upstream patch
> Forwarded: https://github.com/systemd/systemd/issues/6961
> 
> This is upstream issue 6961, where a dummy interface configured into a
> bridge gets stuck in "configuring" state, with the usual consequences of
> the network never getting "online", ultimately leading to a degraded
> system. Having a dummy interface in a bridge is a rather common idiom to
> force the bridge "up" even if there is nothing really "connected" yet.
> 
> I can confirm that the attached patch fixes the issue in systemd 235-2,
> and that it applies with minimal fuzz also applies to the systemd
> version in Debian stretch. Afaik, Susant Sahani, the developer of the
> patch, has submitted the patch, but it is not yet linked to the issue.

Hm, I don't see this patch applied in upstream systemd [1] but the
upstream issue has been closed.
Can you please verify if the issue still exists and if so, reopen the
upstream bug report.

Thanks,
Michael

[1] In case I missed it, can you point me at a git commit?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#868408: xnee: Please drop the (build-)dependency against gnome-vfs

[Henrik Sandklef]

I have removed deps to gnomeui (gconf had already been removed) from 
Xnee sources.


Can I assist you in any way?

/henrik - GNU Xnee maintainer

On 2017-12-31 14:28, Andreas Henriksson wrote:

Hello Vincent Bernat,

On Sat, Jul 15, 2017 at 11:04:51PM +0200, Vincent Bernat wrote:
[...]

As far as xnee is concerned, I can drop the Gnome frontend if it relies
on deprecated libs.


Please do this A.S.A.P!

The time is near when all the remaining unmaintained packages will
removed, and by leaving this issue unfixed xnee risks going out
with the rest.


Regards,
Andreas Henriksson

Bug#807041: 807041

[Michael Biebl]

On Sun, 13 Dec 2015 15:48:20 + "George B."  wrote:
> tags 807041 - moreinfo


This was closed upstream as being fixed.
Can you please retry if you still run into this issue with a recent
version of systemd.

Thanks,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#872562: Please provide a stable backport of biboumi

[W. Martin Borgert]

On 2017-08-18 18:33, Jonas Smedegaard wrote:
> I do not currently have any plans to get involved with the bpo 
> side-project of Debian.  Others are quite welcome to step up to do that.

OK, I made the backport (and use it already in my company).

I can't push my debian/stretch-backports branch, because I don't
have write permissions on the VoIP teams git. Could you add me
to the team for that or do you prefer a patch? Only
debian/changelog is changed, though.

Bug#886063: libgnomecanvas: Don't release with Buster

[Jeremy Bicha]

Source: libgnomecanvas
Version: 2.30.3-3
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs libgnomecanvas
Tags: sid buster

As announced [1], we do not intend to release Debian 10 "Buster" with
the old libgnome (and related) libraries.

libgnomecanvas is one of these unmaintained libraries.

[1] https://lists.debian.org/debian-devel/2017/10/msg00299.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885045: amide: Depends on old GNOME libraries

[Andreas Henriksson]

Hello amide maintainers,

Following up on my previous mail to #885045 which was a reply to Gert.

This is what I found when glancing over the code. Once digging in you
might find other things that also needs attention, but from the first
look it doesn't seem to be very much work to do the porting. Hope this
helps...

The gconf related code is in ./src/amide_gconf.c and it contains 3
versions (Windows, OSX and native GConf) that provide amide_gconf_* API
to the rest of the application code. I can't really help you out with
Windows or OSX, so only speaking for the last/native implementation. The
natural choice would be to port to GSettings, which is part of GLib.
AIUI given that gconf is going to be removed, you'll have no way to
migrate settings over since that needs gconf (or atleast not with the
gnome provided conversion method). I would recommend a NEWS.Debian entry
mentioning that user settings are lost and need to be reconfigured on
upgrade (which is unfortunate, but this migration should really have
happened around wheezy/old-old-stable already so not much we
can do about this now).
If you prefer to rename/change the amide_gconf_* name/interface the
callers are found in ./src/amitk_preferences.c and ./src/ui_series.c.

The usage of GnomeVFS is found in src/amide_gnome.c which boils down to
amide_gnome_url_show_with_env(...) implemented using
gnome_vfs_url_show_with_env (...).
For a replacement of gnome_vfs_url_show* you might want to have a look
at g_app_info_launch_default_for_uri (...). For an example see
gnome-open.c in src:libgnome, in particular
https://github.com/GNOME/libgnome/commit/65b35cbbc8d6021ee158a6657266bcbf0a9a81d2#diff-175f3047052f1df9261a604671a362f4
(where gnome_url_show is/was a libgnomeui wrapper around
gnome_vfs_url_show). (The GAppInfo/GIO functionality is also part of
GLib.)

FWIW, GNOMEs migration guide is available at
https://developer.gnome.org/gio/stable/migrating.html

I see Jeremy Bicha also mentioned gnomecanvas, which I haven't looked
into. That might warrant actually/finally looking into a full Gtk+ 3.x
porting effort. Getting rid of gconf and gnomevfs usage would be a good
start though and should likely be done before attempting a full Gtk+
2->3 port.

Regards,
Andreas Henriksson

Bug#885824: Patch to drop extra goffice dependencies

[Jeremy Bicha]

Control: tags 885824 +patch
From 79337ed16c3f6792bd8614fe2a090d343df57788 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Mon, 1 Jan 2018 18:05:53 -0500
Subject: [PATCH] Drop unnecessary dependencies

Closes: #885824
Closes: #886060
---
 debian/control | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/debian/control b/debian/control
index 8b76895..4ebf00d 100644
--- a/debian/control
+++ b/debian/control
@@ -8,7 +8,6 @@ Build-Depends: debhelper (>= 10) ,dpkg-dev (>= 1.16.1.1)
   ,intltool (>= 0.35.0)
   ,libcairo2-dev (>= 1.10.0)
   ,libcairo2-doc
-  ,libgconf2-dev
   ,libgirepository1.0-dev
   ,libglib2.0-dev (>= 2.28.0)
   ,libglib2.0-doc
@@ -36,8 +35,6 @@ Depends: ${misc:Depends}
 ,gir1.2-goffice-0.10 (= ${binary:Version})
 ,libgoffice-0.10-10 (= ${binary:Version})
 ,libcairo2-dev
-,libgconf2-dev
-,libglade2-dev
 ,libglib2.0-dev
 ,libgtk-3-dev
 ,libgsf-1-dev (>= 1.14.25-2)
-- 
2.14.1

Bug#886062: codeblocks: Please consider updating to codeblocks 17.12

[Svein Engelsgjerd]

Package: codeblocks
Version: 16.01+dfsg-2.1
Severity: wishlist

Dear Maintainer,

Please consider upgrading to codeblocks 17.12 which amongst other things should 
work better with wx3, thanks.

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages codeblocks depends on:
ii  codeblocks-common  16.01+dfsg-2.1
ii  libc6  2.25-3
ii  libcodeblocks0 16.01+dfsg-2.1
ii  libgcc11:7.2.0-18
ii  libglib2.0-0   2.54.1-1
ii  libstdc++6 7.2.0-18
ii  libwxbase3.0-0v5   3.0.3.1+dfsg2-1
ii  libwxgtk3.0-0v53.0.3.1+dfsg2-1

Versions of packages codeblocks recommends:
ii  g++4:7.2.0-1d1
ii  gcc4:7.2.0-1d1
ii  gdb7.12-6+b1
ii  xterm  330-2

Versions of packages codeblocks suggests:
ii  codeblocks-contrib  16.01+dfsg-2.1
ii  libwxgtk3.0-dev 3.0.3.1+dfsg2-1

-- no debconf information

Bug#886061: git-buildpackage: import-orig doesn't sign anymore commits on non-master branches

[Mattia Rizzolo]

Package: git-buildpackage
Version: 0.9.5

Since some time (long time actually, but I never got around to report
it, probably even a whole year) `gbp import-orig` is not signing the
commits in the upstream and pristine-tar branches, despite me having
commit.pgpsign = true
in my ~/.gitconfig.

I'm very sure it used to sign everything in the past, so I don't really
understand why it stopped, but even if it wasn't a regression I'd still
call it a bug that it's overriding my git config :)

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#886060: libgoffice-0.10-dev: Unnecessary depends on gconf

[Jeremy Bicha]

Package: libgoffice-0.10-dev
Version: 0.10.35-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster patch

It looks like your package has an unnecessary Build-Depends and Depends
on libgconf2-dev

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885023: gnome-shell: spams syslog with "e_cal_recur_generate_instances_sync: assertion 'icaltime_compare (interval_start, interval_end) < 0' failed"

[Simon McVittie]

Control: reassign 885023 evolution-data-server 3.26.2.1-1

On Mon, 01 Jan 2018 at 20:42:29 +0100, Martin Bergström wrote:
> Bug resolved when upgrading evolution to 3.26.3-1 and/or
> evolution-data-server to 3.26.3-4 when they entered testing.

In that case I'll close this bug after the reassign command has been
processed.

smcv

Bug#886036: Improve changelog version parsing

[Felix Lechner]

Dear Chris,

On Mon, Jan 1, 2018 at 1:41 PM, Chris Lamb  wrote:
> (Could you push these to a Git repository somewhere? That would make
> them easier to apply... Thanks in advance!)

Please have a look at https://github.com/lechner/lintian. The repo
contains my locally synchronized copy of your master as well as my
branch 'improve-changelog-version-parsing'. Each commit passes all
tests and is perl-tidy.

Unfortunately, I annotated the patches manually in greater detail. You
may wish to consult them. The upshot is:

Many version checks happen on binary packages in
checks/changelog-file.pm, although they may be more helpful on source
packages. Per suggestion from Paul Wise, one could check that binary
packages ship with the source changelog. If the maintainers are
receptive to part of this patch series, the author would be happy help
consolidate further checks in checks/source-changelog. Thank you!

Best regards,
Felix

Bug#886059: jana: Depends on gconf

[Jeremy Bicha]

Source: jana
Version: 0.0.0+git20091215.9ec1da8a-4
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885852: [sparc64] klibc-utils (2.0.4-10) regression, sigserv with fstype

[James Clarke]

Control: severity -1 important

On Sat, Dec 30, 2017 at 03:48:07PM +0300, Anatoly Pugachev wrote:
> Package: klibc-utils
> Version: 2.0.4-10
> Severity: normal
>
> Dear Maintainer,
>
> Upgrading klibc-utils from 2.0.4-9 to 2.0.4-10 started to produce sigserv in 
> fstype
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> using latest version 2.0.4-10 :
>
> $ dpkg -l klibc-utils
> ||/ Name   VersionArchitecture
>Description
> +++-==-==-==-=
> ii  klibc-utils2.0.4-10   sparc64 
>small utilities built with klibc for early boot
>
> $ /usr/lib/klibc/bin/fstype
> Segmentation fault (core dumped)
>
> $ sudo /usr/lib/klibc/bin/fstype /dev/vdiska2
> Segmentation fault
>
> I tried with upstream klibc.git repo, but getting sigserv as well, and since
> klibc.git does not have changed files almost a year now, not sure gdb 
> backtrace
> could be relevant, please see
> http://www.zytor.com/pipermail/klibc/2017-December/003965.html
>
>
>* What outcome did you expect instead?
>
> using older package version of 2.0.4-9 :
>
> # dpkg -i *.deb
> dpkg: warning: downgrading klibc-utils from 2.0.4-10 to 2.0.4-9
> (Reading database ... 68475 files and directories currently installed.)
> Preparing to unpack klibc-utils_2.0.4-9_sparc64.deb ...
> Unpacking klibc-utils (2.0.4-9) over (2.0.4-10) ...
> dpkg: warning: downgrading libklibc from 2.0.4-10 to 2.0.4-9
> Preparing to unpack libklibc_2.0.4-9_sparc64.deb ...
> Unpacking libklibc (2.0.4-9) over (2.0.4-10) ...
> Setting up libklibc (2.0.4-9) ...
> Setting up klibc-utils (2.0.4-9) ...
> root@ttip:~/1# exit
>
> mator@ttip:~/linux-2.6$ dpkg -L klibc-utils | grep fstype
> /usr/lib/klibc/bin/fstype
>
> mator@ttip:~/linux-2.6$ /usr/lib/klibc/bin/fstype
> stdin: Illegal seek
>
> mator@ttip:~$ dpkg -l klibc-utils
> ||/ Name   VersionArchitecture
>Description
> +++-==-==-==-=
> ii  klibc-utils2.0.4-9sparc64 
>small utilities built with klibc for early boot
>
> mator@ttip:~$ sudo /usr/lib/klibc/bin/fstype /dev/vdiska2
> FSTYPE=ext4
> FSSIZE=15002910720

Please consider applying the patch forwarded upstream (linked in an
earlier control message) soon; this bug means that if the current
initramfs is updated, it will no longer boot, as run-init will segfault
in klibc. Given sparc64 is not a release architecture I can't make this
bug RC, otherwise I'd probably go for critical.

(To be clear, the issue is in 2.0.4-10 simply because that is the first
upload to happen since sparc64 has had PIE enabled by default in GCC)

Regards,
James

Bug#885974: lintian: warn about non-git Vcs fields

[Mattia Rizzolo]

Control: clone -1 -2
Control: retitle -2 lintian: warn about 
orphaned-package-not-maintained-in-debian.org-infrastracture

On Mon, Jan 01, 2018 at 10:13:32PM +, Chris Lamb wrote:
> > > it would be a bit wrong to have Vcs-Svn actually point to a git repo…
> > Yes please start warning (not pedantic) now about Vcses hosted at
> > {anonscm,alioth,svn,bzr,hg,darcs,arch}.debian.org.
> 
> Non-sequitur? As I read it, Jeremy's comment was about mismatches.

TBH, I don't fully follow all of Jeremy's message.

> However, could you provide an initial description for the case of
> {anonscm,alioth,svn,bzr,hg,darcs,arch}.debian.org?

Tag: vcs-not-git-hosted-in-debian.org-infrastructure
Severity: normal
Certainty: certain
Info:
 The specified VCS is not Git but is nonetheless hosted in the
 *.debian.org infrastructure.
 .
 Alioth, the historical Debian forge, has been deprecated, and from now
 on only Git is supported and repositories are hosted on
 https://salsa.debian.org.
 .
 If you with to keep the packaging repository on another VCS you should
 move it elsewhere off the Debian official infrastructure; otherwise
 please convert your repository to Git and update the Vcs-* fields to
 point to the new URI.

Possible ref: 
https://lists.debian.org/debian-devel-announce/2017/08/msg8.html

Incredible as it may seem, there was no actual announce email saying
"hey, alioth is deprecated!"... so I wouldn't know where to point people
to.

Note that, differnetly from vcs-field-bitrotted matches, there are still
chances that there will be a read-only export of alioth after its
deprecation.

This is my suggestion for the -1 bug (#885974)

> > > What about QA packages? Maybe those at least should be using git
> > > hosted with Debian.
> > 
> > In general, I'd just warn about
> > orphaned-package-not-maintained-in-debian.org-infrastracture 
> 
> Fancy retitling this bug for the above and cloning another for this
> one? :)

So this is going to be -2:

Tag: orphaned-package-not-maintained-in-debian.org-infrastracture
Severity: normal
Certainty: certain
Info:
 This package is orphaned, and therefore all the wide Debian community
 collaborate to its maintenance, but the specified VCS field does not
 point to an area within the *.debian.org infrastructure, hence
 preventing other Debian Developer and external contributors to commit
 to its repository.
 .
 The specified VCS field is either stale from the time before it was
 orphaned, or otherwise wrong.

I can see how this wording has many (also grammatical) problems, but
I'm sure you'll be able to get something nice out of it.
Also feel free to rename the tag, perhaps making it start with 'vcs-' to
match other tags also checking the VCS fields.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#883341: slic3r: Missing dependencies: wx-common, libopengl-perl, libwx-glcanvas-perl

[Adrian Bunk]

Control: found -1 1.2.9+dfsg-6.1
Control: severity -1 wishlist

On Sat, Dec 02, 2017 at 05:00:26PM +0100, Antonio Trueba Gayol wrote:
> Package: slic3r
> Version: 1.2.9+dfsg-8
> Severity: grave
> Justification: renders package unusable
> 
> Dear Maintainer,
> 
> After installation, slic3r gui fails to start due to missing dependencies.
> Installing the following packages solves the problem:
> 
> - wx-common
> - libopengl-perl
> - libwx-glcanvas-perl
>...
> Versions of packages slic3r recommends:
> pn  libclass-xsaccessor-perl  
> pn  libio-all-perl
> ii  libopengl-perl0.7000+dfsg-1
> pn  libpdf-api2-perl  
> pn  libsvg-perl   
> ii  libwx-glcanvas-perl   0.09-3+b5
> ii  libwx-perl1:0.9932-2
> pn  libxml-sax-expatxs-perl   
>...

Thanks for your report.

The missing packages are recommended.

They are only recommended since the non-GUI functionality of the package 
does work without these packages.

Whether these should be recommends or dependencies is a valid question, 
and as far as I can see both choices would be reasonable maintainer[1] 
choices in this case.

cu
Adrian

[1] I am not the maintainer of slic3r

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#883869: e2fsprogs: debugfs doesn't write group descriptor with block bitmap checksum modified

[Theodore Ts'o]

On Fri, Dec 08, 2017 at 07:33:58PM +0300, Nikita Maslov wrote:
> Package: e2fsprogs
> Version: 1.43.7-1
> Severity: normal
> 
> I found a problem with debugfs (but it may be a problem with the whole
> e2fslibs) when trying to mark block bitmap.  It looks like group
> descriptor which is modified with 
> 
> Steps to reproduce this:
> 
>1. Create a new ext4 filesystem image:
>   $ dd if=/dev/zero of=/tmp/testfs.img bs=1K count=4096
>   $ /sbin/mkfs.ext4 /tmp/testfs.img
>2. Open this image with debugfs, set some free block's mark and close
>debugfs:
>   $ /sbin/debugfs -w /tmp/testfs.img
>   debugfs: ffb
>   Free blocks found: 1204
>   debugfs: setb 1204
>   debugfs: q
>   $
>3. Try to open this image again with debugfs:
>   $ /sbin/debugfs /tmp/testfs.img
>   /tmp/testfs.img: Block bitmap checksum does not match bitmap while 
> reading block bitmap

So this is one of these interesting philosophical questions about how
low-level debugfs is supposed to be.  The setb/clearb/seti/setb
commands are extremely low level, so they do *not* update the block
group descriptor's checksums.

You can update the block group descriptor's checksum by hand via
the set_bg command.

Yes, this is annoyingly manual.  But part of this is a question over
what the intended users of debugfs is supposed to be.  It was
originally intended to be used by ext4 developers to create corrupted
file system images, and to do low-level file system debugging.  But it
is now also used by system administrators, and in some cases by
embedded systems developers who use debugfs to populate prebuilt file
system images (say, as part of Android system image builds, for
example).

This situation has come up before, and this is why in addition to the
"unlink" (which _just_ removes the directory entry, or "link" for a
particular file), and "kill_file" (which deallocates an inode and
updates the block bitmaps -- and also updates the checksums, by the
way), and "rm" (which acts like the rm command --- removes a directory
entry, it drops the inode's link_count, and if the link_count goes to
zero, calls "kill_file").

The "rm" command is the user-friendly command intended for civilian
use cases, where as the "unlink" and "kill_file" are intended for ext4
developers who want to do something extremely targetted.

One approach would be to create a civilian-friendly version of "setb",
but it's not clear to me why civillians would be using setb directly
in the first place.  Another approach might be to create a mode which
automatically updates the block group descriptor's checksum fields
automatically.  At the very least I should add the ability to say,
"set_bg 0 block_bitmap_csum calc", which currently only works for the
"set_bg 0 checksum calc" case.

By the way, you can open a file system bad checksum values by using
the debugfs -n command.

Cheers,

- Ted

Bug#886055: mssh: Depends on gconf

[Jeremy Bicha]

Source: mssh
Version: 2.2-4
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886054: RM: specto -- RoM; RoQA; unmaintained, depends on gnome-python

[Jeremy Bicha]

Package: ftp.debian.org
User: release.debian@packages.debian.org
Usertags: rm
X-Debbugs-Cc: spe...@packages.debian.org

Please remove specto from Debian.

specto is no longer maintained upstream. [1]

specto is now blocking the removal of the unmaintained gnome-python
library. [2]

I got approval from the Debian maintainer Christopher James Halse
Rogers before filing this bug.

[1] http://fortintam.com/blog/2013/03/21/a-programs-obsolescence/
[2] https://bugs.debian.org/790605

Thanks,
Jeremy Bicha

Bug#886056: morris: Depends on gconf

[Jeremy Bicha]

Source: morris
Version: 0.2-3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886053: override: libudev1:libs/optional

[Michael Biebl]

Package: ftp.debian.org
Severity: normal

With the recent changes in debian policy, libudev1 is now flagged as
https://lintian.debian.org/tags/excessive-priority-for-library-package.html

Please downgrade libudev1 to optional.
I'll make the corresponding change in debian/control in the next upload.

Thanks,
Michael

Bug#886052: ogmrip: Depends on gconf

[Jeremy Bicha]

Source: ogmrip
Version: 1.0.1-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886051: ooo-thumbnailer: Depends on gconf

[Jeremy Bicha]

Source: ooo-thumbnailer
Version: 0.2-5
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885423: [Pkg-opencl-devel] Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

[Achim Schaefer]

Here I see something different:
displacement_map_element()    [SUCCESS]
compiler_mandelbrot()utest_run:
/build/beignet-ydQSQk/beignet-1.3.2/utests/utest_helper.cpp:713: void
cl_write_bmp(const int*, int, int, const char*): Assertion `fp' failed.
    Interrupt signal (SIGABRT) received.
summary:
--
  total: 1000
  run: 317
  pass: 316
  fail: 1
  pass rate: 0.996845

Full output attached.

Achim

On 01.01.2018 23:22, Rebecca N. Palmer wrote:
> The lack of failures is strange - does the original bug still exist?
> (beignet hasn't changed, but it might be elsewhere.)  Does
> /usr/lib/x86_64-linux-gnu/beignet/utest_run without
> OCL_IGNORE_SELF_TEST also report "self-test failed"?
>

platform number 1
platform_profile "FULL_PROFILE"
platform_name "Intel Gen OCL Driver"
platform_vendor "Intel"
platform_version "OpenCL 2.0 beignet 1.3"
platform_extensions "cl_khr_global_int32_base_atomics 
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics 
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store 
cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images 
cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups 
cl_intel_subgroups_short cl_khr_gl_sharing"
device_profile "FULL_PROFILE"
device_name "Intel(R) HD Graphics Haswell GT2 Desktop"
device_vendor "Intel"
device_version "OpenCL 1.2 beignet 1.3"
device_extensions "cl_khr_global_int32_base_atomics 
cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics 
cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store 
cl_khr_3d_image_writes cl_khr_image2d_from_buffer cl_khr_depth_images 
cl_khr_spir cl_khr_icd cl_intel_accelerator cl_intel_subgroups 
cl_intel_subgroups_short cl_khr_gl_sharing"
device_opencl_c_version "OpenCL C 1.2 beignet 1.3"
27 image formats are supported
[CL_R CL_UNORM_INT8]
[CL_R CL_UNORM_INT16]
[CL_R CL_SIGNED_INT8]
[CL_R CL_SIGNED_INT16]
[CL_R CL_SIGNED_INT32]
[CL_R CL_UNSIGNED_INT8]
[CL_R CL_UNSIGNED_INT16]
[CL_R CL_UNSIGNED_INT32]
[CL_R CL_HALF_FLOAT]
[CL_R CL_FLOAT]
[CL_RG CL_UNORM_INT8]
[CL_RG CL_UNORM_INT16]
[CL_RG CL_UNSIGNED_INT8]
[CL_RG CL_UNSIGNED_INT16]
[CL_RGBA CL_UNORM_INT8]
[CL_RGBA CL_UNORM_INT16]
[CL_RGBA CL_SIGNED_INT8]
[CL_RGBA CL_SIGNED_INT16]
[CL_RGBA CL_SIGNED_INT32]
[CL_RGBA CL_UNSIGNED_INT8]
[CL_RGBA CL_UNSIGNED_INT16]
[CL_RGBA CL_UNSIGNED_INT32]
[CL_RGBA CL_HALF_FLOAT]
[CL_RGBA CL_FLOAT]
[CL_BGRA CL_UNORM_INT8]
[CL_sRGBA CL_UNORM_INT8]
[CL_sBGRA CL_UNORM_INT8]
builtin_acos_float()[SUCCESS]
builtin_acos_float2()[SUCCESS]
builtin_acos_float4()[SUCCESS]
builtin_acos_float8()[SUCCESS]
builtin_acos_float16()[SUCCESS]
builtin_acosh_float()[SUCCESS]
builtin_acosh_float2()[SUCCESS]
builtin_acosh_float4()[SUCCESS]
builtin_acosh_float8()[SUCCESS]
builtin_acosh_float16()[SUCCESS]
builtin_acospi_float()[SUCCESS]
builtin_acospi_float2()[SUCCESS]
builtin_acospi_float4()[SUCCESS]
builtin_acospi_float8()[SUCCESS]
builtin_acospi_float16()[SUCCESS]
builtin_asin_float()[SUCCESS]
builtin_asin_float2()[SUCCESS]
builtin_asin_float4()[SUCCESS]
builtin_asin_float8()[SUCCESS]
builtin_asin_float16()[SUCCESS]
builtin_asinh_float()[SUCCESS]
builtin_asinh_float2()[SUCCESS]
builtin_asinh_float4()[SUCCESS]
builtin_asinh_float8()[SUCCESS]
builtin_asinh_float16()[SUCCESS]
builtin_asinpi_float()[SUCCESS]
builtin_asinpi_float2()[SUCCESS]
builtin_asinpi_float4()[SUCCESS]
builtin_asinpi_float8()[SUCCESS]
builtin_asinpi_float16()[SUCCESS]
builtin_atan_float()[SUCCESS]
builtin_atan_float2()[SUCCESS]
builtin_atan_float4()[SUCCESS]
builtin_atan_float8()[SUCCESS]
builtin_atan_float16()[SUCCESS]
builtin_atan2_float()[SUCCESS]
builtin_atan2_float2()[SUCCESS]
builtin_atan2_float4()[SUCCESS]
builtin_atan2_float8()[SUCCESS]
builtin_atan2_float16()[SUCCESS]
builtin_atanh_float()[SUCCESS]
builtin_atanh_float2()[SUCCESS]
builtin_atanh_float4()[SUCCESS]
builtin_atanh_float8()[SUCCESS]
builtin_atanh_float16()[SUCCESS]
builtin_atanpi_float()[SUCCESS]
builtin_atanpi_float2()[SUCCESS]
builtin_atanpi_float4()[SUCCESS]
builtin_atanpi_float8()[SUCCESS]
builtin_atanpi_float16()[SUCCESS]
builtin_atan2pi_float()[SUCCESS]
builtin_atan2pi_float2()[SUCCESS]
builtin_atan2pi_float4()[SUCCESS]
builtin_atan2pi_float8()[SUCCESS]
builtin_atan2pi_float16()[SUCCESS]
builtin_cbrt_float()[SUCCESS]
builtin_cbrt_float2()[SUCCESS]
builtin_cbrt_float4()[SUCCESS]
builtin_cbrt_float8()[SUCCESS]
builtin_cbrt_float16()[SUCCESS]
builtin_ceil_float()[SUCCESS]
builtin_ceil_float2()[SUCCESS]
builtin_ceil_float4()[SUCCESS]
builtin_ceil_float8()[SUCCESS]
builtin_ceil_float16()[SUCCESS]
builtin_copysign_float()[SUCCESS]
builtin_copysign_float2()[SUCCESS]
builtin_copysign_float4()[SUCCESS]
builtin_copysign_float8()[SUCCESS]
builtin_copysign_float16()[SUCCESS]

Bug#886049: [linux-image-4.14.0-2-amd64] Function g_file_copy() from libglib2.0-0 hangs when copying small files from CIFS-Share. This is relevant for Thunar filemanager.

[reiny]

Package: linux-image-4.14.0-2-amd64
Version: 4.14.0-2-amd64
Severity: critical

--- Please enter the report below this line. ---

The function g_file_copy() from libglib2.0-0 hangs when copying a small
file from a mounted CIFS-Share. Since the thunar filemanager is using
this function to copy files, the whole copy process hangs and the
progress bar does not close again. I built a debug version of thunar
and found with gdb that the function g_file_copy() uses the systemcall
splice(). There seems to bee the problem. When Thunar hangs the
debugger gives the following output:

[debug]> thread 4
[debug][Switching to thread 4 (Thread 0x7fffe7fff700 (LWP 8037))]
[debug]#0  0x74a2f2a3 in splice () at 
../sysdeps/unix/syscall-template.S:84
[debug]84   in ../sysdeps/unix/syscall-template.S
[debug]>>cb_gdb:
[debug]> bt 30
[debug]#0  0x74a2f2a3 in splice () at 
../sysdeps/unix/syscall-template.S:84
[debug]#1  0x754b3cae in  () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
[debug]#2  0x754ba44c in g_file_copy () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
[debug]#3  0x55613619 in ttj_copy_file (job=0x55980370, 
source_file=0x55c99440, target_file=0x55cd9ae0, 
copy_flags=G_FILE_COPY_NOFOLLOW_SYMLINKS, merge_directories=1, 
error=0x7fffe7ffe8e0) at thunar-transfer-job.c:396
[debug]#4  0x55613a28 in thunar_transfer_job_copy_file 
(job=0x55980370, source_file=0x55c99440, target_file=0x55cd9ae0, 
error=0x7fffe7ffe980) at thunar-transfer-job.c:518
[debug]#5  0x55613f4e in thunar_transfer_job_copy_node 
(job=0x55980370, node=0x559ddce0, target_file=0x55cd9ae0, 
target_parent_file=0x559c3680, target_file_list_return=0x0, 
error=0x7fffe7ffea30) at thunar-transfer-job.c:655
[debug]#6  0x55613fc4 in thunar_transfer_job_copy_node 
(job=0x55980370, node=0x559c3a80, target_file=0x559c3680, 
target_parent_file=0x0, target_file_list_return=0x7fffe7ffeac8, 
error=0x7fffe7ffeac0) at thunar-transfer-job.c:671
[debug]#7  0x55614d62 in thunar_transfer_job_execute 
(job=0x55980370, error=0x7fffe7ffeb60) at thunar-transfer-job.c:1062
[debug]#8  0x779ae08d in exo_job_scheduler_job_func 
(scheduler_job=0x55c02080, cancellable=, 
user_data=) at exo-job.c:317
[debug]#9  0x754cfc96 in  () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
[debug]#10 0x754f6cf6 in  () at 
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
[debug]#11 0x74f76000 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
[debug]#12 0x74f75635 in  () at /lib/x86_64-linux-gnu/libglib-2.0.so.0
[debug]#13 0x74cec519 in start_thread (arg=0x7fffe7fff700) at 
pthread_create.c:456
[debug]#14 0x74a2ea4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97
[debug]>>cb_gdb:
[debug]> if 1
disassemble $pc,$pc+50
info frame
end
[debug] > > >Dump of assembler code from 0x74a2f2a3 to 0x74a2f2d5:
[debug]=> 0x74a2f2a3 :   movrdi,QWORD PTR [rsp]
[debug]   0x74a2f2a7 :   movrdx,rax
[debug]   0x74a2f2aa :   call   0x74a3b690 
<__libc_disable_asynccancel>
[debug]   0x74a2f2af :   movrax,rdx
[debug]   0x74a2f2b2 :   addrsp,0x8
[debug]   0x74a2f2b6 :   cmprax,0xf001
[debug]   0x74a2f2bc :   jae0x74a2f2bf 

[debug]   0x74a2f2be :   ret
[debug]   0x74a2f2bf :   movrcx,QWORD PTR 
[rip+0x2afbb2]# 0x74cdee78
[debug]   0x74a2f2c6 :   negeax
[debug]   0x74a2f2c8 :   movDWORD PTR fs:[rcx],eax
[debug]   0x74a2f2cb :   or rax,0x
[debug]   0x74a2f2cf :   ret
[debug]   0x74a2f2d0 :   moveax,0x63
[debug]End of assembler dump.
[debug]Stack level 0, frame at 0x7fffe7ffe610:
[debug] rip = 0x74a2f2a3 in splice (../sysdeps/unix/syscall-template.S:84); 
saved rip = 0x754b3cae
[debug] called by frame at 0x7fffe7ffe660
[debug] source language asm.
[debug] Arglist at 0x7fffe7ffe5f8, args: 
[debug] Locals at 0x7fffe7ffe5f8, Previous frame's sp is 0x7fffe7ffe610
[debug] Saved registers:
[debug]  rip at 0x7fffe7ffe608
[debug]>>cb_gdb:
[debug]> disassemble /m 0x74a2f2a3
[debug]Dump of assembler code for function splice:
[debug]84   in ../sysdeps/unix/syscall-template.S
[debug]   0x74a2f270 <+0>:  cmpDWORD PTR [rip+0x2b5489],0x0 
   # 0x74ce4700 <__libc_multiple_threads>
[debug]   0x74a2f277 <+7>:  jne0x74a2f28c 
[debug]   0x74a2f279 <+0>:  movr10,rcx
[debug]   0x74a2f27c <+3>:  moveax,0x113
[debug]   0x74a2f281 <+8>:  syscall 
[debug]   0x74a2f283 <+10>: cmp

Bug#677870: lintian: Shouldn't warn about unknown template type "entropy" when a package depends on cdebconf

[Chris Lamb]

tags 677870 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=d97ace49e3146f1274195174093dd001eab9b66b


Regards,

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

Bug#886050: openbox-gnome-session: Depends on gconf

[Jeremy Bicha]

Package: openbox-gnome-session
Version: 3.6.1-5
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster patch

openbox-gnome-session has an apparently unnecessary dependency on
gconf2. gconf will be removed from Debian soon. (No actual patch
attached because this seems trivial to fix.)

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 ) It shouldn't be
necessary for openbox to directly depend on that either unless it's
specifically working with gsettings.

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886048: plasma-pa: Depends on gconf

[Jeremy Bicha]

Source: plasma-pa
Version: 4:5.10.5-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

I assume this depends on pulseaudio.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#883539: metastore: New upstream version (1.1.1) with important bugfix has been released

[Romain Francoise]

Hi,

Sorry for the delay, and thank you for the reminder. I have looked into
updating the package with your new upstream, however the tarball
contains a .gitignore file that ignores the debian/ directory. This
makes it difficult to work with the pristine source under Git, which is
my preferred workflow.

Can you release a 1.1.2 tarball without this line in .gitignore?
Alternatively, I can repack the tarball myself and use a +ds1 suffix for
the version, but I imagine that this would not be your preferred option.

Thanks!
-- 
Romain Francoise 
https://people.debian.org/~rfrancoise/

Bug#886046: soundconverter: Depends on gconf

[Jeremy Bicha]

Source: soundconverter
Version: 3.0.0~beta1-2
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886017: RM: seelablet/1.0.6-2

[Adam D. Barratt]

Control: retitle -1 RM: seelablet -- RoM; abandoned upstream; broken
Control: clone -1 -2
Control: tags -1 + stretch
Control: reassign -2 ftp.debian.org

On Mon, 2018-01-01 at 23:20 +0100, Georges Khaznadar wrote:
> Hi Adam,
> 
> thank you for the fast response.
> 
> Adam D. Barratt a écrit :
> > Control: tags -1 + moreinfo
> > 
> > On Mon, 2018-01-01 at 18:24 +0100, Georges Khaznadar wrote:
> > > abandoned upstream, and other bugs (#885875,
> > > #885876, #885877)
> > 
> > To be clear, which suite(s) are you requesting that the package be
> > removed from?
> 
> With the agreement of the upstream developer, this package can be
> removed from all suites, which includes: stretch, buster and sid.

Removal from unstable is (as ever) handled by the FTP team, so cloning
and reassigning to them; removal from testing will automatically follow
once that happens.

Regards,

Adam

Bug#880483: e2fsprogs: e4crypt add_key requires salt, manpage does not describe it

[Theodore Ts'o]

On Wed, Nov 01, 2017 at 03:05:44AM +0100, Daniel Kahn Gillmor wrote:
> Package: e2fsprogs
> Version: 1.43.7-1
> Severity: normal
> 
> e4crypt(8) says:
> 
> e4crypt add_key -S [ -k keyring ] [-v] [-q] [  path ... ]
> 
> but "e4crypt add_key -h" says:
> 
> e4crypt add_key -S salt [ -k keyring ] [-v] [-q] [ path ... ]
> 
> (note that presence of salt).
> 
> neither of these documentation locations describes what format the
> salt should take, or whether it references any particular type of
> salt.
> 
> Please make the documentation match the executable!

Thanks for the bug report.  I've checked in a fix and a man page
update will be in the next release of e2fsprogs.

  - Ted

commit 18e921a5a0916159742c2ba6a8d7191db590d44c
Author: Theodore Ts'o 
Date:   Mon Jan 1 16:29:56 2018 -0500

Add documentation for e4crypt's add_key command in the man page

Correctly document that the -S option takes an argument, and describe
what arguments to the -S, -k, and -p options.

Addresses-Debian-Bug: #880483

Signed-off-by: Theodore Ts'o 

diff --git a/misc/e4crypt.8.in b/misc/e4crypt.8.in
index 169ab587d..75b968a0f 100644
--- a/misc/e4crypt.8.in
+++ b/misc/e4crypt.8.in
@@ -14,14 +14,41 @@ e4crypt \- ext4 filesystem encryption utility
 performs encryption management for ext4 file systems.
 .SH COMMANDS
 .TP
-.B e4crypt add_key -S \fR[\fB -k \fIkeyring\fR ] [\fB-v\fR] [\fB-q\fR] \fR[\fB 
-p \fIpad\fR ] [ \fIpath\fR ... ]
+.B e4crypt add_key \fR[\fB-vq\fR] [\fB-S\fI salt\fR ] [\fB-k \fIkeyring\fR ] 
[\fB -p \fIpad\fR ] [ \fIpath\fR ... ]
 Prompts the user for a passphrase and inserts it into the specified
 keyring.  If no keyring is specified, e4crypt will use the session
 keyring if it exists or the user session keyring if it does not.
 .IP
+The
+.I salt
+argument is interpreted in a number of different ways, depending on how
+its prefix value.  If the first two characters are "s:", then the rest
+of the argument will be used as an text string and used as the salt
+value.  If the first two characters are "0x", then the rest of the
+argument will be parsed as a hex string as used as the salt.  If the
+first characters are "f:" then the rest of the argument will be
+interpreted as a filename from which the salt value will be read.  If
+the string begins with a '/' character, it will similarly be treated as
+filename.  Finally, if the
+.I salt
+argument can be parsed as a valid UUID, then the UUID value will be used
+as a salt value.
+.IP
+The
+.I keyring
+argument specifies the keyring to which the key should be added.
+.IP
+The
+.I pad
+value specifies the number of bytes of padding will be added to
+directory names for obfuscation purposes.  Valid
+.I pad
+values are 4, 8, 16, and 32.
+.IP
 If one or more directory paths are specified, e4crypt will try to
-set the policy of those directories to use the key just entered by
-the user.
+set the policy of those directories to use the key just added by the
+.B add_key
+command.
 .TP
 .B e4crypt get_policy \fIpath\fR ...
 Print the policy for the directories specified on the command line.

Bug#885423: [Pkg-opencl-devel] Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

[Rebecca N. Palmer]

The lack of failures is strange - does the original bug still exist? 
(beignet hasn't changed, but it might be elsewhere.)  Does 
/usr/lib/x86_64-linux-gnu/beignet/utest_run without OCL_IGNORE_SELF_TEST 
also report "self-test failed"?

Bug#886045: stardict: Depends on gconf

[Jeremy Bicha]

Source: stardict
Version: 3.0.1-9.3
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#648755: lintian: arch-dep-package-has-big-usr-share is probably to eager.

[Chris Lamb]

tags 648755 + pending
thanks

Fixed in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=355b9822b50a63f38c7da7a6a576eef711f81b49


Regards,

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

Bug#885436: /var/log/aptitude shows wrong architecture for architecture:all packages

[Marvin Renich]

* David Kalnischkies  [180101 15:48]:
> On Thu, Dec 28, 2017 at 12:45:14AM +0100, Manuel A. Fernandez Montecelo wrote:
> > > In the extremely rare (I think) case where an upgrade (or downgrade)
> > > replaces a specific architecture package with an architecture all
> > > package, or vice versa, I would be okay with my script breaking because
> > > it does not have enough information from /var/log/aptitude to get it
> > > right.  E.g. I think it is okay to arbitrarily choose one architecture
> > > or the other, but I think it is more useful to know the architecture of
> > > the package being replaced than that of the one being installed.
> > 
> > I wonder if it's because apt treats internally :all packages as the
> > native arch, but it doesn't make much sense, I think that the string
> > printed should still be :all.
> 
> The architecture for a package in apt is never 'all' as this isn't
> a property of the package for preciously the reason Marvin outlines as
> "extremely rare" case – it just isn't that rare.

[good explanation snipped]

Thanks for the explanation.  However, I believe that the log file should
still identify the architecture as specified in the control file, rather
than the architecture that apt is using for dependency and upgrade
resolution.  The log file is used by the human (or a script) after the
fact to identify what happened; it is irrelevant in that context that
aptitude internally substitutes the default dpkg architecture for
arch:all packages in aptitude's internal processing.

Even if you think it is not irrelevant, it is much easier for a human or
script to take pkg-name:all from the log and deduce that aptitude used
pkg-name:amd64 in its processing than it is for a human or script to see
pkg-name:amd64 in the log and then try to determine if it is really
pkg-name:amd64 or was originally pkg-name:all.

IOW, using pkg-name:amd64 in the log loses information that is harder to
recover, while using pkg-name:all hides an internal detail of aptitude's
processing that is trivial to obtain.

...Marvin

Bug#885045: amide: Please drop the (build-)dependency against gnome-vfs

[Andreas Henriksson]

Control: forcemerge 868383 885045

Hello Gert Wollny,

Thanks for followuping up on the bug report.

On Sun, Sep 24, 2017 at 02:29:41PM +0200, Gert Wollny wrote:
> amide pulls in gnome-vfs via libgnomeui and calls gnome-vfs also

In fact amide doesn't seem to need libgnomeui at all. It's just that the
package has the build-dependencies incorrectly specified (which itself
is an RC issue).
What amide actually needs (instead of libgnomeui-dev, which happens to
pull these in for you) is libgconf2-dev and libgnomevfs2-dev.

Given both GConf and GnomeVFS are deprecated and destined for removal
for Buster. It's an 'all or nothing' kind of situation and there's
already an open bug report mentioning the lot, so I'm going to merge
this bug report into "#885045 amide: Depends on old GNOME libraries".
Lets continue continue the discussion there...

> directly. Unless upstream is changing this I don't see that there is a
> good chance to remove this dependency. 

Based on the activity in the upstream repo it doesn't look like you
can rely on upstream solving this for you unfortunately
If there's no hope for the porting to get done at all then please
instead continue with the removal process for your package.

Regards,
Andreas Henriksson

Bug#886044: syncmaildir: Depends on gconf

[Jeremy Bicha]

Source: syncmaildir
Version: 1.2.6.2-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends or build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#885974: lintian: warn about non-git Vcs fields

[Chris Lamb]

Hi Mattia,

> > it would be a bit wrong to have Vcs-Svn actually point to a git repo…
> 
> Yes please start warning (not pedantic) now about Vcses hosted at
> {anonscm,alioth,svn,bzr,hg,darcs,arch}.debian.org.

Non-sequitur? As I read it, Jeremy's comment was about mismatches.

However, could you provide an initial description for the case of 
{anonscm,alioth,svn,bzr,hg,darcs,arch}.debian.org?

> > What about QA packages? Maybe those at least should be using git
> > hosted with Debian.
> 
> In general, I'd just warn about
> orphaned-package-not-maintained-in-debian.org-infrastracture 

Fancy retitling this bug for the above and cloning another for this
one? :)


Best wishes,

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

Bug#886043: sugar-write-activity: Depends on gconf

[Jeremy Bicha]

Package: sugar-write-activity
Version: 98.2-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends on gconf, but gconf will be removed from Debian
soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886042: sugar-read-activity: Depends on gconf

[Jeremy Bicha]

Package: sugar-read-activity
Version: 119-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends on gconf, but gconf will be removed from Debian
soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886041: sugar-browse-activity: Depends on gconf

[Jeremy Bicha]

Package: sugar-browse-activity
Version: 201.3-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package depends on gconf, but gconf will be removed from Debian
soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#886040: sugar-session: Depends on gconf

[Jeremy Bicha]

Package: sugar-session
Version: 0.112-1
Severity: important
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

sugar-session depends and build-depends on gconf, but gconf will be
removed from Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html

On behalf of the Debian GNOME team,
Jeremy Bicha