Bug#1075793: plastimatch FTBFS with DCMTK 3.6.8

[Gregory Sharp]

 Thank you Adrian,

Yes this is the correct patch. I'm inclined to make a new upstream release 
instead of patching, but let me know.

Greg Sharp
gregsh...@geocities.com
  

Bug#1075793: plastimatch FTBFS with DCMTK 3.6.8

[Gregory Sharp]

 Hi Mathieu,

Thank you for the report. This was fixed long ago upstream, but I did not 
deploy a new version.  Sorry for the FTBFS, that is my bad.

Greg Sharp
gregsh...@geocities.com

Bug#1072557: /usr/bin/firefox: crashes when trying to view a PDF file

[Gregory Mounie]

Package: firefox
Followup-For: Bug #1072557

Dear Maintainer,

I confirm the bug with my [AMD/ATI] Kaveri [Radeon R7 Graphics], (AMD
A8-7600 Radeon R7), and that the workaround works for me too.

related glx/egl/vk small programs on X11 (lxqt):

mesa-utils:
glxgears, eglxgear_x11, egltri_x11 eglinfo work flawlessly

vulkan-tools:
vkcube select the llvmpipe

$ vkcube
Selected GPU 0: llvmpipe (LLVM 17.0.6, 256 bits), type: Cpu

May be some false hypothesis are done by firefox on the acceleration
imlementation.

Thanks for all your works !

-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox depends on:
ii  debianutils  5.19
ii  fontconfig   2.15.0-1.1
ii  libasound2t641.2.11-1+b1
ii  libatk1.0-0t64   2.52.0-1
ii  libc62.38-13
ii  libcairo-gobject21.18.0-3+b1
ii  libcairo21.18.0-3+b1
ii  libdbus-1-3  1.14.10-4+b1
ii  libevent-2.1-7t642.1.12-stable-10
ii  libffi8  3.4.6-1
ii  libfontconfig1   2.15.0-1.1
ii  libfreetype6 2.13.2+dfsg-1+b4
ii  libgcc-s114.1.0-1
ii  libgdk-pixbuf-2.0-0  2.42.12+dfsg-1
ii  libglib2.0-0t64  2.80.3-1
ii  libgtk-3-0t643.24.42-1
ii  libnspr4 2:4.35-1.1+b1
ii  libnss3  2:3.101-1
ii  libpango-1.0-0   1.54.0+ds-1
ii  libstdc++6   14.1.0-1
ii  libvpx9  1.14.1-1
ii  libx11-6 2:1.8.7-1+b1
ii  libx11-xcb1  2:1.8.7-1+b1
ii  libxcb-shm0  1.17.0-2
ii  libxcb1  1.17.0-2
ii  libxcomposite1   1:0.4.5-1+b1
ii  libxdamage1  1:1.1.6-1+b1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2+b1
ii  libxrandr2   2:1.5.4-1
ii  procps   2:4.0.4-4
ii  zlib1g   1:1.3.dfsg+really1.3.1-1

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec60  7:6.1.1-4+b3

Versions of packages firefox suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-5
ii  libcanberra0   0.30-17
ii  libgssapi-krb5-2   1.20.1-6+b1
pn  pulseaudio 

-- no debconf information

Bug#1073273: Exception: ../../src/ui.cc:1549: void auto_fix_broken(): Assertion failed.

[Gregory Mounie]

Package: aptitude
Followup-For: Bug #1073273

Dear Maintainer,

Some bugs evaporate when you look at them...

After my today's "apt full-upgrade", the errors vanished. May be a
transient error related to a failed or incomplete upgrade state ?

Anyway, I guess you may close this bug as, thus, it looks like very
difficult to investigate it more, at least for me.

Thanks for all your works !

-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.4
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.5.20240427
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffcd67cc000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f8e3360)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f8e33e78000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f8e339c8000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f8e33e68000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f8e338c)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f8e33488000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f8e33e48000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f8e3320)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f8e32e0)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8e33118000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f8e3389)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8e32c18000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8e3387)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f8e33858000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8e330e8000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8e3346)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8e32b5)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8e330a)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f8e32a68000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f8e3292)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f8e33088000)
/lib64/ld-linux-x86-64.so.2 (0x7f8e33f18000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f8e33078000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f8e3291)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f8e328e)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-6
ii  libapt-pkg6.0t64  2.9.5
ii  libboost-iostreams1.83.0  1.83.0-3
ii  libc6 2.38-13
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14.1.0-1
ii  libncursesw6  6.5-2
ii  libsigc++-2.0-0v5 2.12.1-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-1
ii  libtinfo6 6.5-2
ii  libxapian30   1.4.25-1

Versions of packages aptitude recommends:
ii  libdpkg-perl1.22.6
ii  sensible-utils  0.0.22

Versions of packages aptitude suggests:
ii  apt-xapian-index0.55
ii  aptitude-doc-fr [aptitude-doc]  0.8.13-6
pn  debtags 
ii  tasksel 3.75

-- no debconf information

Bug#1073273: Exception: ../../src/ui.cc:1549: void auto_fix_broken(): Assertion failed.

[Gregory Mounie]

Package: aptitude
Version: 0.8.13-6
Severity: important

Dear Maintainer,

For a few days now, I can not use aptitude to keep up-to-date my sid
on my old desktop computers. It works perfectly on my others sid computers
(laptop, VMs).

1)
Using the TUI, after the selection process, when trying to upgrade or install, 
I only got:

Exception : ../../src/ui.cc:1549: void auto_fix_broken(): Assertion 
"resman->resolver_exists()" failed.

2)
Using the CUI "LANG=C aptitude upgrade" I got the suspicious following ERROR:

'''
The following packages have unmet dependencies:
 libvtk9.3 : Breaks: libvtk9.1 (< 9.3.0+dfsg1-1) but it is not going to be 
installed
*** ERROR: search aborted by fatal exception.  You may continue
   searching, but some solutions will be unreachable.

I want to resolve dependencies, but no dependency resolver was created.The 
following NEW packages will be installed:
  libvtk9.3{ab} libvtk9.3-qt{a} qml6-module-qtquick-effects{a}

'''

 I flagged it "important", as on this computer, aptitude is useless,
but it looks like a rare occurence (race condition on slow computer ?
settings (I masked packagekitd) ?)

I am using "apt upgrade" or "apt full-upgrade" directly and it seems to
work perfectly.

"apt install --reinstall aptitude" change nothing.

I do "apt-get source aptitude" to try to get hints, but as I am just
an aptitude source newbie, I do not yet understand when the aptitude_resolver
should created, and why it is not.


-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude

aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
  apt version 6.0.0
  NCurses version 6.4
  libsigc++ version: 2.12.1
  Gtk+ support disabled.
  Qt support disabled.

Current library versions:
  NCurses version: ncurses 6.5.20240427
  cwidget version: 0.5.18
  Apt version: 6.0.0

aptitude linkage:
linux-vdso.so.1 (0x7ffc671ec000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0 
(0x7f65aea0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6 
(0x7f65aedc)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 
(0x7f65aed88000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0 
(0x7f65aed78000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4 
(0x7f65aec7)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 
(0x7f65ae888000)
libboost_iostreams.so.1.83.0 => 
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f65aec5)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30 
(0x7f65ae60)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 
(0x7f65ae20)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f65ae518000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f65ae858000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f65ae018000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f65ae4f8000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 
(0x7f65ae4e)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f65ae4b)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f65ae488000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f65adf5)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f65adf08000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f65ade2)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 
(0x7f65adcd8000)
libxxhash.so.0 => /lib/x86_64-linux-gnu/libxxhash.so.0 
(0x7f65ae47)
/lib64/ld-linux-x86-64.so.2 (0x7f65af2b)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f65adcc8000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x7f65adcb8000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 
(0x7f65adc88000)

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

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

Versions of packages aptitude depends on:
ii  aptitude-common   0.8.13-6
ii  libapt-pkg6.0t64  2.9.4
ii  libboost-iostreams1.83.0  1.83.0-3
ii  libc6 2.38-13
ii  libcwidget4   0.5.18-6+b1
ii  libgcc-s1 14.1.0-1
ii  libncursesw6  6.5-2
ii  libsigc++-2.0-0v5 2.12.1-2
ii  libsqlite3-0  3.46.0-1
ii  libstdc++614.1.0-1
ii  libtinfo6 6.5-2
ii  libxapian30   

Bug#1055893: libsvtav1enc1d1: Cannot overwrite libSvtAv1Enc.so.1, which is also in package libsvtav1enc1:amd64 2:1.5.0-dmo1

[Gregory Nannig]

Package: libsvtav1enc1d1
Version: 1.7.0+dfsg-2_amd64
Severity: normal
X-Debbugs-Cc: swoarr...@gmail.com

Dear Maintainer,

   * What led up to the situation?  Regular updating of software using aptitude 
or Discover.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?  Updated software
   * What was the outcome of this action?  Several packages held up.
   * What outcome did you expect instead?



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

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

Bug#1031170: QML6: SEGFAULT while starting. 2 missing deps, may be another one ?

[Gregory Mounie]

Package: jami
Version: 20230206.0~ds1-4.2
Severity: normal

Dear Maintainer,

Recent Jami upgrade in SID. I try it. Jami fails in the starting process.

Now, the starting peocess give the following trace, then jami is terminated.
```
Using Qt runtime version: 6.4.2
"notify server name: lxqt-notificationd, vendor: lxqt.org, version: 1.2.0, 
spec: 1.2"
qt.webenginecontext: 

GL Type: desktop
Surface Type: OpenGL
Surface Profile: CompatibilityProfile
Surface Version: 4.5
QSG RHI Backend: OpenGL
Using Supported QSG Backend: yes
Using Software Dynamic GL: no
Using Multithreaded OpenGL: yes

Init Parameters:
  *  application-name Jami 
  *  browser-subprocess-path /usr/lib/qt6/libexec/QtWebEngineProcess 
  *  create-default-gl-context  
  *  disable-features 
ConsolidatedMovementXY,InstalledApp,BackgroundFetch,WebOTP,WebPayments,WebUSB,PictureInPicture
 
  *  disable-setuid-sandbox  
  *  disable-speech-api  
  *  enable-features NetworkServiceInProcess,TracingServiceInProcess 
  *  enable-threaded-compositing  
  *  in-process-gpu  
  *  use-gl desktop 

"Using locale: fr_FR"
No migration required
Screen saver dbus interface:  "org.freedesktop.ScreenSaver"
qt.core.qobject.connect: QObject::connect(lrc::api::ContactModel, 
ContactAdapter): unique connections require a pointer to member function of a 
QObject subclass
zsh: terminated  jami
```

Starting with gdb, I got the SEGFAULT in:
Thread 9 "QQmlThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffc37fe6c0 (LWP 65940)]
0x7fffebb2aca8 in QMetaSequence::valueMetaType() const () from 
/lib/x86_64-linux-gnu/libQt6Core.so.6

The call stack is:
```
#0  0x7fffebb2aca8 in QMetaSequence::valueMetaType() const () at 
/lib/x86_64-linux-gnu/libQt6Core.so.6
#1  0x7fffed4b180e in 
QQmlMetaType::registerSequentialContainer(QQmlPrivate::RegisterSequentialContainer
 const&) ()
at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#2  0x7fffed44cb73 in 
QQmlPrivate::qmlregister(QQmlPrivate::RegistrationType, void*) ()
at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#3  0x7fffed44d959 in 
QQmlPrivate::qmlregister(QQmlPrivate::RegistrationType, void*) ()
at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#4  0x7fffc0be7dd4 in qml_register_types_QtQuick_Layouts() () at 
/lib/x86_64-linux-gnu/libQt6QuickLayouts.so.6
#5  0x7fffed4c19af in  () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#6  0x7fffed4b20d2 in QQmlMetaType::registerPluginTypes(QObject*, QString 
const&, QString const&, QString const&, QTypeRevision, QList*) () at 
/lib/x86_64-linux-gnu/libQt6Qml.so.6

#7  0x7fffed4dcc90 in  () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#8  0x7fffed49a660 in QQmlImports::importExtension(QString const&, 
QTypeRevision, QQmlImportDatabase*, QQmlTypeLoaderQmldirContent const*, 
QList*) () at /lib/x86_64-linux-gnu/libQt6Qml.so.6   
   
#9  0x7fffed49e429 in QQmlImports::addLibraryImport(QQmlImportDatabase*, 
QString const&, QString const&, QTypeRevision, QString const&, QString const&, 
QFlags, QList*) () at 
/lib/x86_64-linux-gnu/libQt6Qml.so.6
#10 0x7fffed532d36 in 
QQmlTypeLoader::Blob::addLibraryImport(std::shared_ptr,
 QList*) () at /lib/x86_64-linux-gnu/libQt6Qml.so.6  

#11 0x7fffed534317 in 
QQmlTypeLoader::Blob::addImport(std::shared_ptr,
 QList*)
() at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#12 0x7fffed534424 in 
QQmlTypeLoader::Blob::addImport(QV4::CompiledData::Import const*, 
QFlags, QList*) () at 
/lib/x86_64-linux-gnu/libQt6Qml.so.6

#13 0x7fffed51e700 in  () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#14 0x7fffed524dd0 in QQmlTypeLoader::setData(QQmlDataBlob*, 
QQmlDataBlob::SourceCodeData const&) ()
at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#15 0x7fffed525c7a in QQmlTypeLoader::setData(QQmlDataBlob*, QString 
const&) () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#16 0x7fffed5292e2 in QQmlTypeLoader::loadThread(QQmlDataBlob*) () at 
/lib/x86_64-linux-gnu/libQt6Qml.so.6
#17 0x7fffed53ae2d in  () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#18 0x7fffed448a6c in  () at /lib/x86_64-linux-gnu/libQt6Qml.so.6
#19 0x7fffec982a53 in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() at /lib/x86_64-linux-gnu/libQt6Widgets.so.6
#20 0x7fffebb238b8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() at /lib/x86_64-linux-gnu/libQt6Core.so.6
#21 0x7fffebb23a97 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) ()
--Type  for more, q to quit, c to continue without paging--
at /lib/x86_64-linux-gnu/libQt6Core.so.6
#22 0x7fffebd0a353 in  () at /lib/x86_64-linux-gnu/libQt6Core.so.6
#23 0x7799b7a9 in g_main_context_dispatch () at 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#24 

Bug#1028156: Bug in SVG output

[Gregory Heytings]

Package: mupdf
Version: 1.21.1+ds1-1

Recent versions of mupdf have a bug in the handling of '<' and '>' 
characters in SVG output.  For example, with the following file:


https://gnu.support/files/tmp/2023-01-05/FR%20205.pdf

mutool draw -o foo.svg  1

produces an invalid SVG file, with several occurrences of 'data-text="<" ... />'.


The function svg_dev_data_text should use the same logic as 
svg_dev_text_span for these characters.  Patch attached.
diff --git a/source/fitz/svg-device.c b/source/fitz/svg-device.c
index dff27789..db634076 100644
--- a/source/fitz/svg-device.c
+++ b/source/fitz/svg-device.c
@@ -568,7 +568,7 @@ svg_dev_data_text(fz_context *ctx, fz_buffer *out, int c)
 			fz_append_string(ctx, out, "");
 		else if (c == '"')
 			fz_append_string(ctx, out, "");
-		else if (c >= 32 && c < 127)
+		else if (c >= 32 && c < 127 && c != '<' && c != '>')
 			fz_append_byte(ctx, out, c);
 		else
 			fz_append_printf(ctx, out, 

Bug#1024687: libfm-qt11:amd64 1.1.0-3 -> 1.2.0-1 breaks some lxqt functionalities

[Gregory Mounie]

Package: libfm-qt11
Version: 1.2.0-1
Followup-For: Bug #1024687

Dear Maintainer,

 pcmanfm-qt is compiled to look for libfm-qt.so.11

 The package provides libfm-qt.so.12

 Workaround until recompilation of pcmanfm-qt:
 - Adding a symbolic link allows to run pcmanfm-qt.

 cd /usr/lib/x86_64-linux-gnu
 ln -s libfm-qt.so.12 libfm-qt.so.11

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

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

Versions of packages libfm-qt11 depends on:
ii  libc6 2.36-5
ii  libexif12 0.6.24-1+b1
ii  libglib2.0-0  2.74.1-2
ii  libglib2.0-bin2.74.1-2
ii  libmenu-cache31.1.0-1.1
ii  libqt5core5a [qtbase-abi-5-15-6]  5.15.6+dfsg-2+b1
ii  libqt5gui55.15.6+dfsg-2+b1
ii  libqt5widgets55.15.6+dfsg-2+b1
ii  libqt5x11extras5  5.15.6-2
ii  libstdc++612.2.0-9
ii  libxcb1   1.15-1
ii  shared-mime-info  2.2-1

Versions of packages libfm-qt11 recommends:
ii  libfm-qt-l10n  1.2.0-1

libfm-qt11 suggests no packages.

-- no debconf information

Bug#1020532: gimp: text element crashes gimp

[Gregory Grosse]

Package: gimp
Version: 2.10.32-1+b1
Followup-For: Bug #1020532
X-Debbugs-Cc: 23704241+gdgro...@users.noreply.github.com

Similarly, opening a PDF in gimp, which then rasterizes it, and clicking using
the text tool and typing 1 character results in:
fatal error: Segmentation fault.




```
GNU Image Manipulation Program version 2.10.32
git-describe: GIMP_2_10_32
Build: unknown rev 0 for linux
# C compiler #
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
12.1.0-8' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-
languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-
major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-
included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-
verify --enable-plugin --enable-default-pie --with-system-zlib --enable-
libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-
abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-
none=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-
amdhsa=/build/gcc-12-WXbu70/gcc-12-12.1.0/debian/tmp-gcn/usr --enable-offload-
defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-
gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Debian 12.1.0-8)

# Libraries #
using babl version 0.1.96 (compiled against version 0.1.92)
using GEGL version 0.4.38 (compiled against version 0.4.38)
using GLib version 2.73.3 (compiled against version 2.72.3)
using GdkPixbuf version 2.42.9 (compiled against version 2.42.9)
using GTK+ version 2.24.33 (compiled against version 2.24.33)
using Pango version 1.50.9 (compiled against version 1.50.9)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```
/lib/x86_64-linux-
gnu/libgimpbase-2.0.so.0(gimp_stack_trace_print+0x3e8)[0x7f73b9300638]
gimp-2.10(+0xdcd1f)[0x55d92d0bed1f]
gimp-2.10(+0xdd0f8)[0x55d92d0bf0f8]
gimp-2.10(+0xdd749)[0x55d92d0bf749]
/lib/x86_64-linux-gnu/libc.so.6(+0x3daf0)[0x7f73b843daf0]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x25103)[0x7f73b8995103]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1b6d8)[0x7f73b898b6d8]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x1bf5a)[0x7f73b898bf5a]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_object_new_with_properties+0x194)[0x7f73b898d3f4]
gimp-2.10(gimp_image_undo_push+0x1a7)[0x55d92d43c787]
gimp-2.10(gimp_image_undo_push_text_layer+0x104)[0x55d92d43f344]
gimp-2.10(gimp_text_tool_apply+0x103)[0x55d92d16ee93]
gimp-2.10(+0x18ea27)[0x55d92d170a27]
gimp-2.10(+0x18ec62)[0x55d92d170c62]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x160)[0x7f73b8986500]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x29b36)[0x7f73b8999b36]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xf35)[0x7f73b89a06b5]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f73b89a087f]
gimp-2.10(+0x1913e5)[0x55d92d1733e5]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x160)[0x7f73b8986500]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x29b36)[0x7f73b8999b36]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xf35)[0x7f73b89a06b5]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x1f8)[0x7f73b89a0a98]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x160)[0x7f73b8986500]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x29b36)[0x7f73b8999b36]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xf35)[0x7f73b89a06b5]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_by_name+0x1f8)[0x7f73b89a0a98]
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x11f030)[0x7f73b951f030]
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x11f613)[0x7f73b951f613]
gimp-2.10(gimp_text_tool_editor_key_press+0x98)[0x55d92d174a48]
gimp-2.10(+0x1e81cc)[0x55d92d1ca1cc]
gimp-2.10(gimp_display_shell_canvas_tool_events+0x79)[0x55d92d1cb139]
/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x1391ab)[0x7f73b95391ab]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_closure_invoke+0x160)[0x7f73b8986500]
/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x29b36)[0x7f73b8999b36]
/lib/x86_64-linux-
gnu/libgobject-2.0.so.0(g_signal_emit_valist+0x76d)[0x7f73b899feed]

Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil

[Gregory Mounie]

Package: elpa-evil
Version: 1.14.0-1
Severity: normal

Dear Maintainer,

Upgrading to emacs-gtk 28.1 fails with byte copiling elpa-evil*

... skipped a lot of successfull byte compiling lines
Install elpa-evil for emacs
install/evil-1.14.0: Handling install of emacsen flavor emacs
install/evil-1.14.0: byte-compiling for emacs
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-command-window.el:36:1: Error: Wrong number of arguments: (3 . 4), 2
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-commands.el:29:1: Error: Wrong number of arguments: (3 . 4), 2

In evil-add-to-alist:
evil-common.el:128:18: Warning: ‘evil-add-to-alist’ is an obsolete function
(as of 1.13.1); use ‘evil--add-to-alist’ instead. You may need to
recompile code with evil macros.

In evil-with-view-list:
evil-common.el:3922:11: Warning: docstring wider than 80 characters

In toplevel form:
evil-core.el:181:31: Warning: defcustom for ‘evil-mode’ fails to specify
containing group
evil-core.el:181:31: Warning: defcustom for ‘evil-mode’ fails to specify
containing group

In toplevel form:
evil-ex.el:596:1: Error: Wrong number of arguments: (3 . 4), 2
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-integration.el:35:1: Error: Wrong number of arguments: (3 . 4), 2

In toplevel form:
evil-jumps.el:38:1: Warning: custom-declare-variable
`evil-jumps-cross-buffers' docstring wider than 80 characters
evil-jumps.el:58:1: Warning: custom-declare-variable
`evil-jumps-ignored-file-patterns' docstring wider than 80 characters
evil-jumps.el:71:1: Warning: defvar `evil--jumps-buffer-targets' docstring
wider than 80 characters
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-keybindings.el:35:1: Error: Wrong number of arguments: (3 . 4), 2
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-maps.el:29:1: Error: Wrong number of arguments: (3 . 4), 2

In evil-repeat-force-abort-p:
evil-repeat.el:242:8: Warning: docstring wider than 80 characters

In evil-repeat-motion:
evil-repeat.el:349:8: Warning: docstring wider than 80 characters
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil-search.el:30:1: Error: Wrong number of arguments: (3 . 4), 2
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
evil.el:133:1: Error: Wrong number of arguments: (3 . 4), 2
ERROR: install script from elpa-evil package failed
dpkg: erreur de traitement du paquet emacs-gtk (--configure) :
 installed emacs-gtk package post-installation script subprocess returned error 
exit status 1

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

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

Versions of packages elpa-evil depends on:
ii  dh-elpa-helper 2.0.10
ii  elpa-goto-chg  1.7.3-1
ii  elpa-undo-tree 0.8.1-1
iu  emacs  1:28.1+1-2
ih  emacs-gtk [emacs]  1:28.1+1-2
ii  emacsen-common 3.0.4

Versions of packages elpa-evil recommends:
iu  emacs  1:28.1+1-2
ih  emacs-gtk [emacs]  1:28.1+1-2

elpa-evil suggests no packages.

-- no debconf information

Bug#1017834: elpa-cider: emacs 28.1 upgrade fails with byte compiling elpa-cider

[Gregory Mounie]

Package: elpa-cider
Version: 0.19.0+dfsg-3
Severity: normal

Dear Maintainer,

While upgrading to emacs-gtk 28.1, the process fails with byte
compiling elpa-cider

... skipped successful byte compiling lines
Install elpa-cider for emacs
install/cider-0.19.0: Handling install of emacsen flavor emacs
install/cider-0.19.0: byte-compiling for emacs
../../elpa-src/clojure-mode-5.10.0/clojure-mode.el: Warning: ‘project-roots’ is 
an obsolete generic function (as of 0.3.0); use ‘project-root’ instead.
../../elpa-src/cider-0.19.0/cider-popup.el: Warning: Use keywords rather than 
deprecated positional arguments to `define-minor-mode'

In toplevel form:
cider-apropos.el:28:1: Warning: Package cl is deprecated
../../elpa-src/cider-0.19.0/nrepl-client.el: Warning: Use keywords rather than 
deprecated positional arguments to `define-minor-mode'
Interactive forms unsupported in generic functions: (interactive "P")

In cider--nrepl-pprint-request-plist:
cider-client.el:238:29: Warning: reference to free variable
‘cider-pprint-options’

In end of data:
cider-client.el:240:58: Warning: the function ‘cider--pprint-option’ is not
known to be defined.

In cider-prompt-for-symbol-function:
cider-common.el:59:8: Warning: docstring wider than 80 characters
Interactive forms unsupported in generic functions: (interactive "P")
../../elpa-src/cider-0.19.0/cider-test.el: Warning: Use keywords rather than 
deprecated positional arguments to `define-minor-mode'

In toplevel form:
cider-debug.el:307:7: Warning: Use keywords rather than deprecated positional
arguments to `define-minor-mode'

In toplevel form:
cider-eldoc.el:48:1: Warning: custom-declare-variable
`cider-eldoc-max-num-sexps-to-skip' docstring wider than 80 characters

In cider-default-err-op-handler:
cider-eval.el:282:19: Warning: reference to free variable
‘cider-stacktrace-print-options’

In cider-popup-eval-out-handler:
cider-eval.el:561:8: Warning: docstring wider than 80 characters
../../elpa-src/cider-0.19.0/cider-mode.el: Warning: Use keywords rather than 
deprecated positional arguments to `define-minor-mode'

In toplevel form:
cider-macroexpansion.el:196:20: Warning: Use keywords rather than deprecated
positional arguments to `define-minor-mode'

In toplevel form:
cider-mode.el:594:1: Warning: custom-declare-variable
`cider-font-lock-reader-conditionals' docstring wider than 80 characters

In cider--compile-font-lock-keywords:
cider-mode.el:725:8: Warning: docstring wider than 80 characters
cider-mode.el:1007:7: Warning: Use keywords rather than deprecated positional
arguments to `define-minor-mode'

In cider-ns-refresh:
cider-ns.el:253:25: Warning: reference to free variable
‘cider-stacktrace-print-options’

In toplevel form:
cider-popup.el:29:20: Warning: Use keywords rather than deprecated positional
arguments to `define-minor-mode'

In toplevel form:
cider-repl-history.el:194:1: Warning: custom-declare-variable
`cider-repl-history-display-duplicate-highest' docstring wider than 80
characters
cider-repl-history.el:232:1: Warning: defvar
`cider-repl-history-preview-overlay' docstring wider than 80 characters

In cider-repl-history-resize-window:
cider-repl-history.el:247:8: Warning: docstring wider than 80 characters

In cider-repl-history-read-regexp:
cider-repl-history.el:257:8: Warning: docstring wider than 80 characters

In cider-repl-history-current-string:
cider-repl-history.el:359:8: Warning: docstring wider than 80 characters

In cider-repl-history-do-insert:
cider-repl-history.el:367:8: Warning: docstring wider than 80 characters

In cider-repl-history-elide:
cider-repl-history.el:498:8: Warning: docstring wider than 80 characters

In cider-repl-history-setup:
cider-repl-history.el:588:8: Warning: docstring wider than 80 characters

In cider-repl-closing-return:
cider-repl.el:1003:8: Warning: docstring wider than 80 characters

In cider-stacktrace-suppress-error:
cider-stacktrace.el:407:8: Warning: docstring wider than 80 characters

In cider-stacktrace-promote-error:
cider-stacktrace.el:412:8: Warning: docstring wider than 80 characters

In cider-stacktrace-suppressed-error-p:
cider-stacktrace.el:417:8: Warning: docstring wider than 80 characters

In cider-stacktrace-toggle-suppression:
cider-stacktrace.el:550:8: Warning: docstring wider than 80 characters

In cider-stacktrace-render-suppression-toggle:
cider-stacktrace.el:665:8: Warning: docstring wider than 80 characters

In cider-test-stacktrace-for:
cider-test.el:287:19: Warning: reference to free variable
‘cider-stacktrace-print-options’

In cider-test-run-loaded-tests:
cider-test.el:713:8: Warning: docstring wider than 80 characters

In cider-test-run-project-tests:
cider-test.el:720:8: Warning: docstring wider than 80 characters
cider-test.el:815:28: Warning: Use keywords rather than deprecated positional
arguments to `define-minor-mode'
../../elpa-src/cider-0.19.0/cider-debug.el: Warning: Use keywords rather than 
deprecated 

Bug#1017833: elpa-elscreen: emacs 28.1 upgrade failure with byte compiling of elpa-elscreen

[Gregory Mounie]

Package: elpa-elscreen
Version: 1.4.6-8
Severity: normal

Dear Maintainer,

Upgrading to emacs-gtk 28.1 fail with byte compiling elpa-elscreen

Paramétrage de emacs-gtk (1:28.1+1-2) ...
Deep recursion on subroutine 
"main::generate_relevant_tsort_dependencies_internals" at 
/usr/lib/emacsen-common/lib.pl line 127.
Install emacs-calfw for emacs
Install emacs-window-layout for emacs
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install emacspeak for emacs
/usr/lib/emacsen-common/packages/install/emacspeak running in /
Latest installed version: 53.0+dfsg-1
Latest compiled version:  53.0+dfsg-1
Install pylint for emacs
... a lot of successful byte compiling lines skipped
Install elpa-elscreen for emacs
install/elscreen-1.4.6: Handling install of emacsen flavor emacs
install/elscreen-1.4.6: byte-compiling for emacs

In toplevel form:
elscreen-color-theme.el:25:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-dired.el:26:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-dnd.el:26:1: Error: Wrong number of arguments: make-obsolete-variable, 
2

In toplevel form:
elscreen-gf.el:28:1: Error: Wrong number of arguments: make-obsolete-variable, 2

In toplevel form:
elscreen-goby.el:26:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-howm.el:26:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-server.el:27:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-speedbar.el:25:1: Error: Wrong number of arguments: 
make-obsolete-variable, 2

In toplevel form:
elscreen-w3m.el:26:1: Error: Wrong number of arguments: make-obsolete-variable, 
2

In toplevel form:
elscreen.el:155:4: Warning: make-obsolete-variable called with 2 arguments,
but requires 3-4
elscreen.el:201:13: Warning: custom-declare-variable
`elscreen-tab-display-kill-screen' docstring wider than 80 characters

In elscreen-get-alist-to-nickname:
elscreen.el:630:8: Warning: ‘mapcar’ called for effect; use ‘mapc’ or ‘dolist’
instead

In elscreen-get-screen-to-name-alist:
elscreen.el:666:21: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead
elscreen.el:666:21: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead

In elscreen-find-screens:
elscreen.el:769:11: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead

In elscreen-find-screen-by-major-mode:
elscreen.el:818:15: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead

In elscreen-kill-others:
elscreen.el:927:14: Warning: ‘interactive-p’ is an obsolete function (as of
23.2); use ‘called-interactively-p’ instead.
elscreen.el:929:5: Warning: ‘interactive-p’ is an obsolete function (as of
23.2); use ‘called-interactively-p’ instead.
elscreen.el:929:5: Warning: ‘interactive-p’ is an obsolete function (as of
23.2); use ‘called-interactively-p’ instead.
elscreen.el:926:45: Warning: ‘interactive-p’ is an obsolete function (as of
23.2); use ‘called-interactively-p’ instead.

In elscreen-select-and-goto:
elscreen.el:1170:8: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead
elscreen.el:1183:43: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead

In elscreen-find-and-goto-by-buffer:
elscreen.el:1193:30: Warning: ‘interactive-p’ is an obsolete function (as of
23.2); use ‘called-interactively-p’ instead.

In elscreen-find-file-read-only:
elscreen.el:1220:4: Warning: ‘toggle-read-only’ is an obsolete function (as of
24.3); use ‘read-only-mode’ instead.

In elscreen-e21-tab-update:
elscreen.el:1533:38: Warning: ‘mapcar’ called for effect; use ‘mapc’ or
‘dolist’ instead

In elscreen-command-line-funcall:
elscreen.el:1676:10: Warning: reference to free variable ‘file-count’
elscreen.el:1676:10: Warning: assignment to free variable ‘file-count’

In elscreen-command-line-find-file:
elscreen.el:1693:20: Warning: ‘goto-line’ is for interactive use only; use
‘forward-line’ instead.
elscreen.el:1728:13: Warning: reference to free variable ‘file-count’
elscreen.el:1728:28: Warning: assignment to free variable ‘file-count’
elscreen.el:1732:50: Warning: reference to free variable ‘orig-argi’
elscreen.el:1751:16: Warning: reference to free variable ‘dir’
elscreen.el:1777:54: Warning: reference to free variable ‘line’
elscreen.el:1717:13: Warning: reference to free variable ‘column’
elscreen.el:1778:21: Warning: assignment to free variable ‘line’
elscreen.el:1778:21: Warning: assignment to free variable ‘column’
elscreen.el:1733:16: Warning: reference to free variable ‘cl1-dir’
elscreen.el:1734:58: Warning: reference to free variable ‘cl1-line’
elscreen.el:1734:67: Warning: reference to free variable ‘cl1-column’
elscreen.el:1735:13: Warning: assignment to free variable ‘cl1-line’
elscreen.el:1736:13: Warning: assignment to free 

Bug#1017831: elpa-rtags: emacs-gtk 28.1-2 upgrade fails with byte-compiling elpa-rtags

[Gregory Mounie]

Package: elpa-rtags
Version: 2.38-5
Severity: normal

Dear Maintainer,

Upgrade to emacs-gtk 28.1 fails with byte compiling elpa-rtags

Paramétrage de emacs-gtk (1:28.1+1-2) ...
Deep recursion on subroutine 
"main::generate_relevant_tsort_dependencies_internals" at 
/usr/lib/emacsen-common/lib.pl line 127.
tsort: - : l'entrée contient une boucle :
tsort: elpa-seq
tsort: emacsen-common
Install emacs-calfw for emacs
Install emacs-window-layout for emacs
Install emacspeak for emacs
/usr/lib/emacsen-common/packages/install/emacspeak running in /
Latest installed version: 53.0+dfsg-1
Latest compiled version:  53.0+dfsg-1
Install pylint for emacs
... skipped successfull byte compiling lines ...
Install elpa-rtags for emacs
install/rtags-2.38.130: Handling install of emacsen flavor emacs
install/rtags-2.38.130: byte-compiling for emacs

In toplevel form:
rtags.el:169:1: Warning: custom-declare-variable
`rtags-references-tree-truncate' docstring wider than 80 characters
rtags.el:226:1: Warning: custom-declare-variable `rtags-spellcheck-enabled'
docstring wider than 80 characters
rtags.el:231:1: Warning: custom-declare-variable `rtags-multiple-targets'
docstring wider than 80 characters
rtags.el:241:1: Warning: custom-declare-variable
`rtags-sort-references-by-input' docstring wider than 80 characters
rtags.el:298:1: Warning: custom-declare-variable
`rtags-imenu-syntax-highlighting' docstring wider than 80 characters
rtags.el:404:1: Warning: custom-declare-variable `rtags-track-container'
docstring wider than 80 characters
rtags.el:596:1: Warning: custom-declare-variable
`rtags-buffer-follows-sandbox-id-match' docstring wider than 80 characters

In rtags-get-sandbox-id:
rtags.el:1127:8: Warning: docstring wider than 80 characters

In rtags-sandbox-id-matches:
rtags.el:1135:8: Warning: docstring wider than 80 characters

In rtags-goto-location:
rtags.el:2397:8: Warning: docstring wider than 80 characters

In rtags-target-declaration-first:
rtags.el:2703:8: Warning: docstring wider than 80 characters

In rtags-find-symbol-at-point:
rtags.el:2714:8: Warning: docstring wider than 80 characters

In rtags--should-rename-with-mc:
rtags.el:2905:8: Warning: docstring wider than 80 characters

In rtags-show-target-in-other-window:
rtags.el:4403:8: Warning: docstring wider than 80 characters
rtags.el:4673:1: Error: Wrong number of arguments: (3 . 4), 2
ERROR: install script from elpa-rtags package failed
dpkg: erreur de traitement du paquet emacs-gtk (--configure) :
 installed emacs-gtk package post-installation script subprocess returned error 
exit status 1

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

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

Versions of packages elpa-rtags depends on:
ii  dh-elpa-helper  2.0.10
ii  emacsen-common  3.0.4
ii  rtags   2.38-5+b1

Versions of packages elpa-rtags recommends:
iu  emacs  1:28.1+1-2
ih  emacs-gtk [emacs]  1:28.1+1-2

Versions of packages elpa-rtags suggests:
ii  elpa-ac-rtags2.38-5
ii  elpa-company-rtags   2.38-5
ii  elpa-flycheck-rtags  2.38-5
ii  elpa-helm-rtags  2.38-5
ii  elpa-ivy-rtags   2.38-5

-- no debconf information

Bug#1017829: elpa-ess: emacs-gtk 28.1 install fails with installed elpa-ess

[Gregory Mounie]

Package: elpa-ess
Version: 18.10.2
Severity: normal

Dear Maintainer,

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

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

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

Upgrading to emacs 28.1-2 leads emacs-gtk to a failure at emacs-ess
byte-compiling.

Paramétrage de emacs-gtk (1:28.1+1-2) ...
Deep recursion on subroutine 
"main::generate_relevant_tsort_dependencies_internals" at 
/usr/lib/emacsen-common/lib.pl line 127.
Install emacs-calfw for emacs
Install emacs-window-layout for emacs
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
Install emacspeak for emacs
/usr/lib/emacsen-common/packages/install/emacspeak running in /
Latest installed version: 53.0+dfsg-1
Latest compiled version:  53.0+dfsg-1

... I skip a lot of successful
Install   
... until ess failure lines

Install elpa-ess for emacs
install/ess-18.10.2: Handling install of emacsen flavor emacs
install/ess-18.10.2: byte-compiling for emacs
Package cl is deprecated
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Error loading autoloads: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
debian-autoloads.el:9:1: Error: Wrong number of arguments: (3 . 4), 2

In toplevel form:
ess-custom.el:363:1: Warning: custom-declare-variable
`ess-tab-complete-in-script' docstring wider than 80 characters
ess-custom.el:409:1: Warning: custom-declare-variable
`ess-eldoc-abbreviation-style' docstring wider than 80 characters
ess-custom.el:1484:1: Warning: custom-declare-variable `ess-roxy-fill-param-p'
docstring wider than 80 characters
ess-custom.el:1547:1: Warning: custom-declare-variable
`ess-gen-proc-buffer-name-function' docstring wider than 80 characters
ess-custom.el:1657:1: Warning: custom-declare-variable `ess-R-readline'
docstring wider than 80 characters
ess-custom.el:1694:1: Warning: custom-declare-variable `ess-program-files'
docstring wider than 80 characters
ess-custom.el:1704:1: Warning: custom-declare-variable `ess-program-files-64'
docstring wider than 80 characters
ess-custom.el:1926:1: Warning: custom-declare-variable
`inferior-Sqpe+-start-args' docstring wider than 80 characters
ess-custom.el:2329:1: Warning: custom-declare-variable
`inferior-ess-safe-names-command' docstring wider than 80 characters

In ess-font-lock-db:
ess-font-lock.el:136:8: Warning: docstring wider than 80 characters
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
ess-gretl.el:40:1: Error: Wrong number of arguments: (3 . 4), 2

In inferior-ess:
ess-inf.el:284:20: Warning: ‘syntax-begin-function’ is an obsolete variable
(as of 25.1).

In ess-gen-proc-buffer-name:abbr-long-directory:
ess-inf.el:373:8: Warning: docstring wider than 80 characters

In ess-process-put:
ess-inf.el:723:8: Warning: docstring wider than 80 characters

In ess-switch-to-inferior-or-script-buffer:
ess-inf.el:924:8: Warning: docstring wider than 80 characters

In ess-execute-search:
ess-inf.el:2301:8: Warning: docstring wider than 80 characters

In ess-resynch:
ess-inf.el:2757:8: Warning: docstring wider than 80 characters
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
ess-julia.el:46:1: Error: Wrong number of arguments: (3 . 4), 2

In ess-noweb-font-lock-mode:
ess-noweb-font-lock-mode.el:163:8: Warning: docstring wider than 80 characters

In ess-noweb-font-lock-fontify-chunk-by-number:
ess-noweb-font-lock-mode.el:244:11: Warning: ‘syntax-begin-function’ is an
obsolete variable (as of 25.1).

In toplevel form:
ess-noweb-mode.el:1559:1: Warning: defvar `ess-noweb-default-tab-width'
docstring wider than 80 characters
ess-noweb-mode.el:1571:1: Warning: defvar `ess-noweb-tab-width' docstring
wider than 80 characters

In ess-noweb-tangle-chunk:
ess-noweb-mode.el:1637:4: Warning: value returned from (1-
ess-noweb-line-number-skip-lines) is unused
ess-noweb-mode.el:1637:4: Warning: value returned from (1-
ess-noweb-line-number-skip-lines) is unused

In end of data:
ess-omg-l.el:44:21: Warning: the function ‘ess-calculate-indent’ is not known
to be defined.
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)
Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2)

In toplevel form:
ess-r-a.el:36:1: Error: Wrong number of arguments: (3 . 4), 2

In ess-r-object-completion:

Bug#1010418: terminus: Do not set $TERM: may provide qterminal (unuseable with aptitude, ...)

[Gregory Mounie]

Package: terminus
Version: 1.15.1-2
Severity: normal
Tags: upstream

Dear Maintainer,

I am using LXQT with qterminal as default terminal.

Note that qterminal has an option to set the TERM variable (by default 
xterm-256color)

When starting from a LXQT launcher (icon, Alt-F2, launcher in panel),
terminus keeps TERM sets to "qterminal". It is quite annoying (no backspace
in zsh and bash, aptitude do not start, ...).

terminus should set the TERM variable to an appropriate
value. Probably to xterm-256color ?

To reproduce from other terminal, or environment:

TERM=qterminal terminus

The same test with other terminals: they set the TERM variable as
expected (tested: qterminal, terminator, gnome-terminal, konsole,
kitty, sakura, urxvt, uxterm, xterm).

Thanks
Grégory

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

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

Versions of packages terminus depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libgee-0.8-2 0.20.5-2
ii  libglib2.0-0 2.72.1-1
ii  libglib2.0-bin   2.72.1-1
ii  libgtk-3-0   3.24.33-1
ii  libkeybinder-3.0-0   0.3.2-1.1
ii  libpango-1.0-0   1.50.6+ds-2
ii  libvte-2.91-00.68.0-1+b1

terminus recommends no packages.

terminus suggests no packages.

-- no debconf information

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Gregory Mounie]

Package: elpa-org
Version: 9.5.2+dfsh-3
Followup-For: Bug #1002982

Dear Maintainer,

Thanks for fast modifications. I still have a problem.

The org-version string in org-version.el is not compatible with
version-to-list standard function (emacs source, lisp/subr.el line 6137 in
current master).

The syntax seems limited to the extension listed in
version-regexp-alist variable a single letter or
(alpha,beta,pre,rc,unknown,git,svn,hg,bzr,darcs). Each of these
extensions has fixed translation to a number (-1 to -4)

I would say that the goal is to be able to sort the version (-4 is
bottom, alpha is -3, beta -2, rc is -1)

Thus it would be possible to put '9.5.2' or '9.5.2+unknown' or '9.5.2+d' but not
'9.5.2+dfsh'.

(I would select '9.5.2+d' translated in (9 5 2 4) as I guess that
+dfsh is patching on top of the standard release)

With current '9.5.2+dfsh', at the install elpa-org, I got 30 times:

In toplevel form:
org-agenda.el:50:1:Error: Invalid version syntax: ‘9.5.2+dfsh’

In toplevel form:
org-archive.el:31:1:Error: Invalid version syntax: ‘9.5.2+dfsh’

In toplevel form:
org-attach-git.el:32:1:Error: Invalid version syntax: ‘9.5.2+dfsh’

In toplevel form:
org-attach.el:38:1:Error: Invalid version syntax: ‘9.5.2+dfsh’
...

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org depends on:
ii  dh-elpa-helper  2.0.10
ii  elpa-htmlize1.56-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1

Versions of packages elpa-org suggests:
ii  ditaa  0.10+ds1-1.2
ii  org-mode-doc   9.4.0-2
ii  texinfo6.8-3
ii  texlive-fonts-recommended  2021.20211217-1
ii  texlive-latex-extra2021.20211217-1

-- no debconf information

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Gregory Mounie]

Package: elpa-org
Version: 9.5.2+dfsh-2
Followup-For: Bug #1002982

Dear Maintainer,

Thanks for the addition of org-version.el but I suspect another bug
still exist in the auto-generation of the file:

The org-version and org-git-version strings in
/usr/share/emacs/site-lisp/elpa-src/org-9.5.2/org-version.el are both
"N/A".

It should probably be respectively something like "9.5.2" and
"9.5.2-gfbff08" (values taken from a local user install of the package
from elpa)

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org depends on:
ii  dh-elpa-helper  2.0.10
ii  elpa-htmlize1.56-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1

Versions of packages elpa-org suggests:
ii  ditaa  0.10+ds1-1.2
ii  org-mode-doc   9.4.0-2
ii  texinfo6.8-3
ii  texlive-fonts-recommended  2021.20211217-1
ii  texlive-latex-extra2021.20211217-1

-- debconf-show failed

Bug#1002982: elpa-org: post-installation script subprocess returned error exit status 1

[Gregory Mounie]

Package: elpa-org
Version: 9.5.2+dfsh-1
Followup-For: Bug #1002982

Dear Maintainer,

After installation, org-version.el is missing (not auto-generated ?) in 
/usr/share/emacs/site-lisp/elpa-src/org-9.5.2/ and soft-linked in 
/usr/share/emacs/site-lisp/elpa/org-9.5.2/

Then the elpa-org 9.5.2 loads the org-version.el from default org 9.3 from 
emacs 27.1 ( /usr/share/emacs/27.1/lisp/org/org-version.el )
 
To reproduce the loading of the wrong file:
emacs -q

then in emacs

M-x org-reload

give the following message:
Successfully reloaded Org
Org mode version N/A (N/A !!check installation!! @ 
/usr/share/emacs/site-lisp/elpa/org-9.5.2/)


The full text of the *Messages* buffer at the org-reload execution. Note the 
directory of the loading of org-version (last previous last loading)

Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-comint...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-core...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-emacs-lisp...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-eval...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-exp...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-lob...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-ref...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-table...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/ob-tangle...done
Loading /usr/share/emacs/27.1/lisp/obarray...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-compat...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-entities...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-faces...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-footnote...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-keys...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-list...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macro...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-macs...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-pcomplete...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-src...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org-table...done
Loading /usr/share/emacs/27.1/lisp/org/org-version.el (source)...done
Loading /usr/share/emacs/site-lisp/elpa/org-9.5.2/org...done
The following features were found in load-path, please check if that’s correct:
(obarray org-version)
Successfully reloaded Org
Org mode version N/A (N/A !!check installation!! @ 
/usr/share/emacs/site-lisp/elpa/org-9.5.2/)


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

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

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


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages elpa-org depends on:
ii  dh-elpa-helper  2.0.10
ii  elpa-htmlize1.56-1
ii  emacsen-common  3.0.4

Versions of packages elpa-org recommends:
ii  emacs  1:27.1+1-3.1
ii  emacs-gtk [emacs]  1:27.1+1-3.1+b1

Versions of packages elpa-org suggests:
ii  ditaa  0.10+ds1-1.2
ii  org-mode-doc   9.4.0-2
ii  texinfo6.8-3
ii  texlive-fonts-recommended  2021.20211217-1
ii  texlive-latex-extra2021.20211217-1

-- debconf-show failed

Bug#1002531: cppcheck: Debian created manpage indicates C++-11 as default instead of C++-20

[Gregory Mounie]

Package: cppcheck
Version: 2.6-2
Severity: minor

Dear Maintainer,

Thanks to Reijo Tomperi cppcheck has a pretty manpage, but it seems out
of sync on the --std option default.

The debian created manpage of cppcheck, copyright from 2016,
indicates C++-11 as default standard (--std= option)

"cppcheck --help" indicates C++-20

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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cppcheck depends on:
ii  libc6 2.33-1
ii  libgcc-s1 11.2.0-13
ii  libpcre3  2:8.39-13
ii  libstdc++611.2.0-13
ii  libtinyxml2-9 9.0.0+dfsg-3
ii  libz3-4   4.8.12-1+b1
ii  python3   3.9.8-1
ii  python3-pygments  2.10.0+dfsg-1

cppcheck recommends no packages.

Versions of packages cppcheck suggests:
ii  clang 1:13.0-53
ii  clang-tidy1:13.0-53
ii  cppcheck-gui  2.6-2

-- no debconf information

Bug#734755: libpostgresql-ocaml-dev bug packaging for prepared statements

[Gregory Bellier]

Probably not.

You may consider closing this ticket.

Best

Le mer. 15 déc. 2021 à 17:36, Stéphane Glondu  a écrit :

> On Thu, 9 Jan 2014 17:12:01 +0100 Gregory Bellier
>  wrote:
> > I believe there is a bug in the packaging of this library. When I build
> my
> > project against the packaged library 1.18.0-1 in wheezy, I hit the error
> > "Postgresql.prepare: not supported"
>
> Is this still on topic?
>
> It is possible that, at the time of building of libpostgresql-ocaml-dev,
> libpostgresql was < 8.2 (in unstable).
>
>
> Cheers,
>
> --
> Stéphane
>

Bug#1001604: Julia segmentation fault on Sid

[Gregory Mounie]

Package: julia
Version: 1.5.3+dfsg-3
Followup-For: Bug #1001604

Dear Maintainer,

The segfault occurs in libllvm9.

I add the last system action according to strace.

** GDB trace of "gdb julia"
Reading symbols from julia...
(No debugging symbols found in julia)
(gdb) run
Starting program: /usr/bin/julia 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x716b8640 (LWP 10032)]

Thread 1 "julia" received signal SIGSEGV, Segmentation fault.
0x74ea29b1 in ?? () from /usr/bin/../lib/x86_64-linux-gnu/libLLVM-9.so.1
(gdb) quit
A debugging session is active.

Inferior 1 [process 10019] will be killed.

** end of "strace julia"
futex(0x7f72a55866a8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
... (many futex_wake_private calls)
lseek(2, 0, SEEK_CUR)   = -1 ESPIPE (Repérage non permis)
brk(0x5598351f7000) = 0x5598351f7000
uname({sysname="Linux", nodename="kiowa", ...}) = 0
openat(AT_FDCWD, "/proc/self/mem", O_RDWR|O_SYNC|O_CLOEXEC) = 16
mmap(NULL, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f72a0e5e000
pwrite64(16, "xV4\22\0\0\377\377", 8, 140130302418944) = 8
munmap(0x7f72a0e5e000, 4096)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x1} ---
+++ killed by SIGSEGV +++
Erreur de segmentation


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

Kernel: Linux 5.15.0-2-amd64 (SMP w/16 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages julia depends on:
ii  julia-common  1.5.3+dfsg-3
ii  libc6 2.33-1
ii  libcurl3-gnutls   7.79.1-2
ii  libdsfmt-19937-1  2.2.3+dfsg-5
ii  libgcc-s1 11.2.0-12
ii  libgfortran5  11.2.0-12
ii  libgit2-1.1   1.1.0+dfsg.1-4.1
ii  libgmp10  2:6.2.1+dfsg-3
ii  libjulia1 1.5.3+dfsg-3
ii  libllvm9  1:9.0.1-20+b1
ii  libmbedcrypto32.16.11-0.3
ii  libmbedtls12  2.16.11-0.3
ii  libmbedx509-0 2.16.11-0.3
ii  libmpfr6  4.1.0-3
ii  libopenlibm3  0.7.0+dfsg-2
ii  libpcre2-8-0  10.39-3
ii  libquadmath0  11.2.0-12
ii  libssh2-1 1.10.0-2
ii  libunwind81.3.2-2
ii  libutf8proc2  2.5.0-1

Versions of packages julia recommends:
ii  git  1:2.34.1-1
ii  openssl  1.1.1l-1

Versions of packages julia suggests:
pn  ess
ii  julia-doc  1.5.3+dfsg-3
ii  vim-julia  0.0~git20201014.a4bc8a2-1

-- no debconf information

Bug#1001525: ICC support should not be disabled in mupdf

[Gregory Heytings]

Debian has disabled ICC support in mupdf.  Because of this colors are 
not always rendered correctly.  In bug#952724 the "ICC support is not 
available" has been (almost) disabled.  Adding ICC support is easy:


git submodule add git://git.ghostscript.com/thirdparty-lcms2.git 
thirdparty/lcms2


and comment the FZ_ENABLE_ICC=0 and USE_SYSTEM_LCMS2=yes lines in 
debian/rules.


I will only enable this if Debian's lcms2 version works. I am happy to 
take patches.




That's not possible, at least not currently, see 
https://raw.githubusercontent.com/plangrid/ghostpdl/master/lcms2mt/doc/WhyThisFork.txt
 .

What is the problem with the above?  The lcms2mt library is built into the 
four mupdf binaries, and each one is about 1.5% larger.

Bug#1001525: ICC support should not be disabled in mupdf

[Gregory Heytings]

Package: mupdf
Version: 1.19.0+ds1-1

Debian has disabled ICC support in mupdf.  Because of this colors are not 
always rendered correctly.  In bug#952724 the "ICC support is not 
available" has been (almost) disabled.  Adding ICC support is easy:


git submodule add git://git.ghostscript.com/thirdparty-lcms2.git 
thirdparty/lcms2


and comment the FZ_ENABLE_ICC=0 and USE_SYSTEM_LCMS2=yes lines in 
debian/rules.

Bug#1001042: rxvt-unicode should depend on libxmu

[Gregory Heytings]

Package: rxvt-unicode
Version: 9.26-2

For some reason the package is built without libxmu.  Because of this the 
pointerShape resource has no effect.  Apparently this is not a conscious 
choice, there is no mention about libxmu in the changelog.

Bug#994729: brltty doesn't start on GUI login screen if sysvinit-core is used

[Gregory Nowak]

Hello Samuel.

It seems that the updated brltty package hasn't yet made it into
bullseye-proposed-updates. Is there any news on when that would
happen? Thanks.

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org

Bug#994729: brltty doesn't start on GUI login screen if sysvinit-core is used

[Gregory Nowak]

On Mon, Sep 20, 2021 at 11:47:56PM +0200, Samuel Thibault wrote:
> Could you test it before I request a stable-proposed-update?

I just have, and it works as expected here, thanks. Any idea how long
it will take to move from stable-proposed-update to stable?

Greg


-- 
web site: http://www.gregn.net
gpg public key: http://www.gregn.net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)
If we haven't been in touch before, e-mail me before adding me to your contacts.

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org

Bug#994729: brltty doesn't start on GUI login screen if sysvinit-core is used

[Gregory Nowak]

Package: brltty
Version: 6.3+dfsg-1
Severity: normal
Tags: a11y

Dear Maintainer,

When using sysvinit as the init system, brltty
shows "screen not in text mode" at the lightdm and gdm3 login screen.
This is because the /var/lib/BrlAPI/0 socket is missing at boot.

The fix is to add "$local_fs" to the "Required-Start" line of 
/etc/init.d/brltty.
So, the lsb header of /etc/init.d/brltty should read as follows:

### BEGIN INIT INFO
# Provides:  brltty
# Required-Start:mountkernfs $local_fs
# Required-Stop:
# Should-Start:  udev
# Should-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Braille terminal driver
# Description: Used to provide access to refreshable braille terminals.
### END INIT INFO

Implementing this fix to brltty in debian would be much appreciated.
Thank you.


-- System Information:
Debian Release: 11.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-8-amd64 (SMP w/1 CPU thread)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages brltty depends on:
ii  init-system-helpers1.60
ii  libasound2 1.2.4-1.1
ii  libbluetooth3  5.55-3.1
ii  libbrlapi0.8   6.3+dfsg-1
ii  libc6  2.31-13
ii  libcap21:2.44-1
ii  libdbus-1-31.12.20-2
ii  libelogind0 [libsystemd0]  246.9.1-1+debian1
ii  libexpat1  2.2.10-2
ii  libglib2.0-0   2.66.8-1
ii  libgpm21.20.7-8
ii  libicu67   67.1-7
ii  liblouis20 3.16.0-1
ii  libncursesw6   6.2+20201114-2
ii  libpcre2-32-0  10.36-2
ii  libpolkit-gobject-1-0  0.105-31
ii  libtinfo6  6.2+20201114-2
ii  lsb-base   11.1.0
ii  policykit-10.105-31

Versions of packages brltty recommends:
ii  python3  3.9.2-3

Versions of packages brltty suggests:
pn  brltty-speechd   
ii  brltty-x11   6.3+dfsg-1
pn  console-braille  

-- no debconf information

Bug#992218: xfce4-clipman floods .xsession-errors

[Gregory]

Package: xfce4-clipman
Version: 2:1.4.3-1
Severity: important
Justification: log file files entire disk

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Gregory 
To: Debian Bug Tracking System 
Subject: xfce4-clipman: none
X-Debbugs-Cc: greg...@eeye.io

Package: xfce4-clipman
Version: 2:1.4.3-1
Severity: important

Dear Maintainer,

On a recently installed system xfce4-clipman floods ~/.xsession-errors with 
messages like:
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:03.999: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.277: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.533: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:09.875: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:27.747: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:30.150: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:31.361: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:48.705: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
  (xfce4-clipman:960): Gdk-CRITICAL **: 15:50:49.469: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed

See the attached file for more.

Unfortunately, the .xsession-errors file eventually filled up the entire hard 
disk.
Disabling and removing the clipman plugin from the panel seems to have solved 
the issue.

A similar, or identical, bug was reported to the XFCE community in February 
2020 and apparently fixed.
See this link:
  https://gitlab.xfce.org/panel-plugins/xfce4-clipman-plugin/-/issues/24


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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-clipman depends on:
ii  libc6   2.28-10
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libqrencode44.0.2-1
ii  libx11-62:1.6.7-1+deb10u2
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  libxtst62:1.2.3-1

xfce4-clipman recommends no packages.

xfce4-clipman suggests no packages.

-- no debconf information

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

Kernel: Linux 4.19.0-17-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-clipman depends on:
ii  libc6   2.28-10
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-2+deb10u3
ii  libgtk-3-0  3.24.5-1
ii  libqrencode44.0.2-1
ii  libx11-62:1.6.7-1+deb10u2
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  libxtst62:1.2.3-1

xfce4-clipman recommends no packages.

xfce4-clipman suggests no packages.

-- no debconf information
** (xfce4-clipman:960): WARNING **: 23:00:15.240: Unable to register 
GApplication: An object is already exported for the interface 
org.gtk.Application at /org/xfce/clipman
(xfce4-clipman:960): GLib-GIO-CRITICAL **: 23:00:15.240: 
g_application_get_is_remote: assertion 'application->priv->is_registered' failed
(xfce4-clipman:960): GLib-WARNING **: 23:00:15.240: g_set_application_name() 
called multiple times
xfce4-panel-Message: 23:00:18.672: Plugin xfce4-clipman-plugin-6 has been 
automatically restarted after crash.
(xfce4-clipman:960): GLib-CRITICAL **: 23:00:42.707: Source ID 49 was not found 
when attempting to remove it
(xfce4-clipman:960): GLib-CRITICAL **: 23:02:01.496: Source ID 250 was not 
found when attempting to remove it
(xfce4-clipman:960): Gdk-CRITICAL **: 23:02:01.746: 
gdk_window_get_device_position_double: assertion 'GDK_IS_WINDOW (window)' failed
(xfce4-clipman:960): Gdk

Bug#983547: [Pkg-julia-devel] Bug#983547: julia-common: julia-config.jl does not find libjulia.so

[Gregory None]

Hi Graham

Le ven. 26 févr. 2021 à 10:39, Graham Inggs  a écrit :

> Hi Gregory
>
> On Fri, 26 Feb 2021 at 02:48, Gregory  wrote:
> > Try for example:
> > $/usr/share/julia/julia-config.jl --allflags
> >
> > It will return (among other things):
> > libjulia.so: cannot open shared object file: no such file or directory
> >
> > Adding a symlink libjulia.so that points to libjulia.so.1.5 (package
> libjulia1)
> > is a workaround of course.
>
> Instead of adding the symlink, try installing the libjulia-dev package.
>

That worked like a charm, thanks!
__
Greg

Bug#983547: julia-common: julia-config.jl does not find libjulia.so

[Gregory]

Package: julia-common
Version: 1.5.3+dfsg-3
Severity: normal
X-Debbugs-Cc: greg.van2...@gmail.com

Dear Maintainer,

To embed Julia in a C program it's possible to use the script:
/usr/share/julia/julia-config.jl
But in Debian it is not usable with the following args:
--ldflags or --ldlibs

This script is a simple tool to know automatically which parameter to
give to gcc when embeding Julia in a C program. It's usable in Julia
from julialang.org. This is in fact an old "bug" in the Debian package.

Try for example:
$/usr/share/julia/julia-config.jl --allflags

It will return (among other things):
libjulia.so: cannot open shared object file: no such file or directory

Adding a symlink libjulia.so that points to libjulia.so.1.5 (package libjulia1)
is a workaround of course.




-- System Information:
Distributor ID: Debian
Description:Debian
Release:
Codename:   sid
Architecture: x86_64

Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

julia-common depends on no packages.

Versions of packages julia-common recommends:
ii  julia  1.5.3+dfsg-3

julia-common suggests no packages.

-- no debconf information

Bug#979978: lime-forensics-dkms: unable to make or make install due to error set_fs

[Gregory Lamarche]

Package: lime-forensics-dkms
Version: 1.9.1-1
Severity: normal
Tags: ftbfs

Dear Maintainer,

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

   * What led up to the situation? Trying to install lime-forensics-dkms
   * What exactly did you do (or not do) that was effective (or 
 ineffective)? tried to install via apt
   * What was the outcome of this action? instead of building the modules it 
just errors out and gives error
‘setup_tcp’:
/usr/src/lime-forensics-1.9.1-1/tcp.c:77:10: error: implicit 
declaration of function ‘get_fs’; did you mean ‘sget_fc’? 
[-Werror=implicit-function-declaration]
/usr/src/lime-forensics-1.9.1-1/tcp.c:77:10: error: incompatible types when 
assigning to type ‘mm_segment_t’ from type ‘int’
/usr/src/lime-forensics-1.9.1-1/tcp.c:78:5: error: implicit declaration of 
function ‘set_fs’; did you mean ‘sget_fc’? 
[-Werror=implicit-function-declaration]
   78 | set_fs(KERNEL_DS);
  | ^~
/usr/src/lime-forensics-1.9.1-1/tcp.c:78:12: error: ‘KERNEL_DS’ undeclared 
(first use in this function); did you mean ‘KERNFS_NS’?
   78 | set_fs(KERNEL_DS);
/usr/src/lime-forensics-1.9.1-1/tcp.c:78:12: error: ‘KERNEL_DS’ undeclared 
(first use in this function); did you mean ‘KERNFS_NS’?
   78 | set_fs(KERNEL_DS);
/usr/src/lime-forensics-1.9.1-1/tcp.c:78:12: note: each undeclared identifier 
is reported only once for each function it appears in
/usr/src/lime-forensics-1.9.1-1/tcp.c:49:12: warning: unused variable ‘opt’ 
[-Wunused-variable]

   * What outcome did you expect instead? for the application to compile and 
build the modules 

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


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lime-forensics-dkms depends on:
ii  dkms  2.8.4-1

Versions of packages lime-forensics-dkms recommends:
ii  linux-headers-amd64  5.10.5-1

lime-forensics-dkms suggests no packages.

-- no debconf information

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,



* When used, pygments only provide reference tags (GRTAGS) not 
definition tags




That's correct AFAIK.



* The definitions were provided by /usr/bin/ctags (in 6.4.4-3). "ctags" 
is usually a symlink pointing to one of few possible ctags 
implementations - ctags.emacs, exuberant-ctags, universal-ctags the ones 
I've come across.




Correct again.



* The pygments plugin script (/usr/share/global/gtags/script) has a 
dependency on exuberant ctags but may also be able compatible with other 
ctags implementations. It is possible to override this by using 
"ctagscom=" in the config file.




That's correct, except that there is no need to make this dependency too 
strict.  Universal Ctags is a fork of Exuberant Ctags, whose development 
has stopped some ten years ago.  Which means that Pygments works with 
Universal Ctags, and that the dependency is in fact "exuberant-ctags | 
universal-ctags".  With only Emacs ctags is installed, gtags with pygments 
displays:


/usr/bin/ctags: unrecognized option '--filter'
Try '/usr/bin/ctags --help' for a complete list of options.



Looking at these, the changes introduced in 6.4.4-4 seem to be headed in 
the right direction.




I do not fully agree with this statement.  I believe that Global should 
honor the choice of the user, who selected an implementation of ctags with 
Debian's "alternatives".  Perhaps there should be a better warning than 
the "unrecognized option '--filter'" when neither exuberant-ctags nor 
universal-ctags is installed.


Gregory

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,

The bug is a modification in gtags.conf:

 pygments-parser|Pygments plug-in parser:\
:tc=common:\
-   :ctagscom=/usr/bin/ctags:\
+   :ctagscom=/usr/bin/ctags-exuberant:\
:pygmentslib=$libdir/gtags/pygments-parser.la:\
:langmap=ABAP\:.abap:\
:langmap=ANTLR\:.G.g:\

When exuberant-ctags (which is not a dependency of global) is not 
installed, definitions are not indexed.


Gregory

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Hi Punit,

On my computer this is the output:

echo 'int main(){return 0;}' > main.c
export GTAGSLABEL=pygments

sudo dpkg -i global_6.6.4-3_amd64.deb
gtags -v
[Tue Aug 11 12:58:15 UTC 2020] Gtags started.
 Using configuration file '/etc/gtags/gtags.conf'.
 Using configuration label 'pygments'.
 Using plug-in parser.
[Tue Aug 11 12:58:15 UTC 2020] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of main.c
[Tue Aug 11 12:58:15 UTC 2020] Done.
gtags -d GTAGS
 __.COMPNAME __.COMPNAME
 __.COMPRESS __.COMPRESS ddefine ttypedef
 __.VERSION  __.VERSION 6
main1 @n 1 int @n(){return 0;}

sudo dpkg -i global_6.6.4-4_amd64.deb
gtags -v
[Tue Aug 11 12:59:10 UTC 2020] Gtags started.
 Using configuration file '/etc/gtags/gtags.conf'.
 Using configuration label 'pygments'.
 Using plug-in parser.
[Tue Aug 11 12:59:10 UTC 2020] Creating 'GTAGS' and 'GRTAGS'.
 [1] extracting tags of main.c
[Tue Aug 11 12:59:10 UTC 2020] Done.
gtags -d GTAGS
 __.COMPNAME __.COMPNAME
 __.COMPRESS __.COMPRESS ddefine ttypedef
 __.VERSION  __.VERSION 6

Gregory

Bug#968231: global: does not index definitions with pygments anymore

[Gregory Heytings]

Package: global
Version: 6.6.4-4
Severity: important
X-Debbugs-Cc: g...@sdf.org

Dear Maintainer,

Version 6.6.4-4 of the package does not index definitions with 
GTAGSLABEL=pygments.  Version 6.6.4-3 did.  Steps to reproduce the bug:

echo 'int main(){return 0;}' > main.c
export GTAGSLABEL=pygments
gtags
gtags -d GTAGS | grep -v '^ '

The last command displays "main" with 6.6.4-3, and nothing with 6.6.4-4.

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages global depends on:
ii  emacsen-common  3.0.4
ii  libc6   2.31-2
ii  libltdl72.4.6-14
ii  libncurses6 6.2-1
ii  libsqlite3-03.32.3-1
ii  libtinfo6   6.2-1

Versions of packages global recommends:
ii  python3  3.8.2-3

Versions of packages global suggests:
pn  doxygen 
pn  exuberant-ctags 
ii  firefox-esr [www-browser]   68.11.0esr-1
pn  id-utils
ii  python3-pygments2.3.1+dfsg-4
ii  w3m [www-browser]   0.5.3-38

-- no debconf information

Bug#966828: emacs: Fatal error 11: Segmentation fault

[Gregory Mounie]

Package: emacs-gtk
Followup-For: Bug #966828

Dear Maintainer,

Before LibX11 being updated, a workaround is to have a
defined XMODIFIERS variable, even to nothing.

export XMODIFIERS=
emacs

or even

XMODIFIERS= emacs # with a space after the = !

Hope this help
Grégory Mounié

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.3+1-2
ii  emacs-common   1:26.3+1-2
ii  libacl12.2.53-8
ii  libasound2 1.2.2-2.3
ii  libc6  2.31-2
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.20-1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.2+dfsg-3
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libgif75.1.9-1
ii  libglib2.0-0   2.64.4-1
ii  libgnutls303.6.14-2+b1
ii  libgpm21.20.7-6
ii  libgtk-3-0 3.24.20-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:2.0.5-1.1
ii  liblcms2-2 2.9-4+b1
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.11.24+dfsg-1
ii  libmagickwand-6.q16-6  8:6.9.11.24+dfsg-1
ii  libotf00.9.13-7
ii  libpango-1.0-0 1.44.7-4
ii  libpng16-161.6.37-2
ii  librsvg2-2 2.48.7-1
ii  libselinux13.1-2
ii  libsm6 2:1.2.3-1
ii  libsystemd0245.7-1
ii  libtiff5   4.1.0+git191117-2
ii  libtinfo6  6.2-1
ii  libx11-6   2:1.6.10-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-2
ii  libxft22.3.2-2
ii  libxml22.9.10+dfsg-5+b1
ii  libxpm41:3.5.12-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-2

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:26.3+1-1

-- no debconf information

Bug#966691: emacs-gtk: Segmentation fault with libx11-6 v. 2:1.6.10-1

[Gregory Mounie]

Package: emacs-gtk
Version: 1:26.3+1-2
Followup-For: Bug #966691

Dear Maintainer,

Compiling emacs from source produces the same results (26.3 branch or
later, including master). I just send a patch upstream in bug-gnu-emacs
mailing list.

In src/xfns.c in create_frame_xic (line 2551 in upstream 26.3 branch):

The code assume that if the xim pointer is set then the xim_styles pointer is 
also set.
This is apparently not always true anymore with this X11 update. Hopefully, the 
patch
seems trivial.

The segfaulting lines are:

xim = FRAME_X_XIM (f);
if (!xim) <-- should be:  if (!xim || ! FRAME_X_XIM_STYLES (f))
   goto out;

/* Determine XIC Style */
xic_style = best_xim_style (FRAME_X_XIM_STYLES (f)); <-- otherwise SEGFAULT here

 Looking at the bug, may be setting a XIM input is also a possible temporary 
workaround.
 Grégory Mounié

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

Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages emacs-gtk depends on:
ii  emacs-bin-common   1:26.3+1-2
ii  emacs-common   1:26.3+1-2
ii  libacl12.2.53-8
ii  libasound2 1.2.2-2.3
ii  libc6  2.31-2
ii  libcairo2  1.16.0-4
ii  libdbus-1-31.12.20-1
ii  libfontconfig1 2.13.1-4.2
ii  libfreetype6   2.10.2+dfsg-3
ii  libgdk-pixbuf2.0-0 2.40.0+dfsg-5
ii  libgif75.1.9-1
it  libglib2.0-0   2.64.4-1
ii  libgnutls303.6.14-2+b1
ii  libgpm21.20.7-6
ii  libgtk-3-0 3.24.20-1
ii  libice62:1.0.9-2
ii  libjpeg62-turbo1:2.0.5-1.1
ii  liblcms2-2 2.9-4+b1
ii  libm17n-0  1.8.0-2
ii  libmagickcore-6.q16-6  8:6.9.11.24+dfsg-1
ii  libmagickwand-6.q16-6  8:6.9.11.24+dfsg-1
ii  libotf00.9.13-7
ii  libpango-1.0-0 1.44.7-4
ii  libpng16-161.6.37-2
ii  librsvg2-2 2.48.7-1
ii  libselinux13.1-2
ii  libsm6 2:1.2.3-1
ii  libsystemd0245.7-1
ii  libtiff5   4.1.0+git191117-2
ii  libtinfo6  6.2-1
ii  libx11-6   2:1.6.10-1
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-2
ii  libxft22.3.2-2
ii  libxml22.9.10+dfsg-5+b1
ii  libxpm41:3.5.12-1
ii  libxrender11:0.9.10-1
ii  zlib1g 1:1.2.11.dfsg-2

emacs-gtk recommends no packages.

Versions of packages emacs-gtk suggests:
ii  emacs-common-non-dfsg  1:26.3+1-1

-- no debconf information

Bug#962655: remmina: Remmina crashes when disconnecting from last open RDP session

[Miah Gregory]

Package: remmina
Version: 1.4.5+dfsg-1
Severity: normal

Dear Maintainer,

$ remmina --full-version
Remmina plugin glibsecret (type=Secret) has registered but not yet
initialized/activated. Initialization order is 2000.
Secret plugin glibsecret has been successfully initialized and will be
your
default secret plugin

org.remmina.Remmina - 1.4.5 (git n/a)

NAMETYPEDESCRIPTION
PLUGIN AND LIBRARY VERSION
RDP ProtocolRDP - Remote Desktop Protocol
RDP plugin: 1.4.5 (Git n/a), Compiled with libfreerdp: 2.0.0-dev5
(2693389a+debian), Running with libfreerdp: 2.1.1 (rev 2.1.1), H.264:
Yes
RDPFFileRDP - RDP File Handler
RDP plugin: 1.4.5 (Git n/a), Compiled with libfreerdp: 2.0.0-dev5
(2693389a+debian), Running with libfreerdp: 2.1.1 (rev 2.1.1), H.264:
Yes
RDPSPreference  RDP - Preferences
RDP plugin: 1.4.5 (Git n/a), Compiled with libfreerdp: 2.0.0-dev5
(2693389a+debian), Running with libfreerdp: 2.1.1 (rev 2.1.1), H.264:
Yes
VNC ProtocolRemmina VNC Plugin
1.4.5
VNCIProtocolRemmina VNC listener Plugin
1.4.5
glibsecret  Secret  Secured password storage in the
GNOME
keyring   1.4.5

Build configuration: HAVE_ARPA_INET_H=1 HAVE_ERRNO_H=1 HAVE_FCNTL_H=1
HAVE_NETDB_H=1 HAVE_NETINET_IN_H=1 HAVE_NETINET_TCP_H=1
HAVE_SYS_SOCKET_H=1
HAVE_SYS_UN_H=1 HAVE_TERMIOS_H=1 HAVE_UNISTD_H=1 WITH_APPINDICATOR=ON
WITH_AVAHI=ON WITH_CUPS=ON WITH_FREERDP_MASTER=OFF WITH_GCRYPT=ON
WITH_GETTEXT=ON WITH_ICON_CACHE=ON WITH_IPP=OFF WITH_KF5WALLET=ON
WITH_LIBRARY_VERSIONING=ON WITH_LIBSECRET=ON WITH_LIBSSH=ON
WITH_LIBVNCSERVER=ON WITH_MANPAGES=ON WITH_SPICE=ON WITH_SSE2=ON
WITH_TRANSLATIONS=ON WITH_UPDATE_DESKTOP_DB=ON WITH_VTE=ON WITH_WWW=ON
Build type:  None
CFLAGS:  -g -O2 -fdebug-prefix-map=/build/remmina-
nuX1VW/remmina-1.4.5+dfsg=. -fstack-protector-strong -Wformat
-Werror=format-
security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -g
Compiler:GNU, 9.3.0
Target architecture: x64

   * What led up to the situation?

Start remmina, either automatically at login, or via a console shell.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Connected to a saved RDP server, then logged out of the remote machine,
causing
the connection to terminate normally.

   * What was the outcome of this action?

Remmina closed down, with the following messages on the console:

[12:01:00:449] [11315:11330] [INFO][com.freerdp.core] -
rdp_set_error_info:freerdp_set_last_error_ex resetting error state
[12:01:00:550] [11315:11330] [INFO][com.freerdp.core] -
ERRINFO_LOGOFF_BY_USER
(0x000C):The disconnection was initiated by the user logging off
their
session on the server.
[12:01:00:550] [11315:11330] [ERROR][com.freerdp.core] -
rdp_set_error_info:freerdp_set_last_error_ex ERRINFO_LOGOFF_BY_USER
[0x0001000C]
[12:01:00:550] [11315:11330] [ERROR][com.freerdp.core.rdp] -
rdp_recv_tpkt_pdu:
rdp_recv_deactivate_all() fail
[12:01:00:550] [11315:11330] [ERROR][com.freerdp.core.transport] -
transport_check_fds: transport->ReceiveCallback() - -1

   * What outcome did you expect instead?

Remmina to continue running.



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

Kernel: Linux 5.2.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8),
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages remmina depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.18-1
ii  dbus-x11 [dbus-session-bus]   1.12.18-1
ii  libavahi-client3  0.8-3
ii  libavahi-common3  0.8-3
ii  libavahi-ui-gtk3-00.8-3
ii  libayatana-appindicator3-10.5.4-2
ii  libc6 2.30-8
ii  libcairo2 1.16.0-4
ii  libgcrypt20   1.8.5-5
ii  libglib2.0-0  2.64.3-1
ii  libgtk-3-03.24.20-1
ii  libjson-glib-1.0-01.4.4-2
ii  libpango-1.0-01.44.7-4
ii  libsodium23   1.0.18-1
ii  libsoup2.4-1  2.70.0-1
ii  libssh-4  0.9.4-1
ii  libssl1.1 1.1.1g-1
ii  libvte-2.91-0 0.60.2-1+b1
ii  remmina-common1.4.5+dfsg-1

Versions of packages remmina recommends:
ii  remmina-plugin-rdp 

Bug#940530: Add CONFIG_BRCMFMAC_SDIO=y to linux-image-rpi

[Gregory Johnson]

Package: linux-image-4.19.0-6-rpi
Version: 4.19.67-2

The linux-image-rpi kernel for armel does not
include CONFIG_BRCMFMAC_SDIO=y.  This config option is necessary to support
the WiFi on the Raspberry Pi Zero W.  I have verified that enabling this
option fixes the problem on my Pi Zero W by building a version of the
kernel package with the option enabled following
https://wiki.debian.org/HowToCrossBuildAnOfficialDebianKernelPackage.

I installed Debian using the images available here:
https://wiki.debian.org/RaspberryPiImages

Bug#939866: mariadb-server-10.1: replication hangs in state "Slave_IO_Running: Preparing" after upgrade from 10.1.38 to 10.1.41

[Gregory Colpart]

Hello,

We confirm this serious bug.

After upgrading from 10.1.38-0+deb9u1 to 10.1.41-0+deb9u1,
replication is completely broken.

For the moment we `apt-mark old` mariadb package with
10.1.38-0+deb9u1 version on all our servers.

Regards,
-- 
Grégory Colpart - CEO Evolix - Clé OpenPGP : 0x44975278B8612B5D
Evolix - Hébergement et Infogérance Open Source
Marseille (37 rue Guibal, Pôle Média, 13003) / Aix / Paris / Montréal
http://evolix.com | Twitter: @Evolix @EvolixNOC | http://blog.evolix.com

Bug#920900: pkgdata in icu-devtools(63.2-2) pkg on deb10 stable still use icu-config

[Gregory Auzanneau]

Dear Maintainer,

As you confirm icu-config is now deprecated.

But pkgdata in icu-devtools(63.2-2) on deb10 stable is still referring 
to icu-config :

$ pkgdata -p bin_mkltfs -m static packagelist.txt
sh: 1: icu-config: not found
sh: 1: icu-config: not found
pkgdata: icu-config: No icu-config found. (fix PATH or use -O option)
 required parameter is missing: -O is required for static and shared 
builds.

Run 'pkgdata --help' for help.

icu-63.2/source/tools/pkgdata/pkgdata.cpp :
line 2137 -> 2172 :
/* Try calling icu-config directly to get the option file. */
 static int32_t pkg_getOptionsFromICUConfig(UBool verbose, UOption 
*option) {

#if U_HAVE_POPEN
LocalPipeFilePointer p;
size_t n;
static char buf[512] = "";
icu::CharString cmdBuf;
UErrorCode status = U_ZERO_ERROR;
const char cmd[] = "icu-config --incpkgdatafile";
char dirBuf[1024] = "";
/* #1 try the same path where pkgdata was called from. */
findDirname(progname, dirBuf, UPRV_LENGTHOF(dirBuf), );
if(U_SUCCESS(status)) {
  cmdBuf.append(dirBuf, status);
  if (cmdBuf[0] != 0) {
cmdBuf.append( U_FILE_SEP_STRING, status );
  }
  cmdBuf.append( cmd, status );

  if(verbose) {
fprintf(stdout, "# Calling icu-config: %s\n", cmdBuf.data());
  }
  p.adoptInstead(popen(cmdBuf.data(), "r"));
[...]

On http://userguide.icu-project.org/howtouseicu, there is an 
recommendation about that :
pkgdata uses the icu-config script in order to locate pkgdata.inc. If 
you are not building ICU using the supplied tools, you may need to 
modify this file directly to allow static and dll modes to function.


Thanks for the good job, keep up with it !
Grégory

Bug#921030: Fails to import the ansible module since its migration to Python 3

[Gregory Colpart]

Hi Samuel,

On Sun, Feb 24, 2019 at 03:25:26AM +, Samuel Henrique wrote:
> I'm working on this: https://salsa.debian.org/debian/ansible-lint
> I think i'm close to an upload now, there's only some problems with .js
> sources.

I review your patches and all is right, in particular your removal of
docs in upstream tarball. Thank you for your work!

Regards,
-- 
Grégory Colpart

Bug#788327: Swift in Debian

[Gregory Williams]

Hello,

Jonas pointed me at this thread. I’m the author of the RDF triplestore[1] he 
referenced, and would *love* to see the swift tools packaged and available in 
Debian. I suspect the ABI stability work coming in swift 5 might bring benefits 
and more widespread use to a future swift-on-debian package, but I would 
personally find immediate use from such a package, whether that were swift 4.x 
or a future 5.x.

Thanks!
Greg Williams

[1] https://github.com/kasei/kineo 

Bug#915488: initramfs-tools-core: after dist-upgrade to testing my system can't boot, need to go to recovery then init 5

[gregory bahde]

Package: initramfs-tools-core
Version: 0.132
Severity: critical
Tags: patch
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
upgrading from stretch to testing
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
edited /usr/share/initramfs-tools/hooks/lvm2
on line 29

to add 60-persistent-storage-lvm.rules

so that it goes like
"for rules in 56-lvm.rules 60-persistent-storage-lvm.rules 69-lvm-metad.rules;
do"

instead of
"
for rules in 56-lvm.rules 69-lvm-metad.rules; do
"
   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (901, 'testing'), (500, 'stable-updates'), (500, 'stable'), (500, 
'oldstable'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-3-amd64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages initramfs-tools-core depends on:
ii  coreutils8.30-1
ii  cpio 2.12+dfsg-6
ii  e2fsprogs1.44.4-2
ii  klibc-utils  2.0.4-14
ii  kmod 25-2
ii  udev 239-13

Versions of packages initramfs-tools-core recommends:
ii  busybox  1:1.27.2-3

Versions of packages initramfs-tools-core suggests:
ii  bash-completion  1:2.8-4

-- debconf-show failed

Bug#915063: xen-hypervisor-4.8-amd64: xen 4.8 fails to boot

[gregory bahde]

Package: src:xen
Version: 4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

   * What led up to the situation?
I installed xen hypervisor 4.8 and rebooted to Xen, I am used to xen and run it
on servers
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
try grub kernel xen parameters (iommu )
   * What was the outcome of this action?
blackscreen at gdm3 login session
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(11, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

xen-hypervisor-4.8-amd64 depends on no packages.

Versions of packages xen-hypervisor-4.8-amd64 recommends:
ii  xen-utils-4.8  4.8.4+xsa273+shim4.10.1+xsa273-1+deb9u10

xen-hypervisor-4.8-amd64 suggests no packages.

-- debconf-show failed

Bug#913021: carbon-c-relay: make the build reproducible

[Nicholas M Gregory]

Source: carbon-c-relay
Version: 3.2-1
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi there,

While working on the reproducible builds project
(https://wiki.debian.org/ReproducibleBuilds), we noticed that
carbon-c-relay could not be built reproducibly.

The attached patch changes the build system to first attempt to use
the SOURCE_DATE_EPOCH envvar
(https://reproducible-builds.org/specs/source-date-epoch/) to
determine build date, then falls back to the git commit date, then the
current date.

Best,
-Nick Gregory

 begin patch 
--- Makefile.am.orig 2017-10-21 10:39:41.0 -0400
+++ Makefile.am 2018-11-05 22:45:30.772368908 -0500
@@ -16,7 +16,11 @@

 CFLAGS ?= -O2 -Wall -Wshadow -pipe

-GIT_VERSION := $(shell git describe --abbrev=6 --dirty --always
2>/dev/null || date +%F)
+GIT_VERSION := $(shell \
+ date -u -d "@${SOURCE_DATE_EPOCH}" "+%F" 2>/dev/null || \
+ date -u -r "${SOURCE_DATE_EPOCH}" "+%F" 2>/dev/null || \
+ git describe --abbrev=6 --dirty --always 2>/dev/null || \
+ date +%F)
 GVCFLAGS = -DGIT_VERSION=\"$(GIT_VERSION)\"

 override CFLAGS += $(GVCFLAGS) -pthread

Bug#912299: blender: make the build reproducible

[Nicholas M Gregory]

Source: blender
Version: 2.79.b+dfsg0-4
Severity: wishlist
Tags: patch
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Hi there,

While working on the reproducible builds project
(https://wiki.debian.org/ReproducibleBuilds), we noticed that blender
could not be built reproducibly.

The attached patch changes the build system to use the
SOURCE_DATE_EPOCH envvar (if set) in place of the current build
date/time to make blender build reproducibly.

Best,
-Nick Gregory

 begin patch 
diff --git a/build_files/cmake/buildinfo.cmake
b/build_files/cmake/buildinfo.cmake
index a43b99f..ab7d3e3 100644
--- a/build_files/cmake/buildinfo.cmake
+++ b/build_files/cmake/buildinfo.cmake
@@ -148,12 +148,21 @@ endif()
 # BUILD_PLATFORM and BUILD_PLATFORM are taken from CMake
 # but BUILD_DATE and BUILD_TIME are platform dependent
 if(UNIX)
-   if(NOT BUILD_DATE)
-   execute_process(COMMAND date "+%Y-%m-%d"
OUTPUT_VARIABLE BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
-   endif()
-   if(NOT BUILD_TIME)
-   execute_process(COMMAND date "+%H:%M:%S"
OUTPUT_VARIABLE BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
-   endif()
+if(DEFINED ENV{SOURCE_DATE_EPOCH})
+execute_process(COMMAND "date" "-u" "-d"
"@$ENV{SOURCE_DATE_EPOCH}" "+%Y-%m-%d"
+OUTPUT_VARIABLE BUILD_DATE
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+execute_process(COMMAND "date" "-u" "-d"
"@$ENV{SOURCE_DATE_EPOCH}" "+%H:%M:%S"
+OUTPUT_VARIABLE BUILD_TIME
+OUTPUT_STRIP_TRAILING_WHITESPACE)
+else()
+if(NOT BUILD_DATE)
+execute_process(COMMAND date "+%Y-%m-%d" OUTPUT_VARIABLE
BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
+if(NOT BUILD_TIME)
+execute_process(COMMAND date "+%H:%M:%S" OUTPUT_VARIABLE
BUILD_TIME OUTPUT_STRIP_TRAILING_WHITESPACE)
+endif()
+endif()
 elseif(WIN32)
if(NOT BUILD_DATE)
execute_process(COMMAND cmd /c date /t OUTPUT_VARIABLE
BUILD_DATE OUTPUT_STRIP_TRAILING_WHITESPACE)

Bug#893839: sqwebmail: the group and owner for /var/cache/sqwebmail are incorrect

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: normal

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (which is based on debian 
stretch), I noticed messages like the following in /var/log/mail.log:
"Jan 31 12:30:56 vserver sqwebmaild: maildircache: Cache create failure - unable
to create file /var/cache/sqwebmail/210754/gr/greg."

I found that the default group and owner for /var/cache/sqwebmail was courier 
and courier respectively. Changing the group and owner to bin and bin 
respectively resolved this for me.


-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
* sqwebmail/install-www: symlink
  sqwebmail/dictionary: default

Bug#893838: sqwebmail: default sendit.sh script doesn't work with postfix

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: important

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (which is based on debian 
stretch), I found that users can't send mail when using the sqwebmail 
interface. When a message is composed, and the send button is chosen, an error 
similar to the following appears:
"sendmail: fatal: g...@gregn.net(1000): Recipient addresses must be specified on
+the command line or via the -t option"
I am using postfix as my MTA. The problem is caused by the 
/usr/lib/courier/sqwebmail/sendit.sh script. The default invocation of sendmail 
doesn't work with postfix. For postfix users, the end of the sendit.sh script 
should read:
"exec /usr/sbin/sendmail -OI -t -f "$1"
# exec /usr/sbin/sendmail $DSN -f "$1""

The first invocation needs to be uncommented, and the second needs to be 
commented out. I would suggest that when the package is installed or upgraded, 
the user should be advised to look at the /usr/lib/courier/sqwebmail/sendit.sh 
script, and edit it as necessary. Ideally, it would be nice if debconf detected 
which MTA is installed, and automagicly adjusted sendit.sh to match what the 
sendmail binary of the MTA expects.


-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
  sqwebmail/dictionary: default
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
* sqwebmail/install-www: symlink

Bug#893830: sqwebmail cgi can't access sqwebmail.sock

[Gregory Nowak]

Package: sqwebmail
Version: 5.8.3+0.76.3-5
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Upon upgrading from devuan jessie to devuan Ascii (based on debian stretch), I 
found that accessing the sqwebmail CGI resulted in a page which displayed a 
system unavailable message.
It turns out the problem was that the sqwebmail CGI couldn't access the unix 
domain sqwebmail.sock socket. This is because the permissions on 
/var/lib/courier are 750 by default. Changing the permissions on 
/var/lib/courier to 755 resolves this issue.

-- System Information:
Debian Release: 9
Architecture: amd64
 (x86_64)

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

Versions of packages sqwebmail depends on:
ii  apache2 [httpd-cgi] 2.4.25-3+deb9u3
ii  courier-authlib 0.66.4-9
ii  courier-base0.76.3-5
ii  cron3.0pl1-128+deb9u1
ii  debconf [debconf-2.0]   1.5.61
ii  expect  5.45-7+deb9u1
ii  iamerican [ispell-dictionary]   3.4.00-5
ii  ibritish [ispell-dictionary]3.4.00-5
ii  init-system-helpers 1.48+devuan2.0
ii  ispell  3.4.00-5
ii  libc6   2.24-11+deb9u3
ii  libcourier-unicode1 1.4-3+b1
ii  libfam0 2.7.0-17.2+b1
ii  libgdbm31.8.3-14
ii  libidn111.33-1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpcre32:8.39-3
ii  maildrop2.8.4-2
ii  postfix [mail-transport-agent]  3.1.8-0+deb9u1
ii  sysvinit-utils  2.88dsf-59.9+devuan2

Versions of packages sqwebmail recommends:
pn  courier-pcp  

Versions of packages sqwebmail suggests:
ii  courier-doc  0.76.3-5
ii  gnupg2.1.18-8~deb9u1

-- debconf information:
* sqwebmail/calendarmode: local
  sqwebmail/install-www-backup: symlink
  sqwebmail/dictionary: default
* sqwebmail/install-www: symlink

Bug#873086: #873086 ifupdown script disables IPv6 on parent of VLAN interface

[Gregory Potamianos]

Control: tags -1 +ipv6
Control: severity -1 serious


Hello,

We are also affected by this bug when uprading to stretch
(1.5-13+deb9u1).  Our setup is similar to alexk's.
Assuming a /e/n/i with:

auto bond0
iface bond0 inet static
address 1.2.3.4
netmask 255.255.255.0
[...]

iface bond0 inet6 static
address 1:2:3::4
netmask 64
[...]

auto br100
iface br100 inet static
bridge_ports bond0.100
[...]


when bridge-utils tries to ifup br100, `create_vlan_port()` ends up
disabling ipv6 connectivity in bond0 which receives untagged traffic and
belongs to a completely different broadcast domain from br100. Since we are
using bond0 for the management of the host machine, the upgrade to
stretch breaks our ipv6 connectivity to the host. 

As a temporary workaround we are using a bridge-utils.sh with a patch similar to
JT's. I'm bumping the priority to serious, if you think it's not
appropriate please adjust it accordingly.

Kind Regards,
-- 
Gregory Potamianos
Skroutz S.A
greg...@skroutz.gr

Bug#886152: /usr/bin/nm-applet: Re: nm-applet crashes when trying to start a VPN connection

[Gregory E. Maurer]

Package: network-manager-gnome
Version: 1.8.10-1
Followup-For: Bug #886152

Dear Maintainer,

   I can confirm this on my machine.

   After updating to 1.8.10 I have been unable to connect to a
   previously configured VPN connection throught the menu on the
   nm-applet (left click menu).
   
   Upon opening the submenu for "VPN Connections" and selecting the
   desired connection (a checkbox) the applet segfaults and the icon in the
   notification area disappears. It can be restarted from the command
   line (`nm-applet`) but the same actions produce the same results, and
   a segmentation fault is reported on the commandline.

   Under normal circumstances selecting the checkbox for the configured
   VPN connection would raise a window for VPN selection and password
   entry.

   backtrace below

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

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

Versions of packages network-manager-gnome depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.2-1
ii  dbus-x11 [dbus-session-bus]   1.12.2-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.1-2
ii  libatk1.0-0   2.26.1-2
ii  libc6 2.25-5
ii  libcairo2 1.15.8-3
ii  libgdk-pixbuf2.0-02.36.11-1
ii  libglib2.0-0  2.54.2-5
ii  libgtk-3-03.22.26-2
ii  libjansson4   2.10-1
ii  libmm-glib0   1.6.8-2
ii  libnm01.10.2-1
ii  libnma0   1.8.10-1
ii  libnotify40.7.7-3
ii  libpango-1.0-01.40.14-1
ii  libpangocairo-1.0-0   1.40.14-1
ii  libsecret-1-0 0.18.5-5
ii  libselinux1   2.7-2
ii  network-manager   1.10.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-6

Versions of packages network-manager-gnome recommends:
ii  gnome-keyring3.20.1-2
ii  iso-codes3.77-1
ii  mobile-broadband-provider-info   20170903-1
ii  notification-daemon  3.20.0-2
ii  xfce4-notifyd [notification-daemon]  0.4.1-1

Versions of packages network-manager-gnome suggests:
ii  network-manager-openconnect-gnome  1.2.4-1
pn  network-manager-openvpn-gnome  
pn  network-manager-pptp-gnome 
pn  network-manager-vpnc-gnome 

-- no debconf information

The Backtrace:

*** Error in `nm-applet': double free or corruption (out): 0x55b56b4b0760 
***
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x722fb)[0x7fb1d077a2fb]
/lib/x86_64-linux-gnu/libc.so.6(+0x7895e)[0x7fb1d078095e]
/lib/x86_64-linux-gnu/libc.so.6(+0x791be)[0x7fb1d07811be]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_strfreev+0x29)[0x7fb1d0d34449]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_datalist_clear+0x6b)[0x7fb1d0cf745b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_unref+0x1a2)[0x7fb1d0ff1ea2]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x38e41)[0x7fb1d0d01e41]
/usr/lib/x86_64-linux-gnu/libnm.so.0(+0x62187)[0x7fb1d1f73187]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_datalist_clear+0x6b)[0x7fb1d0cf745b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_object_unref+0x1a2)[0x7fb1d0ff1ea2]
nm-applet(+0x1629c)[0x55b56904b29c]
nm-applet(+0x198fc)[0x55b56904e8fc]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x47724)[0x7fb1d0d10724]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x155)[0x7fb1d0d13e15]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4b1e0)[0x7fb1d0d141e0]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_iteration+0x2c)[0x7fb1d0d1426c]
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0(g_application_run+0x1fd)[0x7fb1d12d1bed]
nm-applet(+0x101b1)[0x55b5690451b1]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1)[0x7fb1d0728561]
nm-applet(+0x102da)[0x55b5690452da]
=== Memory map: 
55b569035000-55b56907d000 r-xp  08:02 142082 
/usr/bin/nm-applet
55b56927d000-55b56927e000 r--p 00048000 08:02 142082 
/usr/bin/nm-applet
55b56927e000-55b56928 rw-p 00049000 08:02 142082 
/usr/bin/nm-applet
55b56b0e1000-55b56b5c6000 rw-p  00:00 0  [heap]
7fb1ac00-7fb1ac021000 rw-p  00:00 0 
7fb1ac021000-7fb1b000 ---p  00:00 0 
7fb1b000-7fb1b0022000 rw-p  00:00 0 
7fb1b0022000-7fb1b400 ---p  00:00 0 

Bug#882158: Info received (LastChance: free trial pure cbdoil Zh)

[Gregory Jordan]

Unsubscribe me from you and your affiliates mailing list

On Dec 1, 2017 4:45 PM, "Debian Bug Tracking System" 
wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian Release Team 
>
> If you wish to submit further information on this problem, please
> send it to 882...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 882158: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882158
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#882158: LastChance: free trial pure cbdoil Zh

[Gregory Jordan]

Send it to 3833 liberty hill road chillicothe,ohio 45601

On Dec 1, 2017 4:26 PM, "Pure.cbd"  wrote:

> The New.cbd drug that is Sweeping the Nation
>
> Scientists are calling this the UltimateCure for StressRelief
>
> Prevents Anxiety and Stress
> Intensive Relief
> Relieves Nausea
> Helpsto Fight Cancer
> Lcwers Incidence of Diabetes
> Promotes Cardiovascular Health
>
>
> 
>
>
> unsubscrib
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On 2017-11-19 18:36, Aurelien Jarno wrote: > Package: release.debian.org
> > Severity: normal > Tags: stretch > User: release.debian.org@packages.
> debian.org > Usertags: pu > > Dear stable release managers, > > I would
> like to upload a new glibc package for the next stretch release. > It
> mostly consists in pulling the release/2.24/master upstream branch. >
> Unfortunately this makes the patch big because: > - it includes patches
> that were applied as debian patches before (mostly > security ones) > -
> upstream decided to backport all the test support from master in order > to
> ease the backport of fixes from master including the corresponding > tests
> > > I have therefore included two diffs, the full debdiff compared to >
> version 2.24-11+deb9u1 currently in stable, and the one comparing the >
> tree with all the patches applied. The biggest part of the later diff >
> comes from the support infrastructure for tests (support/*) or from > tests
> (tst-*). After removing changes which don't end-up in the binary >
> packages, there are less than 600 lines changed. > > Most of the changes
> were already in buster/sid for quite some time, with > the notable
> exception of compatibility with Intel C++ which is only in > sid and
> experimental. > > Thanks for considering, and don't hesitate to ask for
> more details if > needed. I would also like to add the attached an
> additional patch to fix a critical bug which has been filled recently,
> breaking some systems during jessie to stretch upgrades (see bug#882272).
> Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B
> aurel...@aurel32.net http://www.aurel32.net

Bug#876377: ruby2.3: Ruby process stuck on sched_yield busyloop

[Gregory Potamianos]

On Sun, Oct 22, 2017 at 12:39:36PM -0200, Antonio Terceiro wrote:
> On Sun, Oct 01, 2017 at 01:42:36AM +0300, Gregory Potamianos wrote:
> > On Mon, Sep 25, 2017 at 11:44:52AM -0700, Antonio Terceiro wrote:
> > > Hi,
> > > 
> > > thanks for your bug report
> > > [...] 
> > > > Our case seems identical to this [1] bug report. We have applied the 
> > > > patch [2]
> > > > by Eric Wong and the problem seems resolved without causing any other 
> > > > problems.
> > > > 
> > > > [1] https://bugs.ruby-lang.org/issues/13794
> > > > [2] https://80x24.org/spew/20170809232533.14932-...@80x24.org/raw
> > > 
> > > can you provide a minimal test case that can reproduce the issue that
> > > does not take hours/days?
> > The attached script sometimes exits and leaves a stray child process on
> > busyloop when run as:
> > 
> > `while nice -n19 ruby sched_yield_loop.rb; do :; done`
> > 
> > > 
> > > Also, it would be nice to have some feedback from upstream about whether
> > > one of those patches is going to be applied. I would not like to to
> > > carry such patch indefinitely.
> > The patch i mentioned was just merged in [1] and seems to be tagged as
> > needing backport to v2.3 on ruby's bugtracker.
> > 
> > `
> > Backport changed from 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN to
> > 2.2: UNKNOWN, 2.3: REQUIRED, 2.4: REQUIRED
> 
> can you please test the packages from
> https://people.debian.org/~terceiro/ruby-stretch/ to see if you can
> still reproduce the issue?

I have tested your packages and I'm not able to reproduce it.


-- 
Gregory Potamianos
Skroutz S.A
greg...@skroutz.gr

Bug#878871: gnome-shell: segfault error in libmozjs-24.so.0.0.0

[gregory bahde]

Package: gnome-shell
Version: 3.22.3-3
Severity: important
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
Well once a day or so, I have this crash, causing a refresh of GDM,

and eventually issues (my multi monitor setup reinitialisation is then wronged,
with windows not opening and such)
Installed dbg packages to trace next hang, but so far not much more.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable'), (500, 'oldstable'), (11, 'testing'), (10, 'experimental'), (10, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2+b1
ii  evolution-data-server3.22.7-1
ii  gir1.2-accountsservice-1.0   0.6.43-1
ii  gir1.2-atspi-2.0 2.22.0-6+deb9u1
ii  gir1.2-caribou-1.0   0.4.21-1+b1
ii  gir1.2-freedesktop   1.50.0-1+b1
ii  gir1.2-gcr-3 3.20.0-5.1
ii  gir1.2-gdesktopenums-3.0 3.22.0-1
ii  gir1.2-gdm-1.0   3.22.3-3
ii  gir1.2-glib-2.0  1.50.0-1+b1
ii  gir1.2-gnomebluetooth-1.03.20.1-1
ii  gir1.2-gnomedesktop-3.0  3.22.2-1
ii  gir1.2-gtk-3.0   3.22.11-1
ii  gir1.2-gweather-3.0  3.20.4-1
ii  gir1.2-ibus-1.0  1.5.14-3
ii  gir1.2-mutter-3.03.22.3-2
ii  gir1.2-networkmanager-1.01.6.2-3
ii  gir1.2-nmgtk-1.0 1.4.4-1
ii  gir1.2-pango-1.0 1.40.5-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-soup-2.4  2.56.0-2+deb9u1
ii  gir1.2-telepathyglib-0.120.24.1-1.1
ii  gir1.2-telepathylogger-0.2   0.8.2-2
ii  gir1.2-upowerglib-1.00.99.4-4+b1
ii  gjs  1.46.0-1+b2
ii  gnome-backgrounds3.22.1-1
ii  gnome-settings-daemon3.22.2-2+deb9u2
ii  gnome-shell-common   3.22.3-3
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk-bridge2.0-0   2.22.0-2
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-11+deb9u1
ii  libcairo21.14.8-1
ii  libcanberra-gtk3-0   0.30-3
ii  libcanberra0 0.30-3
ii  libcroco30.6.11-3
ii  libdbus-glib-1-2 0.108-2
ii  libecal-1.2-19   3.22.7-1
ii  libedataserver-1.2-223.22.7-1
ii  libgcr-base-3-1  3.20.0-5.1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u1
ii  libgirepository-1.0-11.50.0-1+b1
ii  libgjs0e [libgjs0-libmozjs-24-0] 1.46.0-1+b2
ii  libglib2.0-0 2.50.3-2
ii  libglib2.0-bin   2.50.3-2
ii  libgstreamer1.0-01.10.4-1
ii  libgtk-3-0   3.22.11-1
ii  libical2 2.0.0-0.5+b1
ii  libicu57 57.1-6
ii  libjson-glib-1.0-0   1.2.6-1
ii  libmozjs-24-024.2.0-5.1+b2
ii  libmutter0i  3.22.3-2
ii  libnm-glib4  1.6.2-3
ii  libnm-util2  1.6.2-3
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpolkit-agent-1-0  0.105-18
ii  libpolkit-gobject-1-00.105-18
ii  libpulse-mainloop-glib0  10.0-1+deb9u1
ii  libpulse010.0-1+deb9u1
ii  libsecret-1-00.18.5-3.1
ii  libstartup-notification0 0.12-4+b2
ii  libsystemd0  232-25+deb9u1
ii  

Bug#876377: ruby2.3: Ruby process stuck on sched_yield busyloop

[Gregory Potamianos]

On Mon, Sep 25, 2017 at 11:44:52AM -0700, Antonio Terceiro wrote:
> Hi,
> 
> thanks for your bug report
> [...] 
> > Our case seems identical to this [1] bug report. We have applied the patch 
> > [2]
> > by Eric Wong and the problem seems resolved without causing any other 
> > problems.
> > 
> > [1] https://bugs.ruby-lang.org/issues/13794
> > [2] https://80x24.org/spew/20170809232533.14932-...@80x24.org/raw
> 
> can you provide a minimal test case that can reproduce the issue that
> does not take hours/days?
The attached script sometimes exits and leaves a stray child process on
busyloop when run as:

`while nice -n19 ruby sched_yield_loop.rb; do :; done`

> 
> Also, it would be nice to have some feedback from upstream about whether
> one of those patches is going to be applied. I would not like to to
> carry such patch indefinitely.
The patch i mentioned was just merged in [1] and seems to be tagged as
needing backport to v2.3 on ruby's bugtracker.

`
Backport changed from 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN to
2.2: UNKNOWN, 2.3: REQUIRED, 2.4: REQUIRED
`


[1] https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/60079


Kind regards,
-- 
Gregory Potamianos
Skroutz S.A
greg...@skroutz.gr


sched_yield_loop.rb
Description: application/ruby

Bug#876377: ruby2.3: Ruby process stuck on sched_yield busyloop

[Gregory Potamianos]

Package: ruby2.3
Version: 2.3.3-1+deb9u1
Severity: important
Tags: upstream patch
Forwarded: https://bugs.ruby-lang.org/issues/13794

Hello,

After the upgrade to stretch we keep finding ruby processes (puppet
agents in particular) stuck in a sched_yield busyloop. The stuck process
is always a forked child of the main puppet agent running inside a
timeout block.

The backtrace of the process is the following:

(gdb) thread apply all bt

Thread 2 (Thread 0x7f2dc7904700 (LWP 11226)):
#0  0x7f2dc63bb6ad in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f2dc73fba62 in timer_thread_sleep (gvl=0x5628917b3f28) at
thread_pthread.c:1455
#2  thread_timer (p=0x5628917b3f28) at thread_pthread.c:1563
#3  0x7f2dc7045494 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#4  0x7f2dc63c4aff in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f2dc78fc700 (LWP 11224)):
#0  0x7f2dc63adca7 in sched_yield () from
/lib/x86_64-linux-gnu/libc.so.6
#1  0x7f2dc73fbac5 in native_stop_timer_thread () at
thread_pthread.c:1664
#2  rb_thread_stop_timer_thread () at thread.c:3902
#3  0x7f2dc7341c42 in before_exec_non_async_signal_safe () at
process.c:1175
#4  before_exec () at process.c:1181
#5  rb_f_exec (argc=, argv=) at
process.c:2576

And the offending part of the code is this:

native_stop_timer_thread(void)
{
int stopped;
stopped = --system_working <= 0;

if (TT_DEBUG) fprintf(stderr, "stop timer thread\n");
#if USE_SLEEPY_TIMER_THREAD
if (stopped) {
/* prevent wakeups from signal handler ASAP */
timer_thread_pipe.owner_process = 0;  

/*   
 * however, the above was not enough: the FD may already be
 * captured and in the middle of a write while we are running,
 * so wait for that to finish:
 */  
while (ATOMIC_CAS(timer_thread_pipe.writing, (rb_atomic_t)0, 0)) {
native_thread_yield();
}   
[..]
}

Thread 1 is spinning around `timer_thread_pipe.writing` because someone has
 erroneously bumped it to 1.

(gdb) print timer_thread_pipe
$1 = {normal = {3, 4}, low = {5, 6}, owner_process = 0, writing = 1}


Our case seems identical to this [1] bug report. We have applied the patch [2]
by Eric Wong and the problem seems resolved without causing any other problems.



[1] https://bugs.ruby-lang.org/issues/13794
[2] https://80x24.org/spew/20170809232533.14932-...@80x24.org/raw


Kind regards,
-- 
Gregory Potamianos
Skroutz S.A
greg...@skroutz.gr


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

Kernel: Linux 4.9.0-3-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 ruby2.3 depends on:
ii  libc6 2.24-11+deb9u1
ii  libgmp10  2:6.1.2+dfsg-1
ii  libruby2.32.3.3-1+deb9u1
ii  rubygems-integration  1.11

Versions of packages ruby2.3 recommends:
ii  fonts-lato2.0-1
ii  libjs-jquery  3.1.1-2

ruby2.3 suggests no packages.

-- no debconf information

Bug#873187: linux-image-amd64: Missing tpm_tis module

[Gregory Stark]

Package: linux-image-amd64
Version: 4.9+80+deb9u1
Severity: normal

Hi,

I find that the tpm_tis.ko module is missing in all kernel packages
since 4.9.0-3 (which is the version in Debian 9 installers and the
security archive). This includes all more recent kernels that I've
tried from unstable.

It was present in 4.9.0-2 which makes me wonder if it was removed due
to some last minute security problem before the release of Debian 9.

However this is a severe problem for users of the 2013 Chromebook
Pixel as there was a firmware bug that means suspend/resume doesn't
work unless the tpm chip has been initialized by the module. In other
words suspend/resume is broken on the 2013 Pixel ever since 4.9.0-3
but worked fine previously.

I can't find an existing bug about tpm_tis or any mention of it on the
list. Perhaps this was done unintentionally?


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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.9.0-3-amd64  4.9.30-2+deb9u3

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information

Bug#799144: ITP: ansible-lint -- Best practices checker for Ansible

[Gregory Colpart]

On Thu, Aug 24, 2017 at 12:06:18PM +0200, Sascha Girrulat wrote:
> ok thx. This year i diddn't attend to the debconf because of lack of
> time :(. If you need assistance pls tell me.

ansible-lint is in NEW 14 days ago:
https://ftp-master.debian.org/new/ansible-lint_3.4.13+git.20170811-1-1.html
 
Regards,
-- 
Grégory Colpart   GnuPG:4096R/B8612B5D
Evolix - Hébergement et Infogérance Open Source http://www.evolix.fr/

Bug#799144: ITP: ansible-lint -- Best practices checker for Ansible

[Gregory Colpart]

Hi Sascha,

On Wed, Aug 09, 2017 at 10:15:51PM +0200, Sascha Girrulat wrote:
> sry, i thought that i moved this itp top an rfp. Feel free if you would like 
> to take over this itp. Of you don't want i could try it next week. I have a 
> short holiday and hopefully a time to do that.

Thanks for you quick reply. I will take over and probably upload
the package in NEW before the end of DebConf17 :)

Regards,
-- 
Grégory Colpart   GnuPG:4096R/B8612B5D
Evolix - Hébergement et Infogérance Open Source http://www.evolix.fr/

Bug#799144: ITP: ansible-lint -- Best practices checker for Ansible

[Gregory Colpart]

any news?

I have a package ready, I intent to take over the ITP if no answer.

Regards,
-- 
Grégory Colpart   GnuPG:4096R/B8612B5D
Evolix - Hébergement et Infogérance Open Source http://www.evolix.fr/

Bug#750946: libhtml-html5-parser-perl: UTF-8 character breaks parse_file

[Gregory Williams]

On Aug 7, 2017, at 8:26 AM, gregor herrmann  wrote:
> 
> 
> This looks indeed much better than my crude workarounds, thanks for
> that!
> 
> Do you think you can take this up with upstream?

Yes, I think Kjetil and I can work on getting this merged upstream.

Thanks,
Greg

Bug#750946: libhtml-html5-parser-perl: UTF-8 character breaks parse_file

[Gregory Williams]

On Sat, 5 Aug 2017 12:16:04 -0400 gregor herrmann  wrote:
> What helps is:
> - replace in lib/HTML/HTML5/Parser.pm
>   $response->{decoded_content} with $response->{content}
>   which feels a bit dangerous
> - or in lib/HTML/HTML5/Parser/UA.pm's get:
>   move the
>   if ($uri =~ /^file:/i)
>   up so it's the first alternative and then _get_fs is used
> 
> 
> The latter change would be, as a diff:
> 
> #v+
> --- a/lib/HTML/HTML5/Parser/UA.pm
> +++ b/lib/HTML/HTML5/Parser/UA.pm
> @@ -18,14 +18,14 @@ sub get
>  {
> my ($class, $uri, $ua) = @_;
> 
> +   if ($uri =~ /^file:/i)
> +   { goto \&_get_fs }
> if (ref $ua and $ua->isa('HTTP::Tiny') and $uri =~ /^https?:/i)
> { goto \&_get_tiny }
> if (ref $ua and $ua->isa('LWP::UserAgent'))
> { goto \&_get_lwp }
> if (UNIVERSAL::can('LWP::UserAgent', 'can') and not $NO_LWP)
> { goto \&_get_lwp }
> -   if ($uri =~ /^file:/i)
> -   { goto \&_get_fs }
> 
> 
> 
> While this helps for reading local files, I guess the _get_lwp() case
> might still be buggy.


I also looked into this and found another possible fix:

diff -ru HTML-HTML5-Parser-0.301/lib/HTML/HTML5/Parser.pm 
HTML-HTML5-Parser-0.301-patched/lib/HTML/HTML5/Parser.pm
--- HTML-HTML5-Parser-0.301/lib/HTML/HTML5/Parser.pm2013-07-08 
07:12:25.0 -0700
+++ HTML-HTML5-Parser-0.301-patched/lib/HTML/HTML5/Parser.pm2017-08-06 
12:42:58.0 -0700
@@ -13,6 +13,7 @@
 use HTML::HTML5::Parser::TagSoupParser;
 use Scalar::Util qw(blessed);
 use URI::file;
+use Encode qw(encode_utf8);
 use XML::LibXML;
 
 BEGIN {
@@ -102,6 +103,11 @@
{
 # XXX AGAIN DO THIS TO STOP ENORMOUS MEMORY LEAKS
 my ($errh, $errors) = @{$self}{qw(error_handler errors)};
+
+if (utf8::is_utf8($text)) {
+   $text   = encode_utf8($text);
+}
+
$self->{parser}->parse_byte_string(
 $opts->{'encoding'}, $text, $dom,
 sub {


Part of the underlying issue here is that many variables and methods in these 
modules are named in a confusing way, expecting/requiring encoded bytes, but 
using names which imply a desire for decoded strings.

The above patch should handle the LWP case which the previously suggest patch 
avoids. It still passes the test suite (which should probably be improved to 
verify this case), and also supports the test case detailed in this bug report 
(though I should mention that I believe the test script included by Vincent 
Lefevre includes a double-encoding bug as $doc->toString() actually returns 
utf8 encoded bytes, which the :encoding(UTF-8) PerlIO layer on stdout will 
attempt to encode a second time).

thanks,
.greg

Bug#864551: gcc-6: linker symbol incorrectly decoded in C code

[Gregory Mounie]

Package: gcc-6
Version: 6.3.0-18
Severity: normal
Tags: upstream

Dear Maintainer,

When using the linker symbols, the values of the adresses of the symbols
are incorrectly decoded.

The problem occurs with the linker scripts but also with the following
small code and minimalist compiler options:

The test code:

#include 

extern unsigned char liloo;
extern unsigned char lilootab[];

static void * spa = & liloo;
static void * sta = lilootab;

int main() {
void * pa = & liloo;
void * ta = lilootab;
printf("%p %p %p %p\n", spa, sta, pa, ta);
return 0;
}

The compilation with gcc-6:
gcc-6 -g -c testld.c
gcc-6 -fuse-ld=bfd -Wl,--defsym=liloo=0x100 -Wl,--defsym=lilootab=0x200 
testld.o -o testld-6

The incorrect execution:
./testld-6
0x55bf6cc0c000 0x55bf6dc0c000 0x55bf6cc0c000 0x55bf6dc0c000

The symbol table is still correct according to objdump:

$ objdump -t testld-6 | grep liloo
0200 g   *ABS*    lilootab
0100 g   *ABS*    liloo


The compilation with gcc-5
gcc-5 -g -c testld.c
gcc-5 -fuse-ld=bfd -Wl,--defsym=liloo=0x100 -Wl,--defsym=lilootab=0x200 
testld.o -o testld-5

The correct execution:
./testld-5
0x100 0x200 0x100 0x200

Using linker:
no change using gold instead of bfd

Using other compilers:

The bug occurs with gcc-6 (6.3.0-18) and gcc-7 (7.1.0-6) in experimental

Correct execution occurs with with gold and bfd:
gcc-4.8,4.9,5.0 and clang 3.6,3.7,3.8,3.9,4.0,5.0



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

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

Versions of packages gcc-6 depends on:
ii  binutils  2.28-5
ii  cpp-6 6.3.0-18
ii  gcc-6-base6.3.0-18
ii  libc6 2.24-11
ii  libcc1-0  7.1.0-6
ii  libgcc-6-dev  6.3.0-18
ii  libgcc1   1:7.1.0-6
ii  libgmp10  2:6.1.2+dfsg-1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-1+b2
ii  libmpfr4  3.1.5-1
ii  libstdc++66.3.0-18
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-6 recommends:
ii  libc6-dev  2.24-11

Versions of packages gcc-6 suggests:
ii  gcc-6-doc 6.3.0-1
pn  gcc-6-locales 
pn  gcc-6-multilib
pn  libasan3-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

Bug#863603: bluez: a2dp not working

[gregory . bahde]

Finally solved, 


It is indeed a gdm3 bug, the #805414 seems a good candidate, 

I modified /usr/bin/start-pulseaudio-x11 attached ( needed only if using gdm3) 
and modified /etc/pulse/default.pa (same) 


I also prevented pulseaudio to load under gdm3 according to this: 
https://wiki.debia n.org/BluetoothUser/a2dp 

The odd thing is that without all of this my other headphones where connecting 
a2dp straight. 



However 

Grégory Bahde 

- Mail original -

De: "gregory bahde" <gregory.ba...@laposte.net> 
À: "gregory bahde" <gregory.ba...@laposte.net>, 863...@bugs.debian.org 
Cc: "Debian Bug Tracking System" <sub...@bugs.debian.org> 
Envoyé: Mardi 30 Mai 2017 16:43:49 
Objet: Re: Bug#863603: bluez: a2dp not working 

Hello, 

Here I attached logs regarding an attempt(s) to use A2dp. 
there are also pulseaudio log attached as I am investigating it too. 
I switched harddrives from machines, it worked for a bit then refused to switch 
to a2dp again :/ 


Continuing to investigate, 

Grégory Bahde 

Doctorant en Géographie UJM / ENSSIB 
Financé par la Région RA dans le cadre de l'ARC 5 
Enseignant UE5 Edition Numérique @ ENSSIB 

0619157341 



- Mail original -

De: "gregory bahde" <gregory.ba...@laposte.net> 
À: "Debian Bug Tracking System" <sub...@bugs.debian.org> 
Envoyé: Lundi 29 Mai 2017 09:46:51 
Objet: Bug#863603: bluez: a2dp not working 

Package: bluez 
Version: 5.43-2 
Severity: normal 
Tags: upstream 

Dear Maintainer, 

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

* What led up to the situation? 
I acquired a JBL Go bluetooth speaker. 
It works only in headsetmode on one of my computers (both running stetch, the 
other one is running this speaker wih a2dp fine) 

I tried different dongles (different chips) and they all don't allow me to use 
a2dp, only HSP with this speaker. 

I own another bluetooth device and it connects with a2dp fine. 


journalctl gives me this: 

mai 29 09:42:11 GoonieB gnome-settings-[1856]: Unable to get default sink 
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion 
'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion 
'GVC_IS_MIXER_CARD (card)' failed 



AND THEN 

kernel: Bluetooth: hci0 SCO packet for unknown connection handle 71 
mai 29 09:42:16 GoonieB gnome-control-c[6529]: Device did not have an 
appropriate card 
mai 29 09:42:16 GoonieB gnome-control-c[6529]: gvc_mixer_card_get_index: 
assertion 'GVC_IS_MIXER_CARD (card)' failed 
mai 29 09:42:21 GoonieB pulseaudio[2950]: [pulseaudio] module-bluez5-device.c: 
Refused to switch profile to a2dp_sink: Not connected 



* What exactly did you do (or not do) that was effective (or 
ineffective)? 

Tried all the fix for such bug shown on the internet 

* What was the outcome of this action? 

unsuccessful 



-- System Information: 
Debian Release: 9.0 
APT prefers testing 
APT policy: (502, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable'), (10, 'experimental'), (10, 'unstable') 
Architecture: amd64 
(x86_64) 
Foreign Architectures: i386 

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

Versions of packages bluez depends on: 
ii dbus 1.10.18-1 
ii init-system-helpers 1.48 
ii kmod 23-2 
ii libc6 2.24-10 
ii libdbus-1-3 1.10.18-1 
ii libglib2.0-0 2.50.3-2 
ii libreadline7 7.0-3 
ii libudev1 232-23 
ii lsb-base 9.20161125 
ii udev 232-23 

bluez recommends no packages. 

Versions of packages bluez suggests: 
ii pulseaudio-module-bluetooth 10.0-1 

-- debconf-show failed 




default.pa
Description: Binary data


start-pulseaudio-x11
Description: application/shellscript

Bug#863652: system-config-lvm: crash on stretch, python gtk bug?

[gregory bahde]

Package: system-config-lvm
Version: 1.1.18-3
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

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


Dear sir, just discovered that sysmtem-config-lvm was crashing on my system:
It didn't occur during an operation as it crashes pretty quickly


Ready to help and provide more info.


Here is the output, running as root:


  scaled_pixbuf = self.pixbuf.scale_simple(pixmap_width, height,
gtk.gdk.INTERP_BILINEAR)
Traceback (most recent call last):
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 486, in
on_tree_selection_changed
self.on_best_fit(None)
  File "/usr/share/system-config-lvm/Volume_Tab_View.py", line 555, in
on_best_fit
self.display_view.draw()
  File "/usr/share/system-config-lvm/renderer.py", line 604, in draw
self.display.draw(self.da, self.gc, (10, y_offset))
  File "/usr/share/system-config-lvm/cylinder_items.py", line 513, in draw
self.cyl.draw(pixmap, gc, (x, y))
  File "/usr/share/system-config-lvm/cylinder_items.py", line 305, in draw
CylinderItem.draw(self, dc, gc, (x, y))
  File "/usr/share/system-config-lvm/cylinder_items.py", line 120, in draw
child.draw(dc, gc, (x, y))
  File "/usr/share/system-config-lvm/cylinder_items.py", line 311, in draw
cyl_pix = self.cyl_gen.get_cyl(dc, self.get_width(), self.height)
  File "/usr/share/system-config-lvm/cylinder_items.py", line 1039, in get_cyl
pixmap.draw_pixbuf(gc, scaled_pixbuf, 0, 0, 0, 0, -1, -1)
TypeError: Gdk.Drawable.draw_pixbuf() argument 2 must be gtk.gdk.Pixbuf, not
None
The program 'system-config-lvm.py' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 9424 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)








-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (502, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages system-config-lvm depends on:
ii  gettext0.19.8.1-2
ii  gsfonts1:8.11+urwcyr1.0.7~pre44-4.3
ii  lvm2   2.02.168-2
ii  menu   2.1.47+b1
ii  python-glade2  2.24.0-5.1
ii  python-gnome2  2.28.1+dfsg-1.2
ii  python-gtk22.24.0-5.1
pn  python:any 

system-config-lvm recommends no packages.

system-config-lvm suggests no packages.

-- debconf-show failed

Bug#863603: bluez: a2dp not working

[gregory bahde]

Package: bluez
Version: 5.43-2
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
I acquired a JBL Go bluetooth speaker.
It works only in headsetmode on one of my computers (both running stetch, the
other one is running this speaker wih a2dp fine)

I tried different dongles (different chips) and they all don't allow me to use
a2dp, only HSP  with this speaker.

I own another bluetooth device and it connects with a2dp fine.


journalctl gives me this:

mai 29 09:42:11 GoonieB gnome-settings-[1856]: Unable to get default sink
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index:
assertion 'GVC_IS_MIXER_CARD (card)' failed
mai 29 09:42:11 GoonieB gnome-settings-[1856]: gvc_mixer_card_get_index:
assertion 'GVC_IS_MIXER_CARD (card)' failed
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion
'GVC_IS_MIXER_CARD (card)' failed
mai 29 09:42:11 GoonieB gnome-shell[1727]: gvc_mixer_card_get_index: assertion
'GVC_IS_MIXER_CARD (card)' failed



AND THEN

kernel: Bluetooth: hci0 SCO packet for unknown connection handle 71
mai 29 09:42:16 GoonieB gnome-control-c[6529]: Device did not have an
appropriate card
mai 29 09:42:16 GoonieB gnome-control-c[6529]: gvc_mixer_card_get_index:
assertion 'GVC_IS_MIXER_CARD (card)' failed
mai 29 09:42:21 GoonieB pulseaudio[2950]: [pulseaudio] module-bluez5-device.c:
Refused to switch profile to a2dp_sink: Not connected



   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Tried all the fix for such bug shown on the internet

   * What was the outcome of this action?

unsuccessful



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (502, 'testing'), (500, 'testing-proposed-updates'), (500, 
'stable'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

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

Versions of packages bluez depends on:
ii  dbus 1.10.18-1
ii  init-system-helpers  1.48
ii  kmod 23-2
ii  libc62.24-10
ii  libdbus-1-3  1.10.18-1
ii  libglib2.0-0 2.50.3-2
ii  libreadline7 7.0-3
ii  libudev1 232-23
ii  lsb-base 9.20161125
ii  udev 232-23

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  10.0-1

-- debconf-show failed

Bug#857450: libxcb1: many segfaults -gnome and such- related to libxcb

[gregory bahde]

Package: libxcb1
Version: libxcb.so.1.1.0
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
I don't know, it pops up randomly:
It goes like
[  826.014264] gnome-shell[3060]: segfault at ffb9 ip
7ffb33523ba3 sp 7ffc4416c5b0 error 7 in
libxcb.so.1.1.0[7ffb33516000+27000]
[  826.028665] solaar[3215]: segfault at ffb9 ip 7f54adaa1ba3
sp 7ffde885caa0 error 7 in libxcb.so.1.1.0[7f54ada94000+27000]
[  826.028994] arandr[3841]: segfault at ffb9 ip 7f4cc6861ba3
sp 7fff0663e630 error 7 in libxcb.so.1.1.0[7f4cc6854000+27000]
[  826.029578] smart-notifier[3205]: segfault at ffb9 ip
7fad6795aba3 sp 7ffe787b5c70 error 7 in
libxcb.so.1.1.0[7fad6794d000+27000]
[  826.030002] gnome-settings-[3185]: segfault at ffb9 ip
7f54e4bd9ba3 sp 7ffc46860410 error 7 in
libxcb.so.1.1.0[7f54e4bcc000+27000]
[  826.030908] nautilus-deskto[3216]: segfault at ffb9 ip
7f6e67830ba3 sp 7ffc1d48f5a0 error 7 in
libxcb.so.1.1.0[7f6e67823000+27000]
[  826.031081] python2[3212]: segfault at ffb9 ip 7f1a0cd3bba3
sp 7ffd982f3610 error 7 in libxcb.so.1.1.0[7f1a0cd2e000+27000]
[  826.031161] evolution-alarm[3202]: segfault at ffb9 ip
7eff93510ba3 sp 7fff22040a10 error 7 in
libxcb.so.1.1.0[7eff93503000+27000]
[  826.031209] qjackctl[3208]: segfault at ffb9 ip 7f951851fba3
sp 7fff453c51b0 error 7 in libxcb.so.1.1.0[7f9518512000+27000]
[  826.033558] gnome-software[3203]: segfault at ffb9 ip
7f5889e67ba3 sp 7fff023832c0 error 7 in
libxcb.so.1.1.0[7f5889e5a000+27000]
[  849.862335] show_signal_msg: 4 callbacks suppressed
[  849.862339] gnome-settings-[1748]: segfault at ffb9 ip
7f886ed92ba3 sp 7ffca61cd370 error 7 in
libxcb.so.1.1.0[7f886ed85000+27000]
[  849.876014] gnome-settings-[4164]: segfault at ffba ip
7fae3fedeba3 sp 7ffec51bc490 error 7 in
libxcb.so.1.1.0[7fae3fed1000+27000]
[  849.889686] gnome-shell[1554]: segfault at ffb9 ip
7f3369638ba3 sp 7ffc6c161510 error 7 in
libxcb.so.1.1.0[7f336962b000+27000]
[  916.162758] at-spi-bus-laun[3038]: segfault at ffba ip
7efc2f16fba3 sp 7ffe16cbd370 error 7 in
libxcb.so.1.1.0[7efc2f162000+27000]



Then if I try to restart gdm:

[ 1049.291499] gnome-shell[4356]: segfault at ffba ip
7fdf7b9a6ba3 sp 7ffc20e8b9f0 error 7 in
libxcb.so.1.1.0[7fdf7b999000+27000]
[ 1050.216066] gnome-session-c[4400]: segfault at ffba ip
7f649bacbba3 sp 7fff17039230 error 7 in
libxcb.so.1.1.0[7f649babe000+27000]
[ 1050.221303] gnome-session-c[4401]: segfault at ffba ip
7f268a0f3ba3 sp 7f071480 error 7 in
libxcb.so.1.1.0[7f268a0e6000+27000]
[ 1050.226985] gnome-session-f[4402]: segfault at ffba ip
7f1926b09ba3 sp 7ffcf9dc11d0 error 7 in
libxcb.so.1.1.0[7f1926afc000+27000]
[ 1051.588970] gnome-session-c[4434]: segfault at ffba ip
7fa80d070ba3 sp 7fff57a63870 error 7 in
libxcb.so.1.1.0[7fa80d063000+27000]
[ 1051.594360] gnome-session-c[4435]: segfault at ffba ip
7f8c1ffdfba3 sp 7ffdd56d9490 error 7 in
libxcb.so.1.1.0[7f8c1ffd2000+27000]
[ 1051.600283] gnome-session-f[4436]: segfault at ffba ip
7fecd15b9ba3 sp 7ffc9d0fd320 error 7 in
libxcb.so.1.1.0[7fecd15ac000+27000]
[ 1052.961614] gnome-session-c[4468]: segfault at ffba ip
7eff08e30ba3 sp 7ffca5e61100 error 7 in
libxcb.so.1.1.0[7eff08e23000+27000]
[ 1052.967012] gnome-session-c[4469]: segfault at ffba ip
7f71a0ffdba3 sp 7ffd3c620be0 error 7 in
libxcb.so.1.1.0[7f71a0ff+27000]
[ 1052.972834] gnome-session-f[4470]: segfault at ffba ip
7fd7e0c23ba3 sp 7ffc62acbb60 error 7 in
libxcb.so.1.1.0[7fd7e0c16000+27000]
[ 1054.318303] gnome-session-c[4501]: segfault at ffba ip
7fbfb518eba3 sp 7ffcccf92120 error 7 in
libxcb.so.1.1.0[7fbfb5181000+27000]
[ 1054.323252] gnome-session-c[4502]: segfault at ffba ip
7fa77c9cfba3 sp 7ffe566c6c90 error 7 in
libxcb.so.1.1.0[7fa77c9c2000+27000]
[ 1054.329006] gnome-session-f[4503]: segfault at ffba ip
7f6a9cd0cba3 sp 7ffdff3aa910 error 7 in
libxcb.so.1.1.0[7f6a9ccff000+27000]
[ 1055.708343] gnome-session-c[4534]: segfault at ffba ip
7ff874bc6ba3 sp 7ffe5d0e7800 error 7 in
libxcb.so.1.1.0[7ff874bb9000+27000]
[ 1055.713639] gnome-session-c[4535]: segfault at ffba ip
7eff39f78ba3 sp 7ffe98d508f0 error 7 in
libxcb.so.1.1.0[7eff39f6b000+27000]
[ 1055.719478] gnome-session-f[4536]: segfault at ffba ip
7f52214cbba3 sp 7fff2bc0ce50 error 7 in
libxcb.so.1.1.0[7f52214be000+27000]


   * What exactly did you do (or not 

Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

[Gregory CLEMENT]

Hi Ben,
 
 On lun., févr. 20 2017, Ben Hutchings <b...@decadent.org.uk> wrote:

> On Mon, 2017-02-20 at 17:50 +0100, Thomas Petazzoni wrote:
>> Hello,
>> 
>> On Mon, 20 Feb 2017 16:40:25 +, Ben Hutchings wrote:
>> 
>> > That is precisely what I intended.  20-23 are used by the second
>> > Ethernet port.  The old board code doesn't assign 4 or 5 at all.
>> 
>> Then I believe it would be more explicit to have separate pin muxing
>> configurations for SATA on this board.
>
> You mean, define additional pinmux nodes and override the pinctrl-0
> property of ?  More like this:
>
> --- a/arch/arm/boot/dts/kirkwood-ts419.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-ts419.dtsi
> @@ -73,3 +73,19 @@
>   phy-handle = <>;
>   };
>  };
> +
> + {
> + pmx_sata0_ts419: pmx-sata0-ts419 {
> + marvell,pins = "mpp15";
> + marvell,function = "sata0";
> + };
> +
> + pmx_sata1_ts419: pmx-sata1-ts419 {
> + marvell,pins = "mpp16";
> + marvell,function = "sata1";
> + };
> +};
> +
> + {
> + pinctrl-0 = <_sata0_ts419 _sata1_ts419>;
> +};
> --- END ---

If you send a new version of your patch, then I will be able to apply
it on mvebu/dt.

Thanks,

Gregory

>
> Ben.
>
> -- 
> Ben Hutchings
> If at first you don't succeed, you're doing about average.
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

-- 
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Bug#749272: varnish doesn't source /etc/default/varnish when started with systemd

[Gregory Colpart]

tags 749272 - wontfix
severity 749272 serious
retitle 749272 varnish doesn't source /etc/default/varnish when started but 
uses it when reloaded

Hello,

Keeping file /etc/default/varnish when Varnish doesn't source it
is confusing for users. And the worst is that the script
/usr/share/varnish/reload-vcl (used by ExecReload in systemd
unit) sources /etc/default/varnish !
Then users need to configure Varnish options in /etc/default/varnish
*and* in varnish.service... and keep synchronized. The result is
often a production failure when "systemctl reload varnish" then
I consider this bug as serious severity (and it should be fixed for
Stretch).

There could be two bug fixes :
- Using patch in this bug report to source /etc/default/varnish
  in varnish.service (and removing useless variables like START=yes)
- Rewriting the script reload-vcl to not use /etc/default/varnish
  (and removing the file /etc/default/varnish)

Regards,
-- 
Grégory Colpart   GnuPG:4096R/B8612B5D
Evolix - Hébergement et Infogérance Open Source http://www.evolix.fr/

Bug#854866: solaar: Solaar did not have permissions to open my receiver

[gregory bahde]

Package: solaar
Version: 0.9.2+dfsg-7
Severity: grave
Tags: ipv6
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
installing it
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
none yet though it i a matter a group permissions, i'll investigate soon

   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (101, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages solaar depends on:
ii  adduser3.115
ii  debconf [debconf-2.0]  1.5.60
ii  gir1.2-gtk-3.0 3.22.7-2
ii  passwd 1:4.4-3
ii  python-gi  3.22.0-2
ii  python-pyudev  0.21.0-1
pn  python:any 
ii  udev   232-15

Versions of packages solaar recommends:
ii  gir1.2-notify-0.7  0.7.7-1
ii  python-dbus1.2.4-1
ii  systemd232-15
ii  upower 0.99.4-4

Versions of packages solaar suggests:
ii  gir1.2-appindicator3-0.1  0.4.92-4
ii  solaar-gnome3 0.9.2+dfsg-7

-- debconf information:
  solaar/use_plugdev_group: false

Bug#854597: font-viewer: missing capital feature: font location!!

[gregory bahde]

Package: gnome-font-viewer
Version: 3.22.0-1
Severity: important
File: font-viewer
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
 I had a font package installed locally (under home/fonts) superseeding the
system installed times new roman font packages. the local one was uncomplete
for some reason, leading to weird substitution. the problem is, there are no
soft for finding out where your fonts are located for real.
like fc-list would only report one location for the font whereas there were 2
indeed, which the font viewer showed but without telling you were the font is
located...
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to installe fontmatrix for that, not  installable for stretch, so
compiled it to figure out where those fonts were

   * What was the outcome of this action?
succesfull but it was like using a gatling gun to blow a candle
   * What outcome did you expect instead?
gnome-font viewer to indicate me the font  directory it was from
*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (101, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages gnome-font-viewer depends on:
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-9
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1
ii  libgdk-pixbuf2.0-0 2.36.4-1
ii  libglib2.0-0   2.50.2-2
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.7-2
ii  libharfbuzz0b  1.4.2-1
ii  libpango-1.0-0 1.40.3-3
ii  libpangocairo-1.0-01.40.3-3

gnome-font-viewer recommends no packages.

gnome-font-viewer suggests no packages.

-- no debconf information

Bug#854598: fontconfig: fc-list does show only one item if the font is installed in multiple locations -duplicate but not same version for instance which caused troubles with caracters on my system-

[gregory bahde]

Package: fontconfig
Version: 2.11.0-6.7
Severity: normal
Tags: upstream

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

   * What was the outcome of this action?
   * What outcome did you expect instead?

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



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (101, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages fontconfig depends on:
ii  dpkg   1.18.18
ii  fontconfig-config  2.11.0-6.7
ii  libc6  2.24-9
ii  libfontconfig1 2.11.0-6.7
ii  libfreetype6   2.6.3-3+b1

fontconfig recommends no packages.

fontconfig suggests no packages.

-- no debconf information

Bug#854596: fontmatrix: uninstallable -at least under stretch, fontmatrix : Dépend: libicu52 (>= 52~m1-1~) which is a virtual package and is not provided by any available package

[gregory . bahde]

Package: fontmatrix 
Version: 0.6.0+svn20110930-1.1+b1 
Severity: grave 
Tags: upstream 
Justification: renders package unusable 

Dear Maintainer, 

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

* What led up to the situation? 
trying to install the soft 
* What exactly did you do (or not do) that was effective (or 
ineffective)? 
installed it from source -github, following the regular procedure- 
* What was the outcome of this action? 
successful but not using the package 
* What outcome did you expect instead? 
install from a package rightaway i suppose ;) 

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



-- System Information: 
Debian Release: 9.0 
APT prefers testing 
APT policy: (101, 'testing'), (10, 'experimental'), (10, 'unstable') 
Architecture: amd64 (x86_64) 
Foreign Architectures: i386 

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

Bug#854596: fontmatrix: uninstallable -at least under stretch, fontmatrix : Dépend: libicu52 (>= 52~m1-1~) which is a virtual package and is not provided by any available package

[gregory bahde]

Package: fontmatrix
Version: 0.6.0+svn20110930-1.1+b1
Severity: grave
Tags: upstream
Justification: renders package unusable

Dear Maintainer,

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

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

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



-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (101, 'testing'), (10, 'experimental'), (10, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#755545: Add glusterfs/libgfapi

[Gregory Auzanneau]

Dear Maintainer,

As finally, glusterfs was integrated to qemu (into qemu-block-extra) on 
12/28/2016 which close blocking bugs #775431 and #787112, is the 
integration of glusterfs to libvirt is possible now ?



Best regards,
Gregory Auzanneau

Bug#843118: seabios: Unable to boot KVM guest with "-display none"

[Gregory Auzanneau]

Package: seabios
Version: 1.9.3-2
Severity: normal

Dear Maintainer,

Since the latest update of seabios 1.9.3-2, a guest machine can't start with 
qemu parameter "-display none".
The guest hang immediatly at boot with all vCPU at 100%.

If I revert back to seabios 1.8.2-1, the problem is solved.
If I add a virtual graphic card, the is problem is also solved.

Best regards,
Gregory

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

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

-- no debconf information

Bug#673050: dh-linktree: allow symlinking within a source package

[Gregory Lutostanski]

Agreed completely. I expected this to work much like dh_link but
recursively for trees in the source, rather than other files outside.
So I'm just doing ln -s thing/* otherthing for now as an override, but not
as pretty.

But useful for the other case too, just not what I expected from the
manpage.

Thanks,
Greg Lutostanski

Bug#834788: singularity-container: FTBFS: most platforms unsupported

[Gregory M. Kurtzer]

On Fri, Aug 19, 2016 at 7:18 AM, Yaroslav Halchenko <deb...@onerussian.com>
wrote:

>
> On Fri, 19 Aug 2016, Gregory M. Kurtzer wrote:
> >  I thought that the idea generally is to not restrict by default and
> >  possibly to let interested in porting to look at it. Policy 5.6.8
> >  states "Specifying a list of architectures or architecture wildcards
> >  other than any is for the minority of cases where a program is not
> >  portable or is not useful on some architectures".
>
> >  Theoretically I think singularity could be ported for other
> >  architectures (CCing upstream for clarification), not that me or
> >  upstream is going to embark on such a voyage ATM ;)
>
> >  If there is somewhere policy/recommendation that I should better
> drop
> >  from any to a restricted list of architectures, please let me know,
> and
> >  I will do so for the next release.
>
> >That is a good point regarding non-Linux builds. At present I am not
> >checking for the clone() or unshare() system calls, as they have been
> on
> >Linux for quite some time so I didn't think of them not being
> available,
> >but they are Linux specific system calls (as are the CLONE_* flags
> which I
> >am checking for). So it sounds like I need to add some checks for
> clone()
> >and unshare() and bomb out early with a reasonable error message
> about an
> >unsupported platform before checking for the flags.
> >As far as architecture support, Singularity *should* build on non-x86
> >architectures just fine, but my ability to port and test are limited
> to
> >x86. I am aware that IBM has successfully ported and used Singularity
> on
> >Power, but I've never gotten any patches so I assumed it just worked.
> Are
> >the failed build logs for non-x86 available?
>
> This is the page you could always go to
> https://buildd.debian.org/status/package.php?p=
> singularity-container=unstable
> to get the logs (click on Build-Attempted)
>

It doesn't actually show the configure output, or did it die at the first
line?


configure: exit 1
dh_auto_configure: ./configure --build=aarch64-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=${prefix}/lib/aarch64-linux-gnu
--libexecdir=${prefix}/lib/aarch64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking returned exit code 1
debian/rules:9: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2



>
> I can provide you access to mipsel, and possible sparc (when I bring it
> back online, that poor elderly beast with failing fan), and soon
> powerpc.
>
>
 You are awesome, thank you!

Greg

-- 
Gregory M. Kurtzer
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

Bug#834788: singularity-container: FTBFS: most platforms unsupported

[Gregory M. Kurtzer]

On Thu, Aug 18, 2016 at 10:02 PM, Yaroslav Halchenko <deb...@onerussian.com>
wrote:

>
> On Thu, 18 Aug 2016, Aaron M. Ucko wrote:
>
> > Source: singularity-container
> > Version: 2.1.2-1
> > Severity: important
> > Justification: fails to build from source
>
> > Builds of singularity-container for architectures other than x86 Linux
> > have been failing at the configuration stage.  The non-Linux builds
> > complain that various CLONE_* flags, most crucially CLONE_NEWNS, are
> > unavailable; I presume these platforms are a lost cause.  As for Linux
> > on non-x86, the build system complains that the architecture "is not
> > supported"; I haven't checked whether that's simply a case of
> > excessive conservatism.
>
> > Could you please take a look and restrict the package's official
> > Architecture accordingly?
>
> I thought that the idea generally is to not restrict by default and
> possibly to let interested in porting to look at it. Policy 5.6.8
> states "Specifying a list of architectures or architecture wildcards
> other than any is for the minority of cases where a program is not
> portable or is not useful on some architectures".
>
> Theoretically I think singularity could be ported for other
> architectures (CCing upstream for clarification), not that me or
> upstream is going to embark on such a voyage ATM ;)
>
> If there is somewhere policy/recommendation that I should better drop
> from any to a restricted list of architectures, please let me know, and
> I will do so for the next release.
>

That is a good point regarding non-Linux builds. At present I am not
checking for the clone() or unshare() system calls, as they have been on
Linux for quite some time so I didn't think of them not being available,
but they are Linux specific system calls (as are the CLONE_* flags which I
am checking for). So it sounds like I need to add some checks for clone()
and unshare() and bomb out early with a reasonable error message about an
unsupported platform before checking for the flags.

As far as architecture support, Singularity *should* build on non-x86
architectures just fine, but my ability to port and test are limited to
x86. I am aware that IBM has successfully ported and used Singularity on
Power, but I've never gotten any patches so I assumed it just worked. Are
the failed build logs for non-x86 available?

 Thank you!


-- 
Gregory M. Kurtzer
High Performance Computing Services (HPCS)
University of California
Lawrence Berkeley National Laboratory
One Cyclotron Road, Berkeley, CA 94720

Bug#820595: gtkboard: Crashes in menu and during gameplay

[Gregory Lozet]

Package: gtkboard
Version: 0.11pre0+cvs.2003.11.02-7
Followup-For: Bug #820595

Dear Maintainer,

I experimented the first problem when selecting new games.

I found that a wring index is used to set a pointer to NULL:

--- a/src/menu.c
+++ b/src/menu.c
@@ -810,8 +810,13 @@ void menu_insert_recent_game (gchar *gam
if (tmpname)
{
GtkWidget *wid;
-   gtk_widget_destroy (menu_recent_widgets[i == NUM_RECENT_GAMES ? 
i -
1 : i]);
-   menu_recent_widgets[i] = NULL;
+   if (i == NUM_RECENT_GAMES) {
+   j = i - 1;
+   } else {
+   j = i;
+   }
+   gtk_widget_destroy (menu_recent_widgets[j]);
+   menu_recent_widgets[j] = NULL;
gtk_item_factory_delete_item (menu_factory, tmp = 
g_strdup_printf
("/Game/%s", tmpname));
g_free (tmp);
}

Best Regards,
Greg


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

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

Versions of packages gtkboard depends on:
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u4
ii  libcairo21.14.0-2.1+deb8u1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.5.2-3+deb8u1
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk2.0-0  2.24.25-3+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libpangoft2-1.0-01.36.8-3
ii  libsdl-mixer1.2  1.2.12-11+b1
ii  libsdl1.2debian  1.2.15-10+b1

gtkboard recommends no packages.

gtkboard suggests no packages.

-- no debconf information

Bug#760474: Subject: smokeping configuration for apache2 no longer working

[Gregory Guthrie]

Any progress on this, or even a manual fix to remedy?

---

Bug#819550: linux-image-4.4.0-0.bpo.1-rt-amd64: boot stall while trying 4.4 rt amd64 kernel

[gregory bahde]

Package: linux-image-4.4.0-0.bpo.1-rt-amd64
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

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

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

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



-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), 
(10, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#816201: live-config: using tzdata component fails and always set to 'Etc/UTC'

[Gregory DAVID]

Source: live-config
Version: 5.20151121
Severity: normal
Tags: patch

Dear Maintainer,

   * What led up to the situation?
While configuring the live-config.timezone parameter (on kernel boot parameter
or by config.conf file) to any value, hence 'Europe/Paris', the only result is
the 'Etc/UTC' timezone set.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Looked up the '0070-tzdata' component source file and find that the process to
change timezone is:
 1/ echoing the timezone to the '/etc/timezone' file (ex: echo
"Europe/Paris">/etc/timezone )
 2/ call to the reconfiguration of tzdata package ( "dpkg-reconfigure -f
noninteractive -p critical tzdata" )

If I try to do the same thing by hand, I can se that:
 1/ echoing works fine (hopefully :) )
 2/ call to the tzdata package reconfiguration do not return any error, BUT the
'/etc/timezone' file content has been modified by the reconfiguration process.

I thought then the package tzdata was misconfigured or with errors. Looking up
the https://anonscm.debian.org/cgit/pkg-
glibc/tzdata.git/tree/debian/tzdata.config#n329 we can identify that the tzdata
configuration process override the '/etc/timezone' file if '/etc/localtime'
exists and is a symlink.
I really think I get something!

We may unlink '/etc/localtime' in
https://anonscm.debian.org/cgit/debian-live/live-
config.git/tree/components/0070-tzdata#n50
before calling 'dpkg-reconfigure ... tzdata'



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

Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
>From b10d7cf76929325741e51479099cc7d2a233f9c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gr=C3=A9gory=20DAVID?= 
Date: Sun, 28 Feb 2016 15:32:16 +0100
Subject: [PATCH] Unlink /etc/localtime if exists before calling
 reconfiguration

---
 components/0070-tzdata | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/components/0070-tzdata b/components/0070-tzdata
index 2677c37..f0a338b 100755
--- a/components/0070-tzdata
+++ b/components/0070-tzdata
@@ -47,6 +47,9 @@ Config ()
 	fi
 
 	echo "${_AREA}/${_ZONE}" > /etc/timezone
+	if [ -L /etc/localtime ] ; then
+		unlink /etc/localtime
+	fi
 	dpkg-reconfigure -f noninteractive -p critical tzdata
 
 	# Creating state file
-- 
2.7.0

Bug#648621: [libglib2.0-dev] need dh_python2 call update

[gregory hainaut]

Package: libglib2.0-dev
Version:  2.42.1-1

Dear Maintainer,

I try the Riku's patch above (glib-ma-fixed.patch). Disclaimer, I rebase
 the patch myself so maybe I break it. Anyway, I manage to broke dpkg install.
 Here some information that I hope would be useful and avoid the same failure 
as me.

Dpkg error:
-
(Reading database ... 237158 files and directories currently installed.)
Removing libglib2.0-dev:i386 (2.42.1-2) ...
dpkg-query: error: --listfiles needs a valid package name but 'libglib2.0-dev' 
is not: ambiguous package name 'libglib2.0-dev' with more than one installed 
instance

Use --help for help about querying packages.
Traceback (most recent call last):
  File "/usr/bin/pyclean", line 117, in 
main()
  File "/usr/bin/pyclean", line 101, in main
pfiles = set(dpf.filter_out_ext(pfiles, ('.so',)))
  File "/usr/share/python/debpython/files.py", line 77, in filter_out_ext
for fn in files:
  File "/usr/share/python/debpython/namespace.py", line 77, in 
add_namespace_files
for fn in files:
  File "/usr/share/python/debpython/files.py", line 53, in from_package
raise Exception("cannot get content of %s" % package_name)
Exception: cannot get content of libglib2.0-dev
dpkg: error processing package libglib2.0-dev:i386 (--purge):
---


I try to debug it. I think it is related to the content of prerm script. As you 
can
see it uses a dpkg call without the architecture information (:amd64)
---
cat /var/lib/dpkg/info/libglib2.0-dev:amd64.prerm
#!/bin/sh
set -e

# Automatically added by dh_python2:
if which pyclean >/dev/null 2>&1; then
pyclean -p libglib2.0-dev 
else
dpkg -L libglib2.0-dev | grep \.py$ | while read file
do
rm -f "${file}"[co] >/dev/null
done
fi

# End automatically added section
---

Based on the comment I think it is related to those 2 lines in the rule file.
binary-install/libglib2.0-dev::
dh_python2 -plibglib2.0-dev /usr/share/glib-2.0/codegen

I'm gussing it must be somewhat contain :arch (maybe $(DEV_PKG)).

As a side note, it would be very nice to have a multiarch glib-dev package for 
the next release.

Best regards,
Gregory

Bug#784373: [Ceph-maintainers] Bug#784373: jessie-pu: package ceph/0.80.9-2 (pre approval)

[Gregory Farnum]

On Tue, Jan 5, 2016 at 1:32 PM, Gaudenz Steinlin  wrote:
>
> [ CCing the upstream package maintainers list ]
>
> Hi
>
> Julien Cristau  writes:
>
>> On Fri, Sep 18, 2015 at 22:57:27 +0200, Gaudenz Steinlin wrote:
>>
>>>
>>> Hi debian-release
>>>
>>> Gaudenz Steinlin  writes:
>>>
>>> > Gaudenz Steinlin  writes:
>>> >> I'd like to update ceph in jessie to the latest upstream bugfix release.
>>> >> The version of ceph in jessie is a long term support (LTS) release which
>>> >> will receive updates at least until January 2016. Updates will be bugfix
>>> >> only. New features go into new release which are developed in parallel.
>>> >> See at the end of this report for the upstream changelog.
>>> >>
>>> >> See http://ceph.com/docs/master/releases/ for the ceph release timeline
>>> >> and support statement.
>>> >>
>>> >
>>> > Just as an additional data point, Ubuntu has a "Minor Release Exception"
>>> > for stable updates for their ceph package [1].
>>>
>>> In the meantime another stable point release of ceph 0.80 (0.80.10) was
>>> released and on top of that there is a (minor) security issue which
>>> won't be fixed through a security update but which would be nice to fix
>>> by a stable update (see bug #798567 / CVE-2015-5245)).
>>>
>>> As another stable update has passed, it would be nice if someone of the
>>> stable release team could comment on this and eventually decide if they
>>> are OK with the proposal to follow the ceph stable branch or if they
>>> don't like it and would prefer an update just fixing the security bug.
>>> It would be nice to have a decision soon, so that there is enough time
>>> to prepare and test the update for the next stable point release.
>>>
>> What does the QA process on upstream's bugfix releases, and on the
>> Debian side for the proposed stable updates, look like?
>
> The QA processes on the upstream side are quite extensive. They run
> integration and upgrade tests on a regular basis. They use their test
> framework theutology[1] for these tests. Their QA configuration is
> available in the ceph-qa-suite repository [2].
>
> Unfortunately it's not easy to see how this testing is actually done and
> if the tests all pass at release time. Maybe someone from upstream Ceph
> can shed some more light on this and explain things in more detail. Some
> test results can be seen on Pulpito [3] but it's not clear to me how
> these results relate to actual releases.

We have some "gitbuilders" running on debian which you can see at
http://ceph.com/gitbuilder.cgi. Those build the source debs and run
"make check", which includes unit tests and some very simple running
cluster tests.

The stable releases and QA teams do affirmative checks to make sure
that all their releases are passing every test prior to tagging. Those
records are available in Redmine tracker tickets; I've added Loïc who
leads that effort and can speak more about it.
-Greg

>
> The QA on the Debian side is not as extensive. My resources are limited,
> but I do run my builds on my own test infrastructure. But I expect the
> changes to the Debian packaging side to be fairly minimal.
>
>>
>> So far I'm leaning towards rejecting this request, as I don't want to
>> spend that much time reviewing these changes, and as you see we're
>> already way behind on stable update requests.
>
> I don't think it's reasonable to expect the release team to review the
> upstream changes. If you don't trust them enough to not break things,
> then we should not upgrade the package. On the other hand other major
> Linux distribution do trust them enough as I wrote in my initial
> request.
>
> If you agree to do these stable updates they have to be done in a
> similar way to the postgres and linux kernel updates. I don't think the
> release team or any Debian developer reviews all upstream changes there.
> So it's really a matter of trust.
>
> Upstream also provides their own Debian packages which are always
> updated to the latest bugfix point releases. I guess many users use
> these packages instead of the packages from Debian because they are
> up to date wrt bugfix releases. IMO this is sad as I think Debian should
> aim at providing the most useful experience out of the box without 3rd
> party repositories.
>
> Gaudenz
>
> [1] https://github.com/ceph/teuthology
> [2] https://github.com/ceph/ceph-qa-suite/tree/firefly
> [3] http://pulpito.ceph.com/?branch=firefly
>
> ___
> Ceph-maintainers mailing list
> ceph-maintain...@lists.ceph.com
> http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com
>

Bug#802770: [libwxgtk3.0-0] dependency on SDL half enabled (rule vs control)

[gregory hainaut]

Package: libwxgtk3.0-0
Version: 3.0.2-1+b1
Severity: minor

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

As far as I understand, WX supports an audio plugin based on SDL 
(see src/unix/sound_sdl.cpp).

My application (PCSX2) depends on both SDL and WX which means the SDL
version (2 vs 1.2) depends on the compilation/link of WX. So it is very 
annoying for me.

It is typically enabled on Archlinux but not in Debian. I searched in the 
Debian's 
rule file the option to disable it so Archlinux can do the same. 
However I found that SDL is kind of enabled but libsdl isn't pulled by
the control file. So the configure script just disable it.

Is it done on purpose? Do you want to disable or enable it? Personally I'm in 
favor to
disable it because it was never enabled on Debian and it is painful to upgrade 
to SDL2.

Here an extract of the build log:

checking for --with-sdl... yes
--
checking for sdl-config... no
checking for SDL - version >= 1.2.0... no
*** The sdl-config script installed by SDL could not be found
*** If SDL was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the SDL_CONFIG environment variable to the
*** full path to sdl-config.
--
  sdlno

touch configure-gtk-shared-stamp


Best regards,
Gregory

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.18.12-1-gregory

Debian Release: 8.2
  500 stable-updates  http.debian.net 
  500 stable  security.debian.org 
  500 stable  ftp.fr.debian.org 
  100 jessie-backports ftp.debian.org 
1 experimentalftp.fr.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#795444: python-enum: Conflicting module with package 'enum' provided by 'python-enum34'

[Gregory DAVID]

Package: python-enum
Version: 0.4.4-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When trying to execute the 'ladi-control-center', part of the 'ladi-tools'
package, Python issue the following error: TypeError: issubclass() arg 1 must
be a class.
After some code analysis, I fund that the import of the 'enum' module do not
reflect what is expected.
In my system, both 'python-enum' and 'python-enum34' are installed, but when
importing the 'enum' module, 'python-enum34' has the precedence.
I do not know exactly how to force the load of a particular module when having
the same name.
'enum' module from 'python-enum' live in '/usr/share/pyshared/enum.py' and is
linked in '/usr/lib/python2.7/dist-packages/enum.py' and I can't load it.
'enum' module from 'python-enum34' live in '/usr/lib/python2.7/dist-
packages/enum/enum.py' and is the one loaded while importing 'import enum' or
'from enum import Enum'.

Thanks.



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

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

Versions of packages python-enum depends on:
ii  python 2.7.9-1
ii  python2.7  2.7.10-3

python-enum recommends no packages.

python-enum suggests no packages.

-- no debconf information

Bug#795270: coreutils: df does not display all nfs mounts for the same mount points

[Gregory Storme]

Package: coreutils
Version: 8.23-4
Severity: normal

Dear Maintainer,

I have these two NFS mounts in fstab:

storage001:/vol/webdata /var/www/sites  nfsdefaults00
storage001:/vol/webdata /var/www/sites-secondarynfsdefaults00

Running df, df -h, df -t only displays the first mount.
Both mounts are displayed using mount, df -a, df -a -t nfs.
Why is it not displayed using df -h in this version?
In coreutils package 8.5-1 on squeeze, both mounts are displayed using df -h.


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

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

Versions of packages coreutils depends on:
ii  libacl1  2.2.52-2
ii  libattr1 1:2.4.47-2
ii  libc62.19-18
ii  libselinux1  2.3-2

coreutils recommends no packages.

coreutils suggests no packages.

-- no debconf information

Bug#792168: pdftk breaks PDF forms

[Gregory Heytings]

Package: pdftk
Version: 2.01-1
Severity: important

Hi,

pdftk (both 1.41 and 2.01) breaks PDF forms.

More precisely, the /NeedAppearances true entry in the AcroForm 
dictionary is silently removed by pdftk, even in a simple pdftk in.pdf 
cat output out.pdf operation.  Attached to this report are three PDF 
files: good.pdf with a simple form, pdftk-wrong.pdf obtained with 
pdftk cat output, and pdftk-correct.pdf which is the (corrected by 
hand) file I would have expected to get.


Note that the forms are only visible in Acrobat Reader.

Many thanks,

Gregory

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.ISO-8859-1, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages pdftk depends on:
ii  libc6   2.17-97
ii  libgcc1 1:4.8.2-16
ii  libgcj144.8.2-16
ii  libstdc++6  4.8.2-16

pdftk recommends no packages.

Versions of packages pdftk suggests:
ii  poppler-utils [xpdf-utils]  0.22.5-4

-- no debconf information

good.pdf
Description: Adobe PDF document


pdftk-correct.pdf
Description: Adobe PDF document


pdftk-wrong.pdf
Description: Adobe PDF document

Bug#786685: proftpd-basic: SSL / TLS handshakes for data connections sometimes stall for 3-30 seconds

[Gregory Fardel]

Package: proftpd-basic
Version: 1.3.5-1.1+deb8u1
Severity: important

Dear Maintainer,

Can you add this upstream patch to the proftpd-basic Debian package ?
I have this issue when I use ProFTPD with TLS on.

Look at this url below :

http://bugs.proftpd.org/show_bug.cgi?id=4108


Thanks !

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

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

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

proftpd-basic recommends no packages.

Versions of packages proftpd-basic suggests:
pn  openbsd-inetd | inet-superserver  none
ii  openssl   1.0.1k-3
pn  proftpd-doc   none
pn  proftpd-mod-geoip none
pn  proftpd-mod-ldap  none
pn  proftpd-mod-mysql none
pn  proftpd-mod-odbc  none
pn  proftpd-mod-pgsql none
pn  proftpd-mod-sqlitenone

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


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#784882: [Ceph-maintainers] Bug#784882: librados2: should not request an executable stack

[Gregory Farnum]

This is resolved upstream. See the ticket at
http://tracker.ceph.com/issues/10114; the original fix for upstream
master is commit 06a245a9845c0c126fb3106b41b2fd2bc4bc4df3, and it is
in the firefly (v0.80.* releases) as commit
01faf1356f648ded9acda02e7cc67c1adb9e9ee3 from November 14 2014 (this
is in v0.80.9 at least, not sure what the timing is on the previous
releases).
-Greg

On Sat, May 9, 2015 at 8:03 PM, Russell Coker russ...@coker.com.au wrote:
 Package: librados2
 Version: 0.80.7-2
 Severity: normal

 # execstack /usr/lib/x86_64-linux-gnu/librados.so.2
 X /usr/lib/x86_64-linux-gnu/librados.so.2

 librados currently requests an executable stack.  It would be ideal if it
 didn't request such access so that programs such as /usr/bin/qemu-system-i386
 that link against it are less vulnerable to stack based attacks.

 Does librados even need an executable stack?  In a quick test it appeared to
 work without it.

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

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

 Versions of packages librados2 depends on:
 ii  libboost-system1.55.0  1.55.0+dfsg-3
 ii  libboost-thread1.55.0  1.55.0+dfsg-3
 ii  libc6  2.19-18
 ii  libgcc11:4.9.2-10
 ii  libnspr4   2:4.10.7-1
 ii  libnss32:3.17.2-1.1
 ii  libstdc++6 4.9.2-10
 ii  libuuid1   2.25.2-6
 ii  multiarch-support  2.19-18

 librados2 recommends no packages.

 librados2 suggests no packages.

 -- no debconf information
 ___
 Ceph-maintainers mailing list
 ceph-maintain...@lists.ceph.com
 http://lists.ceph.com/listinfo.cgi/ceph-maintainers-ceph.com


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#779785: clang-3.7: -fsanitize doesn't work due to missing ubsan libraries in 3.7 (they were in libclam-common-3.x-dev previously)

[Gregory Stark]

Package: clang-3.7
Version: 1:3.7~svn230892-1
Severity: normal


I get the following when I try to run clang-3.7 with 
-fsanitize=address,undefined:

configure:3866: checking whether the C compiler works
configure:3888: /usr/bin/clang -g -O2 -fsanitize=address,undefined   conftest.c 
 5
/usr/bin/ld: cannot find 
/usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.asan-x86_64.a: 
No such file or directory
/usr/bin/ld: cannot find 
/usr/lib/llvm-3.7/bin/../lib/clang/3.7.0/lib/linux/libclang_rt.ubsan-x86_64.a: 
No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Poking around it seems previous versions of clang these libraries
existed in the libclang-common-3.x-dev package. I'm not sure that
makes sense if they're needed at runtime under normal use so perhaps
they've moved to a different package?

I think I've installed all the relevant 3.7 packages but perhaps
there's a missing dependency and there's a package that isn't uploaded
yet that I'll need for clang to work properly?


$ apt-file search -x '/usr/lib/.*/lib/clang/.*/lib/linux'

libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.dfsan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.full-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.lsan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.msan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.profile-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.san-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.tsan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.ubsan-x86_64.a
libclang-common-3.4-dev: 
/usr/lib/llvm-3.4/lib/clang/3.4.2/lib/linux/libclang_rt.ubsan_cxx-x86_64.a

libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.builtins-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.dfsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.lsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.msan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.profile-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.san-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.tsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.ubsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.asan_cxx-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.builtins-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.dfsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.lsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.msan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.profile-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.san-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.tsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.ubsan-x86_64.a
libclang-common-3.5-dev: 
/usr/lib/llvm-3.5/lib/clang/3.5.1/lib/linux/libclang_rt.ubsan_cxx-x86_64.a

libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.asan-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.builtins-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.dfsan-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.lsan-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.msan-x86_64.a
libclang-common-3.6-dev: 
/usr/lib/llvm-3.6/lib/clang/3.6.0/lib/linux/libclang_rt.profile-x86_64.a
libclang-common-3.6-dev: 

Bug#775978: php5-ming: the package php5-ming is not available in Debian Jessie

[Gregory Fardel]

Package: php5-ming
Version: 1:0.4.5-1.2+b1
Severity: wishlist

Dear Maintainer,

In Debian 8.0 (Jessie), the package php5-ming is not available.
I can install this package only if I switch to Debian sid, and it works fine.
It is possible for you to upload the php5-ming package in the Jessie main 
archive ?

Best regards,

Have a nice day !

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

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

Versions of packages php5-ming depends on:
ii  libc6  2.19-13
ii  libming1   1:0.4.5-1.2+b1
ii  php5-common [phpapi-20131226]  5.6.4+dfsg-4

php5-ming recommends no packages.

php5-ming suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#534504: mediatomb: Daemon starts up too early in the boot process; interface not found

[Gregory Shimansky]

I just had a fresh install of Debian 7.7.0, and had the same problem with
mediatomb. After I configured INTEFACE to eth0 in /etc/default/mediatomb I
got this error in /var/log/mediatomb.log at startup:

2015-01-09 22:46:08   ERROR: Could not determine interface address: Cannot
assign requested address
2015-01-09 22:46:08   ERROR: Could not find interface: eth0

The problem appears to be in minissdpd service. For some reason it was
added to startup together with mediatomb. I don't know which dependency
pulled this service and why it was enabled by default. After removing
minissdpd package I have meditomb running just fine at startup.

-- 
Gregory

Bug#771092: insighttoolkit: Build failure on sparc

[Gregory Sharp]

Package: insighttoolkit
Version: 3.20.1+git20120521-5+b1
Severity: normal

The sparc build continuously fails with the following message:

Preparing to unpack .../libuuid1_2.25.2-3_sparc.deb ...
Unpacking libuuid1:sparc (2.25.2-3) over (2.25.2-2) ...
Setting up libuuid1:sparc (2.25.2-3) ...
/var/lib/dpkg/info/libuuid1:sparc.postinst: 15:
/var/lib/dpkg/info/libuuid1:sparc.postinst: groupmod: not found
dpkg: error processing package libuuid1:sparc (--configure):
 subprocess installed post-installation script returned error exit status 127
Errors were encountered while processing:
 libuuid1:sparc
E: Sub-process /usr/bin/dpkg returned an error code (1)
apt-get failed.

See for example:

https://buildd.debian.org/status/fetch.php?pkg=insighttoolkitarch=sparcver=3.20.1%2Bgit20120521-5%2Bb1stamp=1416898633


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#771094: nmu: plastimatch_1.5.16+dfsg-2

[Gregory Sharp]

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

nmu plastimatch_1.5.16+dfsg-2 . ALL -amd64 -arm64 -hurd-i386 -i386 -ppc64el .
-m Rebuild against new libinsighttoolkit3-dev

This is needed to resolve #769975.

Thank you,
Greg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#770837: nmu: insighttoolkit_3.20.1+git20120521-5

[Gregory Sharp]

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

nmu insighttoolkit_3.20.1+git20120521-5 . !ppc64el . -m Rebuild against
multi-arch gdcm library

The binNMU is needed to resolve #768769, and eventually #769975.

Thank you,
Greg


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org