Bug#811352: linux 4.4-rc8: i915: "[drm] stuck on render ring" on resume

[Julian Andres Klode]

Package: src:linux
Version: 4.4~rc8-1~exp1
Severity: normal

I'm not sure if that's the right package to report this bug, it could
also be mesa, the X11 driver, or maybe even gnome-shell. Anyway, I don't
think I have seen this with 4.3:

Often, when resuming the GPU hangs, and gnome-shell thus exits and then
restarts, delaying usable resume by about 13 seconds.

I'm running xserver-xorg-video-intel 2.99.917+git20151217-1~exp1 from
experimental (as unstable has a few bugs fixed in there), and libdrm
2.4.65-3. Neither have been upgraded recently, so it is
likely the kernel causing the issue, as this is a very recent
problem.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 2325CN3
product_version: ThinkPad X230
chassis_vendor: LENOVO
chassis_version: Not Available
bios_vendor: LENOVO
bios_version: G2ETA5WW (2.65 )
board_vendor: LENOVO
board_name: 2325CN3
board_version: Not Defined

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM 
Controller [8086:0154] (rev 09)
Subsystem: Lenovo 3rd Gen Core processor DRAM Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ivb_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation 3rd Gen Core 
processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Lenovo 3rd Gen Core processor Graphics Controller [17aa:21fa]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-  [disabled]
Capabilities: 
Kernel driver in use: i915
Kernel modules: i915

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family USB xHCI Host 
Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series 
Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
Subsystem: Lenovo 7 Series/C210 Series Chipset Family MEI Controller 
[17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
Connection [8086:1502] (rev 04)
Subsystem: Lenovo 82579LM Gigabit Network Connection [17aa:21f3]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: e1000e
Kernel modules: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI])
Subsystem: Lenovo 7 Series/C210 Series Chipset Family USB Enhanced Host 
Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset 
Family High Definition Audio Controller [8086:1e20] (rev 04)
Subsystem: Lenovo 7 Series/C210 Series Chipset Family High Definition 
Audio Controller [17aa:21fa]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset 
Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.1 PCI bridge [0604]: Intel Corporation 7 

Bug#811391: finish-install.d/07speakup: remove superfluous 'fi' leftover

[Hendrik Brueckner]

Control: tags -1 + patch

Attaching patch.
>From 71840fc0f7bcb9c5d80330bb8ccbc1b2e4a673e0 Mon Sep 17 00:00:00 2001
From: Hendrik Brueckner 
Date: Mon, 18 Jan 2016 15:23:00 +0100
Subject: [PATCH] speakup: remove superfluous 'fi'

Commit cd6e3cab78fc3 "Enable screen reader in KDE" removed an if
condition but left the 'fi' there.  Found this problem by inspecting
the d-i syslog:

Jan 14 15:40:18 finish-install: /usr/lib/finish-install.d/07speakup: line 95:
syntax error: unexpected "fi"

Signed-off-by: Hendrik Brueckner 
---
 debian/changelog   | 8 
 finish-install.d/07speakup | 1 -
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/debian/changelog b/debian/changelog
index ab9d9dd..b59331a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+finish-install (2.59) UNRELEASED; urgency=medium
+
+  [Hendrik Brueckner]
+  * finish-install.d/07speakup: remove superfluous 'fi' leftover
+(Closes: #811391)
+
+ -- Hendrik Brueckner   Mon, 18 Jan 2016 
15:26:04 +0100
+
 finish-install (2.58) unstable; urgency=high
 
   [ Steve McIntyre ]
diff --git a/finish-install.d/07speakup b/finish-install.d/07speakup
index 3767cc4..4219dfc 100755
--- a/finish-install.d/07speakup
+++ b/finish-install.d/07speakup
@@ -90,7 +90,6 @@ END
/bin/in-target su -s /bin/sh -c "kwriteconfig --file 
kaccessibleapp --group Main --key SpeechEnabled 'true'" "$USERNAME" || true
# KDE5
/bin/in-target su -s /bin/sh -c "kwriteconfig5 --file kaccessrc 
--group ScreenReader --key Enabled 'true'" "$USERNAME" || true
-   fi
fi
 fi
 
-- 
2.6.4

Bug#811274: nmu: mmpong smc

[Esa Peuha]

On Mon, Jan 18, 2016 at 4:21 PM, Jonathan Wiltshire  wrote:
> Is this going to happen often? I'm not excited by the idea of having to get
> involved every time the version number for cegui-mk2 gets incremented...

I'm afraid I don't know; the only reason I even noticed this is that
currently the removal of ogre-1.8 (#797423) is blocked by stale
cegui-mk2 binaries. After sending the binNMU request, I did notice
that there is an open transition bug for cegui-mk2 (#732763) that
is now a little over two years old, so if I had to guess, I'd say
there's no danger of cegui-mk2 getting too frequent updates...

Bug#811391: finish-install.d/07speakup: remove superfluous 'fi' leftover

[Samuel Thibault]

Control: tags -1 + pending
Control: severity -1 minor

Hendrik Brueckner, on Mon 18 Jan 2016 15:34:02 +0100, wrote:
> The d-i syslog contains this error message:
> 
> Jan 14 15:40:18 finish-install: /usr/lib/finish-install.d/07speakup: line 95:
> syntax error: unexpected "fi"

D'oh.  And things are just working fine because it's only a spurious fi.

Thanks for the notice,
Samuel

Bug#811214: RFS: retroarch/1.3.0-1 [ITP]

[rondom]

I had a look at libretro-mupen64plus (out of curiosity only). I saw that
it bundles a copy of mupen64plus and its modules.

Due to the fact that Mupen64plus can be used as a library and it is
already in Debian I am wondering in how far this copy differs from the
upstream mupen64plus.
Given that emulators handle a lot of untrusted data from various
(sometimes shady) sources I am wondering whether it is possible/feasible
to use the already packaged mupen64plus with libretro.

I am not very familiar with libretro, so please excuse my ignorance.

On 18/01/16 02:00, Sérgio Benjamim wrote:
> RetroArch has these 2 packages as dependencies:
> 
> retroarch-assets: http://mentors.debian.net/package/retroarch-assets
> (icons for the menu drivers, like XMB)
> 
> libretro-core-info: http://mentors.debian.net/package/libretro-core-info
> (has useful info about authors, license, supported extensions, firmware)
> 
> 
> There are some packages for libretro cores:
> 
> Game Boy [Color]: http://mentors.debian.net/package/libretro-gambatte
> 
> Game Boy Advance: http://mentors.debian.net/package/mgba (it's already
> in the NEW queue)
> 
> Nintendo DS: http://mentors.debian.net/package/libretro-desmume
> 
> Genesis and other Sega consoles/handhelds:
> http://mentors.debian.net/package/genesisplusgx
> 
> NEC PC Engine / TurboGrafx:
> http://mentors.debian.net/package/libretro-beetle-pce-fast
> 
> PlayStation: http://mentors.debian.net/package/libretro-beetle-psx
> 
> Nintendo 64: http://mentors.debian.net/package/libretro-mupen64plus
> 
> SNES: http://mentors.debian.net/package/libretro-bsnes-mercury
> 
> SNES: http://mentors.debian.net/package/snes9x
> 
> 
> 
> 
> Sergio Benjamim
> 

Bug#811347: newer 1.3.2 debian package available for review

[Tino Mettler]

On Mon, Jan 18, 2016 at 14:14:08 +, Chris Knadle wrote:
> Chris Knadle:

[...]

> Edit: the actual build failure looks like it might be lack of finding a
> crypto library:

[...]

> /usr/bin/ld: cannot find -lcrypto-lQtGui

Missing space? Should be -lcrypto -lQtGui I think.

Regards,
Tino

Bug#811207: transition: libcutl

[Jonathan Wiltshire]

On 2016-01-18 13:23, László Böszörményi wrote:
On Sat, Jan 16, 2016 at 11:34 PM, Jonathan Wiltshire  
wrote:

On 2016-01-16 20:17, Laszlo Boszormenyi (GCS) wrote:

[...], but I plan to upload soname 1.10 version. May I upload
it directly to Sid or should I target experimental first?
The only affected binary is odb which can be binNMUed. Libraries are
co-installable.


If you have tested odb and it builds correctly with the new library, 
you may

upload directly to sid.

 Yes, of course I've tested odb and it built correctly. Uploaded
libcutl 1.10 to Sid and built / installed on all primary
architectures; expect mips where it's still scheduled.


Thanks, scheduled with --extra-depends.


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Bug#811388: consider switching to unix sockets by default

[Pirate Praveen]

package: redis-server
version: 2:3.0.3-2
severity: wishlist

Can we switch to unix sockets by default? I'm packaging gitlab and they
recommend using unix sockets for gitlab [1]. I think it would be better
for security for whole debian.

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/9081#note_3265402

In case, we can't make it default, can we add a debconf option to let
users make that choice? I'm trying to make gitlab configuration via
debconf without having to touch any configuration files.




signature.asc
Description: OpenPGP digital signature

Bug#811360: [pkg-horde] Bug#811360: php-horde-mapi: depends on not-in-the-archive-anymore php-math-biginteger

[Mattia Rizzolo]

On Mon, Jan 18, 2016 at 02:15:21PM +0100, Mathieu Parent wrote:
> It shouldn't, as this package is provided by php-seclib.
> 
> See https://tracker.debian.org/media/packages/p/phpseclib/control-1.0.0-3

ah, I didn't notice there was also a virtual package providing it.

> > Is it possible to have a binary without such dependency?
> 
> Given the above: Why?

if there is an alternative is ok leave it as it is.
It's just that tooling is not so good at mixing real and virtual
packages...
This means I'm going to request a manual removal of the old package from
testing, then.

https://bugs.debian.org/811387
Let's see how this goes, If everything's fine I'll close this bug as
soon as the real php-math-biginteger is completely gone.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#811274: nmu: mmpong smc

[Jonathan Wiltshire]

Control: tag -1 moreinfo

On 2016-01-17 14:48, Esa Peuha wrote:

Recent update of the cegui-mk2 source package changed the name of the
binary package from libcegui-mk2-0.7.6 to libcegui-mk2-0.8.4 with the
result that the dependent packages need a binNMU. Apparently there
are only two of them in unstable, mmpong and smc. There doesn't seem
to be any problems with mmpong, but smc has been built on kfreebsd-*
on which the new cegui-mk2 source fails to build, so that might need
a dep-wait.


Is this going to happen often? I'm not excited by the idea of having to 
get involved every time the version number for cegui-mk2 gets 
incremented...


--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

 i have six years of solaris sysadmin experience, from
8->10. i am well qualified to say it is made from bonghits
layered on top of bonghits

Bug#811389: graphite-web: Incomplete chown instructions in README.debian

[Slaven Rezic]

Package: graphite-web
Version: 0.9.12+debian-6
Severity: normal

Dear Maintainer,

followed the sqlite instructions in
/usr/share/doc/graphite-web/README.Debian --- and it seems that
the chown instruction is incomplete. Also the parent directory
/var/lib/graphite has to belong to the _graphite user, otherwise
sqlite is not able to create journal files.

So the following line should be added:

# chown _graphite:_graphite /var/lib/graphite

This is also relevant to the 0.9.15+debian-1 package.

Regards,
Slaven

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

Kernel: Linux 3.16.0-4-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: systemd (via /run/systemd/system)

Versions of packages graphite-web depends on:
ii  adduser3.113+nmu3
ii  libjs-jquery   1.7.2+dfsg-3.2
ii  libjs-jquery-flot  0.8.2+dfsg-1
ii  libjs-prototype1.7.1-3
ii  libjs-scriptaculous1.9.0-2
ii  python 2.7.9-1
ii  python-cairo   1.8.8-1+b2
ii  python-django  1.7.7-1+deb8u3
ii  python-django-tagging  1:0.3.1-4
ii  python-pyparsing   2.0.3+dfsg1-1
ii  python-simplejson  3.6.5-1
ii  python-tz  2012c+dfsg-0.1
ii  python-whisper 0.9.12-1

graphite-web recommends no packages.

Versions of packages graphite-web suggests:
pn  graphite-carbon  
pn  libapache2-mod-wsgi  
pn  python-ldap  
pn  python-memcache  
pn  python-mysqldb   

-- no debconf information

Bug#811347: newer 1.3.2 debian package available for review

[Chris Knadle]

Tino Mettler:
> On Mon, Jan 18, 2016 at 14:14:08 +, Chris Knadle wrote:
>> Chris Knadle:
> 
> [...]
> 
>> Edit: the actual build failure looks like it might be lack of finding a
>> crypto library:
> 
> [...]
> 
>> /usr/bin/ld: cannot find -lcrypto-lQtGui
> 
> Missing space? Should be -lcrypto -lQtGui I think.

Yeah I donno; the only place I see "-lcrypto" is in the xca.pro file:

   xca.pro:LIBS += -lcrypto -lltdl -lstdc++

and similarly with "-lQtGui":

   configure.ac:QT_LIBS=" -lQtCore -lQtGui "

so best guess is that this is something generated by calling automake.

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

[Luke Kenneth Casson Leighton]

simon, hi, many apologies for not following up: my friend running the
server discovered, after around 18 months of puzzled investigation,
that he had (or perhaps had not) added a certain critical
system-required file to .gitignore as part of the upgrade to
gitolite3.  exact details are hard to remember (plus it wasn't me
doing the investigating) but this was very obscure, but finally
solved.

the typical ikiwiki git arrangement was as you described.  although it
would only be a kludge, the "manual recovery" i propose(d) would be an
"rm -fr * and a git clone", or a "git reset --hard".  this would at
least permit people in similar circumstances to at least run a
functioning web site from a remote laptop whilst there was a sysadmin
(2nd person) who could only respond on a delayed schedule.

l.

Bug#810848: ace-of-penguins: 4 doesn't call the four suits game

[Esa Peuha]

On Mon, Jan 18, 2016 at 1:34 AM, Markus Koschany  wrote:
> The affected game is Penguin Spider. According to the help menu it
> should be possible to choose a four suits or two suits game by pressing
> the buttons 4 or 2. But pressing 4 or 2 in version 1.5~rc1 reshuffles
> the cards presenting a new one suite game. For me this looks like a bug
> or an intentional change but then the help menu is out-of-sync. What do
> you think?

This is definitely a bug. Pressing 1, 2 or 4 sets the variable
suit_mask and calls start_again() but currently suit_mask is only
used in init() which is only called once; IOW this is a case of
manual over-optimization. I will fix this in CVS as soon as I have
time to work on it (hopefully tomorrow).

Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package

[Stefan Ahlers]

Hi,

> please ping me when the jreen is accepted, I'll go in a new review spin.

Ok, I'll do it.

> please point to the sources, and look if the copyright shows them.
> http://metadata.ftp-master.debian.org/changelogs/main/c/clementine/unstable_copyright

Tomahawk and clementine uses the company logos for the provided
services/resolvers. On both software, the logos are necessary to show
the music streaming source. This is a requirement to use this services.

I discussed the problematic with the developers of tomahawk but they
think it is not a good idea to replace them because the company only
allows the use of their services if there is the company branding. It
would be more critical to replace them with self-made-ones than to ship
the logos.

For example in the clementine sources:
 * clementine-1.2.3+git1354-gdaddbde+dfsg/data/icons/svg/spotify.svg
 * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/soundcloud.png
 * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/itunes.png
 * clementine-1.2.3+git1354-gdaddbde+dfsg/data/providers/echonest.png
There are many more company branding in /data/providers but there is no
comment in the copyright file.

I think this is a very important issue.

Stefan

Bug#811390: ITP: ruby-hamster -- Efficient, immutable, thread-safe collection classes for Ruby

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-hamster
  Version : 2.0.0
  Upstream Author : Simon Harris
* URL : https://rubygems.org/gems/hamster
* License : Expat
  Programming Lang: Ruby
  Description : Efficient, immutable, thread-safe collection classes for 
Ruby

Packaging as dependency of Sonic Pi (ITP #796550)

Bug#811391: finish-install.d/07speakup: remove superfluous 'fi' leftover

[Hendrik Brueckner]

Package: finish-install
Version: 2.58
Severity: normal
Tags: d-i

The d-i syslog contains this error message:

Jan 14 15:40:18 finish-install: /usr/lib/finish-install.d/07speakup: line 95:
syntax error: unexpected "fi"

Correct shell syntax in finish-install.d/07speakup.  Patch will follow.

Thanks and kind regards,
  Hendrik

Bug#811266: pulseaudio: log is flooded sometimes when combined with torsocks (torify)

[Felipe Sateler]

Control: tags -1 moreinfo

Hi,

On 17 January 2016 at 09:09, Andreas B. Mundt  wrote:
> Package: pulseaudio
> Version: 7.1-2
> Severity: normal
>
> Dear Maintainer,
>
> when playing a stream using a music player with torsocks like:
>
>   torify mpg321 http://mp3stream1.apasf.apa.at:8000
>
> it happens sometimes that no music is played, instead the log is
> flooded with identical messages like:
>
> pulseaudio[3148]: [pulseaudio] socket-server.c: accept(): Bad address
>
> On my system, 33 174 574 lines like the above ended up in
> /var/log/user.log within 73 seconds.  Yesterday, I ended up with no
> space left on my root partition because /var/log/user.log and
> /var/log/syslog both grow to a size of > 5G within minutes, before I
> realized the problem.
>
> I've not figured out yet when it works, it seems to fail only the
> first time after reboot.  Once pulseaudio is killed and tried again, it
> seems to work, also after stopping and starting again there where no
> issues so far.
>
> I'm not sure if this is only pulseaudio's problem, feel free to clone
> or reassign.

Could you attach a verbose log of when the problem happens?

https://wiki.ubuntu.com/PulseAudio/Log


Also, as a workaround you can try disabling logging with the
log-target option in default.pa (eg, set it to file:/dev/null)

-- 

Saludos,
Felipe Sateler

Bug#805487: Intent to NMU sysvinit, init-system-helpers.

[Andreas Henriksson]

Hello Ben Hutchings.

On Mon, Jan 18, 2016 at 01:06:44PM +, Ben Hutchings wrote:
[...]
> I also planned an NMU to sysvinit, and have just committed my changes
> to the git master branch.  As it looks like your changes are also
> ready, could you merge them to master and then upload?

Thanks for asking but please go ahead without my changes for now. I'll
likely start a wider discussion on the init-helper tools given that I'm
moving things around which affects essential packages on debian-devel
before moving forward.

> 
> Note that sysvinit no longer has any active maintainers (at least, none
> that consider themselves so), so don't expect much response from that
> side.

I've been able to sucker pere into answering some questions on IRC even
though he insists on not being a sysvinit authority anymore.

For official status today the best info is (the lack of any other
followup than) this I think:
http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/2015-May/008086.html

Regards,
Andreas Henriksson

Bug#796208: ca-certificates: removal of SPI CA

[Thijs Kinkhorst]

On Sat, January 16, 2016 22:15, Robert Edmonds wrote:
> Axel Beckert wrote:
>> So why was the CA then removed already if debconf.org still uses this
>> CA? https://www.debconf.org/ is now reported as broken.
>
> Hi,
>
> If you examine the certificate served by www.debconf.org:443, it has a
> common name of wiki.debconf.org, with SANs for wiki.debconf.org and
> www.wiki.debconf.org.  It will report as broken regardless of which CAs
> are in the ca-certificates package, because the server does not appear
> to be configured to correctly serve its www.debconf.org virtual host via
> HTTPS.
>
> Also note that the certificate is issued by "Gandi Standard SSL CA 2",
> not SPI, Inc.
>
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 71:12:ca:53:8d:33:d4:41:c7:c6:63:f5:04:ed:22:84
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: C=FR, ST=Paris, L=Paris, O=Gandi, CN=Gandi Standard SSL CA
> 2
> Validity
> Not Before: Jan  1 00:00:00 2016 GMT
> Not After : Jan  1 23:59:59 2017 GMT
> Subject: OU=Domain Control Validated, OU=Gandi Standard SSL,
> CN=wiki.debconf.org
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (4096 bit)
> Modulus:
> 00:c0:84:16:fc:c8:8b:78:aa:b9:ac:db:b4:23:fc:
> 2a:db:d9:6b:76:1d:de:92:8c:4c:d7:86:5f:15:d4:
> 15:90:64:7d:a9:05:cd:4c:49:63:63:00:e3:a6:63:
> bb:04:29:fb:67:ee:d7:25:17:4f:e1:87:23:fa:a1:
> ea:38:aa:9d:dc:d6:a0:f7:ab:5f:44:43:1f:03:80:
> d9:d3:39:e0:42:5a:48:91:b3:da:b3:b1:1e:fa:86:
> 0b:5d:b7:34:fe:f1:22:e7:96:58:2e:c3:86:09:e1:
> 5b:82:54:a0:e7:db:ba:fa:0c:6c:f6:42:4d:54:54:
> 2a:4a:48:87:35:f9:71:e8:67:a9:8e:ba:23:74:32:
> 12:dc:ff:15:9b:c3:98:bd:d1:0c:ba:3f:2d:de:50:
> 71:27:ef:a1:88:96:f2:d5:15:d8:ff:14:c2:c4:b8:
> 83:32:81:a8:91:67:97:19:c1:c2:c1:e2:0c:1b:4b:
> 4f:f2:19:fb:19:4a:07:ee:29:36:13:dd:0c:a2:76:
> 48:79:d7:a0:03:51:d4:7f:31:a5:5d:00:dc:4f:cc:
> 3b:f9:00:84:d6:2b:63:d7:86:e7:e3:aa:7a:f9:6f:
> 75:2b:87:0d:c9:82:3e:85:03:d6:a0:7a:2e:cf:b2:
> 85:9a:72:38:51:92:f6:a7:d9:d1:19:97:e3:3e:99:
> c5:b6:ae:c9:55:77:34:34:ae:a5:66:3a:5d:13:57:
> 25:da:44:29:43:dd:33:ca:05:53:c0:3f:84:e3:64:
> 12:d2:b0:68:d9:05:55:8e:14:e6:99:6d:bd:73:e4:
> e9:f9:3c:26:5b:f1:1c:fa:a2:28:dc:ea:24:af:71:
> 33:66:10:14:a9:3a:c1:a1:ca:66:f2:bd:31:08:60:
> 2c:b4:f9:d6:a9:6c:3b:7c:c4:bd:99:42:b4:7f:f5:
> 0e:14:ea:13:80:c2:bd:ea:4f:c2:ff:ff:ae:67:2c:
> 8e:5a:40:87:85:97:b8:c1:25:f5:5d:e2:1f:cf:bb:
> f1:18:89:0a:08:2c:da:b1:d8:1d:4d:c2:7b:4b:67:
> eb:af:e8:38:7c:74:41:8b:7f:08:cb:1a:24:d1:0e:
> c4:2f:5c:cd:ff:6a:96:c3:34:b2:f8:bb:4e:50:66:
> 82:84:02:4b:b9:81:4b:a8:1c:d6:90:35:56:26:a1:
> 8f:b9:8b:68:a0:78:f5:f7:75:e9:cb:de:8a:b1:1d:
> c6:e3:df:7b:08:bc:39:76:cf:ed:6b:29:9b:2c:f5:
> 06:3f:d5:9d:32:c6:cd:9a:42:1f:66:ee:3c:4e:21:
> b3:30:7c:74:d0:ed:80:6c:d2:a9:01:1c:91:b1:b0:
> ac:4d:99:09:4c:ac:dd:7b:d6:21:95:37:d5:6e:4a:
> ef:0b:6f
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Authority Key Identifier:
> 
> keyid:B3:90:A7:D8:C9:AF:4E:CD:61:3C:9F:7C:AD:5D:7F:41:FD:69:30:EA
>
> X509v3 Subject Key Identifier:
> 92:53:21:4C:FE:33:67:8A:BB:CA:17:19:49:EF:30:FD:15:F9:EE:56
> X509v3 Key Usage: critical
> Digital Signature, Key Encipherment
> X509v3 Basic Constraints: critical
> CA:FALSE
> X509v3 Extended Key Usage:
> TLS Web Server Authentication, TLS Web Client
> Authentication
> X509v3 Certificate Policies:
> Policy: 1.3.6.1.4.1.6449.1.2.2.26
>   CPS: https://cps.usertrust.com
> Policy: 2.23.140.1.2.1
>
> X509v3 CRL Distribution Points:
>
> Full Name:
>   URI:http://crl.usertrust.com/GandiStandardSSLCA2.crl
>
> Authority Information Access:
> CA Issuers -
> URI:http://crt.usertrust.com/GandiStandardSSLCA2.crt
> OCSP - URI:http://ocsp.usertrust.com
>
> X509v3 Subject Alternative Name:
> DNS:wiki.debconf.org, DNS:www.wiki.debconf.org
> Signature Algorithm: sha256WithRSAEncryption
>  

Bug#811379: libmia-2.2-dev: switch from libgsl0-dev to libgsl-dev

[Andreas Beckmann]

Package: libmia-2.2-dev
Version: 2.2.7-2
Severity: important

Hi,

you switched src:mia's B-D to libgsl-dev, but libmia-2.2-dev still
depends on libgsl0-dev which makes it a bit awkward to install right now
because apt/aptitude prefer to install the real package libgsl0-dev
(1.16+dfsg-4, which in uninstallble) over the virtual one provided by
libgsl-dev. This would clear up itself once the old libgsl0-dev goes
away, which requires the transition to have finished completely.
Also src:gsl probably want's to drop the convenience Provides:
libgsl0-dev at some point.


Andreas

Bug#805487: Intent to NMU sysvinit, init-system-helpers.

[Ben Hutchings]

On Tue, 5 Jan 2016 14:15:15 +0100 Andreas Henriksson  wrote:
> Hello!
> 
> I think the current state of the previously announced sysvinit[0] and
> init-system-helpers[1] branches should now be in decent shape to
> upload this to the archive. Partially motivated by the recently
> announced "If you are hoping to do any larger changes for stretch,
> please consider starting on them now"[2].
> I'm thus announcing my intent to NMU, please speak up now if you
> have any objections...
> 
> As I see it init-system-helpers have given their acknowledgement
> for NMU based on previous comment from Michael Biebl on this bug
> report and the just now ack and support from Martin Pitt on IRC.
[...]

I also planned an NMU to sysvinit, and have just committed my changes
to the git master branch.  As it looks like your changes are also
ready, could you merge them to master and then upload?

Note that sysvinit no longer has any active maintainers (at least, none
that consider themselves so), so don't expect much response from that
side.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai Stevenson

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

Bug#811377: RFA: sysvinit -- System-V-like init utilities - transitional package

[Ben Hutchings]

Package: wnpp
Severity: normal

I request an adopter for the sysvinit package.

Although it is team-maintained, I have found that none of the listed
uploaders are still active:

- Petter Reinholdtsen says he has retired from maintenance
- Henrique de Moraes Holschuh has not committed for over 6 years
- Kel Modderman has not committed for over 3 years
- Roger Leigh is retired from Debian
- Thomas Goirand says he 'never really was' a maintainer

Ben.

The package description is:
 This package contains programs required for booting
 a Debian system and doing basic process management.
 .
 The most important program in the package is /sbin/init.
 It is the first process started on boot and continues
 to run as process number 1 until the system halts. All
 other processes are descended from it.

Bug#811378: mirror submission for ftp.uni-hannover.de

[Patrick Njofang]

Package: mirrors
Severity: wishlist

Submission-Type: new
Site: ftp.uni-hannover.de
Aliases: ftp.luis.uni-hannover.de
Type: leaf
Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mipsel powerpc s390x sparc 
Archive-ftp: /debian/debian/
Archive-http: /debian/debian/
Backports-ftp: /debian/debian-backports/
Backports-http: /debian/debian-backports/
CDImage-ftp: /debian/debian-cd/
CDImage-http: /debian/debian-cd/
IPv6: no
Archive-upstream: ftp.de.debian.org
Backports-upstream: ftp.de.debian.org
CDImage-upstream: ftp.de.debian.org
Updates: four
Maintainer: Patrick Njofang 
Country: DE Germany
Location: Hannover, Germany
Sponsor: Uni Hannover http://www.luis.uni-hannover.de

Bug#805487: Intent to NMU sysvinit, init-system-helpers.

[Ben Hutchings]

On Mon, 2016-01-18 at 13:06 +, Ben Hutchings wrote:
> On Tue, 5 Jan 2016 14:15:15 +0100 Andreas Henriksson  wrote:
> > Hello!
> >  
> > I think the current state of the previously announced sysvinit[0] and
> > init-system-helpers[1] branches should now be in decent shape to
> > upload this to the archive. Partially motivated by the recently
> > announced "If you are hoping to do any larger changes for stretch,
> > please consider starting on them now"[2].
> > I'm thus announcing my intent to NMU, please speak up now if you
> > have any objections...
> >  
> > As I see it init-system-helpers have given their acknowledgement
> > for NMU based on previous comment from Michael Biebl on this bug
> > report and the just now ack and support from Martin Pitt on IRC.
> [...]
> 
> I also planned an NMU to sysvinit, and have just committed my changes
> to the git master branch.  As it looks like your changes are also
> ready, could you merge them to master and then upload?

Actually, I've gone ahead and done the merge myself but not uploaded
since init-system-helpers needs to go first.

Ben.

> Note that sysvinit no longer has any active maintainers (at least, none
> that consider themselves so), so don't expect much response from that
> side.
> 
> Ben.
> 
-- 
Ben Hutchings
A free society is one where it is safe to be unpopular. - Adlai Stevenson

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

Bug#811360: [pkg-horde] Bug#811360: php-horde-mapi: depends on not-in-the-archive-anymore php-math-biginteger

[Mathieu Parent]

2016-01-18 11:15 GMT+01:00 Mattia Rizzolo :
> Package: php-horde-mapi
> Version: 1.0.5-3
> Severity: serious
>
> Dear maintainer,
>
> your package depends on a package not available anymore in unstable, and
> that is keep in testing just for you.

It shouldn't, as this package is provided by php-seclib.

See https://tracker.debian.org/media/packages/p/phpseclib/control-1.0.0-3

> Is it possible to have a binary without such dependency?

Given the above: Why?

Regards

-- 
Mathieu

Bug#811383: linux-image-4.3.0-1-amd64: drm:intel_dp_aux_ch [i915] *ERROR* dp aux hw did not signal timeout

[Felix Defrance]

Package: src:linux
Version: 4.3.0-1-amd64
Severity: important

Dear Maintainer,

I have installed Debian Stretch on my new laptop Dell XPS 15 (9550). It's the 
model version: i7, 16G RAM, 512 SSD, and 4k QHD screen.

The problem: the screen don't work at boot. 
Gdm work but i can see nothing on the screen (screen is on, but stay black).

Sometime, when i push the power botton, the laptop drop down into power suspend 
mode.
After that, when i push the botton again, it wake up and i can see the login 
screen. 
In this step, the laptop work, (screen is ok but stay unstable).

It's impossible to lock the screen for example. In the case, i need to drop 
down in PMsuspend mode again

-- Package-specific info:
** Version:
Linux stellar 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 (2016-01-04) x86_64 GNU/Linux

** Command line:
Kernel command line: BOOT_IMAGE=/vmlinuz-4.3.0-1-amd64 
root=/dev/mapper/vg_stellar-rootfs ro quiet 
cryptdevice=51fc65f7-a622-46c2-8b52-bb2e71166ee9:lvm 

With the "i915.preliminary_hw_support=1" boot option, it's the same problem.

** Kernel log:
Jan 18 13:40:33 stellar kernel: [7.143659] ACPI: Video Device [GFX0] 
(multi-head: yes  rom: no  post: no)
Jan 18 13:40:33 stellar kernel: [7.162045] ACPI: Battery Slot [BAT0] 
(battery present)
Jan 18 13:40:33 stellar kernel: [7.162687] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input12
Jan 18 13:40:33 stellar kernel: [7.162762] ACPI Exception: AE_NOT_FOUND, 
Evaluating _DOD (20150818/video-1153)
Jan 18 13:40:33 stellar kernel: [7.162763] ACPI: Video Device [PEGP] 
(multi-head: no  rom: yes  post: no)
Jan 18 13:40:33 stellar kernel: [7.162801] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:0a/LNXVIDEO:01/input/input13
Jan 18 13:40:33 stellar kernel: [7.171979] brcmfmac: brcmf_add_if: ERROR: 
netdev:wlp2s0 already exists
Jan 18 13:40:33 stellar kernel: [7.171979] brcmfmac: brcmf_add_if: ignore 
IF event
Jan 18 13:40:33 stellar kernel: [7.364105] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp aux hw did not signal timeout (has irq: 1)!
Jan 18 13:40:33 stellar kernel: [7.380077] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp aux hw did not signal timeout (has irq: 1)!
Jan 18 13:40:33 stellar kernel: [7.396078] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp aux hw did not signal timeout (has irq: 1)!
Jan 18 13:40:33 stellar kernel: [7.412082] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp aux hw did not signal timeout (has irq: 1)!
Jan 18 13:40:33 stellar kernel: [7.416922] ip_tables: (C) 2000-2006 
Netfilter Core Team
Jan 18 13:40:33 stellar kernel: [7.420226] ip6_tables: (C) 2000-2006 
Netfilter Core Team
Jan 18 13:40:33 stellar kernel: [7.427728] Ebtables v2.0 registered
Jan 18 13:40:33 stellar kernel: [7.428073] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp aux hw did not signal timeout (has irq: 1)!
Jan 18 13:40:33 stellar kernel: [7.428091] [drm:intel_dp_aux_ch [i915]] 
*ERROR* dp_aux_ch not done status 0xad40001f
Jan 18 13:40:33 stellar kernel: [7.452044] [ cut here 
]
Jan 18 13:40:33 stellar kernel: [7.452070] WARNING: CPU: 2 PID: 158 at 
/build/linux-dUKt9u/linux-4.3.3/drivers/gpu/drm/i915/intel_dp.c:854 
intel_dp_aux_ch+0x112/0x670 [i915]()
Jan 18 13:40:33 stellar kernel: [7.452071] dp_aux_ch not started status 
0xad40001f
Jan 18 13:40:33 stellar kernel: [7.452093] Modules linked in: 
ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables 
x_tables binfmt_misc uinput dell_wmi joydev sparse_keymap intel_rapl 
dell_laptop x86_pkg_temp_thermal dcdbas intel_powerclamp coretemp nouveau(+) 
brcmfmac kvm_intel uvcvideo i915(+) brcmutil videobuf2_vmalloc snd_hda_intel 
kvm videobuf2_memops rtsx_pci_ms cfg80211 mxm_wmi videobuf2_core snd_hda_codec 
memstick ttm snd_hda_core evdev psmouse snd_hwdep efi_pstore drm_kms_helper 
serio_raw pcspkr snd_pcm v4l2_common snd_timer drm videodev efivars 
hid_multitouch i2c_i801 mei_me processor_thermal_device snd btusb 
intel_soc_dts_iosf tpm_tis btrtl media soundcore mei shpchp iosf_mbi 
i2c_algo_bit tpm battery hci_uart btbcm btintel bluetooth rfkill 
int3403_thermal wmi dell_smo8800 video int3402_thermal int340x_thermal_zone 
int3400_thermal acpi_thermal_rel acpi_pad ac processor button parport_pc ppdev 
lp parport efivarfs autofs4 ext4 crc16 mbcache jbd2 alg
 if_skcipher af_alg usbhid dm_crypt dm_mod crct10dif_pclmul crc32_pclmul 
crc32c_intel rtsx_pci_sdmmc mmc_core jitterentropy_rng sha256_ssse3 
sha256_generic hmac drbg ansi_cprng aesni_intel aes_x86_64 lrw gf128mul 
glue_helper ablk_helper cryptd ahci libahci xhci_pci libata rtsx_pci xhci_hcd 
nvme mfd_core scsi_mod usbcore usb_common fan thermal i2c_hid hid
Jan 18 13:40:33 stellar kernel: [7.452109] CPU: 2 PID: 158 Comm: 
kworker/u16:3 Not tainted 4.3.0-1-amd64 #1 Debian 4.3.3-5
Jan 18 13:40:33 stellar kernel: [7.452110] Hardware name: Dell Inc. XPS 15 
9550/0N7TVV, BIOS 01.01.15 12/18/2015

Bug#811384: texlive-fonts-extra: inconsolata: missing Euro sign

[Thorsten Glaser]

Package: texlive-fonts-extra
Version: 2015.20160117-1
Severity: minor

I’m currently trying to literate¹ my listings. I’m using Inconsolata
as tt font and have already found out how to add … (Ellipsis) to the
list of supported characters, but am having trouble with € (Euro sign).
The font table² shows it ought to be on '001 in LY1 encoding, but the
attached dump program shows that the version of Inconsolata shipped
with sid doesn’t map anything to that codepoint.

① https://en.wikibooks.org/wiki/LaTeX/Source_Code_Listings#Encoding_issue
② ftp://ftp.fau.de/ctan/obsolete/fonts/inconsolata/inconsolata.pdf


##
 List of ls-R files

-rw-r--r-- 1 root root 2032 Jan 18 09:50 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Oct 14 05:48 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Jan 17 09:55 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Jan 17 09:55 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 1464 Jan 18 09:48 /etc/texmf/web2c/texmf.cnf
-rw-r--r-- 1 root root 3118 Jun 29  2015 /var/lib/texmf/web2c/fmtutil.cnf
lrwxrwxrwx 1 root root 32 Jan 17 09:55 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 4962 Jan 18 09:50 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root  283 Nov 26  2007 mktex.cnf
-rw-r--r-- 1 root root 1464 Jan 18 09:48 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf
055e06548bac99958d8ab2dd1248f2b4  /etc/texmf/texmf.d/80tex4ht.cnf
1df66bc319cec731e202eaf39f5d85e1  /etc/texmf/texmf.d/96JadeTeX.cnf

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

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages texlive-fonts-extra depends on:
ii  fonts-cabin  1.5-2
ii  fonts-comfortaa  2.003-1
ii  fonts-crosextra-caladea  20130214-1
ii  fonts-crosextra-carlito  20130920-1
ii  fonts-dejavu-core2.35-1
ii  fonts-dejavu-extra   2.35-1
ii  fonts-ebgaramond 0.015+git20130628-3
ii  fonts-ebgaramond-extra   0.015+git20130628-3
ii  fonts-font-awesome   4.5.0~dfsg-1
ii  fonts-freefont-otf   20120503-4
ii  fonts-freefont-ttf   20120503-4
ii  fonts-gfs-artemisia  1.1-5
ii  fonts-gfs-complutum  1.1-6
ii  fonts-gfs-didot  1.1-6
ii  fonts-gfs-neohellenic1.1-6
ii  fonts-gfs-olga   1.1-5
ii  fonts-gfs-solomos1.1-5
ii  fonts-junicode   0.7.8-2
ii  fonts-lato   2.0-1
ii  fonts-linuxlibertine 5.3.0-2
ii  fonts-lobstertwo 2.0-2
ii  fonts-oflb-asana-math000.907-6
ii  fonts-roboto-hinted  2:0~20160106-1
ii  fonts-sil-gentium20081126:1.03-1
ii  fonts-sil-gentium-basic  1.1-7
ii  fonts-sil-gentiumplus5.000-1
ii  fonts-stix   1.1.1-4
ii  tex-common   6.04
ii  texlive-base 2015.20160117-1
ii  ttf-adf-accanthis0.20090423-2
ii  ttf-adf-gillius  0.20090423-2
ii  ttf-adf-universalis  0.20090423-2

Versions of packages texlive-fonts-extra recommends:
ii  texlive-fonts-extra-doc  2015.20160117-1
ii  texlive-latex-extra  2015.20160117-1

Versions of packages texlive-fonts-extra suggests:
ii  cm-super  0.3.4-9

Versions of packages tex-common depends on:
ii  dpkg  1.18.4
ii  ucf   3.0031

Versions of packages tex-common suggests:
ii  debhelper  9.20160115

Versions of packages texlive-fonts-extra is related to:
ii  tex-common6.04
ii  texlive-binaries  2015.20150524.37493-7+b1

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:
% Copyright 2009 Karl Berry.
% You may freely use, modify and/or distribute this file.

\documentclass{article}

% No need for excessive margins.
\usepackage{fullpage}

% Try to output everything in a given TFM.
\usepackage{fonttable}

% What we're testing.
\usepackage{inconsolata}  % can use [scaled=1.1]

% For testing, much easier not to have to put entries in the system map files.
\pdfmapfile{+zi4.map}

\usepackage[T1]{fontenc}

\def\dofontenc#1#2{{\tt #1:} \fonttable{#2}\newpage}

\begin{document}

\thispagestyle{empty}
\pagestyle{empty}

% tables of (mostly) supported encodings.
% To actually use them in a document, need to specify
%  \usepackage[XYZ1]{fontenc}
% where XYZ1 is the LaTeX encoding name: T1, TS1, EI1, OT1, LY1, QX.
% 
\dofontenc{ec/T1}{t1-zi4r-0}
\dofontenc{qx/QXtt}{qx-zi4r-0}
\dofontenc{OT1}{ot1-zi4r-0}

Bug#775277: should we split krb5-kpropd into a separate package?

[Michael Weiser]

Hi Sam,

On Fri, Oct 16, 2015 at 01:24:05PM +, Sam Hartman wrote:

> I'm sorry.
> I thought I had responded long ago on this, but apparently not.
> I think the package split makes sense.

I finally got a chance to give this kpropd package split a whirl.
Attached is my first take on a patch.

What's your take on the upgrade path: Do we need to make sure that
someone who's using kpropd now doesn't get it uninstalled upon upgrade
of krb5-kdc? Should we have a preinst script that detects a running
kpropd and print a warning that he'll need to install krb5-kpropd?

Thanks,
-- 
Michael Weiserscience + computing ag
Senior Solutions ArchitectGeschaeftsstelle Duesseldorf
  Faehrstrasse 1
phone: +49 211 302 708 32 D-40221 Duesseldorf
fax:   +49 211 302 708 50 www.science-computing.de
-- 
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Dr. Arno Steitz, Yvonne Veyhelmann
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Aufsichtsrat/Supervisory Board:
Katrin James, Winfried Holz
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
>From 1a8ddc544abe303e2929edb6a9e4645e062b4caa Mon Sep 17 00:00:00 2001
From: Mark Proehl 
Date: Tue, 13 Jan 2015 14:34:50 +0100
Subject: [PATCH] Move kpropd into separate package

This allows for more fine-granular deployment of services and allows easy
integration of init script and systemd unit for kpropd (in addition to existing
inetd example). Fixes #775277.
---
 debian/control  |  21 +++-
 debian/krb5-kdc.install |   2 -
 debian/krb5-kdc.postinst|  12 -
 debian/krb5-kdc.prerm   |   6 ---
 debian/krb5-kpropd.init | 127 
 debian/krb5-kpropd.install  |   2 +
 debian/krb5-kpropd.postinst |  19 +++
 debian/krb5-kpropd.prerm|  13 +
 debian/krb5-kpropd.service  |  14 +
 debian/rules|   1 +
 10 files changed, 196 insertions(+), 21 deletions(-)
 create mode 100755 debian/krb5-kpropd.init
 create mode 100644 debian/krb5-kpropd.install
 create mode 100644 debian/krb5-kpropd.postinst
 create mode 100644 debian/krb5-kpropd.prerm
 create mode 100644 debian/krb5-kpropd.service

diff --git a/debian/control b/debian/control
index e81e946..71c24d9 100644
--- a/debian/control
+++ b/debian/control
@@ -39,7 +39,7 @@ Depends: ${misc:Depends}, ${shlibs:Depends}, libkrb5-3 (= 
${binary:Version}),
  libkadm5srv-mit9,
  krb5-config, krb5-user, lsb-base (>= 3.0-6), libverto-libev1 | 
libverto-libevent1,
  libkdb5-8 (>= 1.13.1+dfsg-1)
-Suggests: openbsd-inetd | inet-superserver, krb5-admin-server,
+Suggests: krb5-kpropd, krb5-admin-server,
  krb5-kdc-ldap (= ${binary:Version})
 Description: MIT Kerberos key server (KDC)
  Kerberos is a system for authenticating users and services on a network.
@@ -92,6 +92,25 @@ Description: MIT Kerberos master server (kadmind)
  slave KDCs.  This package is generally only used on the master KDC for a
  Kerberos realm.
 
+Package: krb5-kpropd
+Architecture: any
+Priority: optional
+Depends: ${misc:Depends}, ${shlibs:Depends},
+ krb5-kdc (= ${binary:Version})
+Suggests: openbsd-inetd | inet-superserver
+Description: MIT Kerberos key server (KDC)
+ Kerberos is a system for authenticating users and services on a network.
+ Kerberos is a trusted third-party service.  That means that there is a
+ third party (the Kerberos server) that is trusted by all the entities on
+ the network (users and services, usually called "principals").
+ .
+ This is the MIT reference implementation of Kerberos V5.
+ .
+ This package contains the Kerberos slave KDC update server (kpropd). The
+ kpropd command runs on the slave KDC server. It listens for update requests
+ made by the kprop program, and periodically requests incremental updates from
+ the master KDC. This package should be installed on slave KDCs.
+
 Package: krb5-multidev
 Section: libdevel
 Architecture: any
diff --git a/debian/krb5-kdc.install b/debian/krb5-kdc.install
index 93aecc4..15b0e83 100644
--- a/debian/krb5-kdc.install
+++ b/debian/krb5-kdc.install
@@ -2,8 +2,6 @@ usr/sbin/kproplog
 usr/share/man/man8/kproplog.8
 usr/sbin/kdb5_util
 usr/share/man/man8/kdb5_util.8
-usr/sbin/kpropd
-usr/share/man/man8/kpropd.8
 usr/sbin/krb5kdc
 usr/share/man/man8/krb5kdc.8
 usr/share/man/man5/kdc.conf.5
diff --git a/debian/krb5-kdc.postinst b/debian/krb5-kdc.postinst
index e90e301..6e5a8be 100644
--- a/debian/krb5-kdc.postinst
+++ b/debian/krb5-kdc.postinst
@@ -46,18 +46,6 @@ EOF
 db_stop
 fi
 
-# Only try to add the inetd line on an initial installation.  Add it
-# commented out in a way that will not be automatically enabled, since the
-# Kerberos administrator should do that manually when ready.
-#
-# If update-inetd isn't available, don't bother, since it's just an example.
-if [ "configure" = "$1" ] && which update-inetd 

Bug#811386: ITP: python-genty -- Python library for test generation

[Tristan Seligmann]

Package: wnpp
Severity: wishlist
Owner: Tristan Seligmann 

* Package name: python-genty
  Version : 1.3.0
  Upstream Author : Box 
* URL : https://github.com/box/genty
* License : Apache 2.0
  Programming Lang: Python
  Description : Python library for test generation

Needed as a test dependency for python-flaky. I will maintain this under DPMT.

Bug#811380: enigmail: does not show progress - if gpg is slow, signed email looks unsigned until gpg completes

[Andrew Gallagher]

Package: enigmail
Version: 2:1.8.2-4~deb8u1
Severity: normal

Dear Maintainer,

I have quite a large public keyring and gpg (v2.0 in particular) can be quite
slow to complete. While gpg is running, enigmail shows no indication that
processing is being performed. This means that emails quite often appear to be
unsigned even when they have (possibly valid) signatures.

Solution: enigmail should show a "working..." indicator in the toolbar as soon
as it detects pgp content, to be replaced by the success/failure notification
once processing is complete.

A



-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages enigmail depends on:
ii  gnupg1.4.18-7
ii  gnupg2   2.0.26-6
ii  icedove  38.5.0-1~deb8u1
ii  libc62.19-18+deb8u1

Versions of packages enigmail recommends:
ii  gnupg-agent   2.0.26-6
ii  gnupg22.0.26-6
ii  pinentry-gtk2 [pinentry-x11]  0.8.3-2

enigmail suggests no packages.

-- no debconf information

The information in this email and any attachments contain confidential 
information and is intended only for the individual named. If you are not the 
named addressee you should not disseminate, distribute or copy this e-mail, the 
attachments or any part thereof. Please notify the sender immediately by e-mail 
if you have received this e-mail by mistake and delete this e-mail from your 
system. E-mail transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability 
for any errors or omissions in the contents of this message which arise as a 
result of e-mail transmission. If verification is required please request a 
hard-copy version. Unless expressly stated, this email is not intended to 
create any contractual relationship. If this email is not sent in the course of 
the senders employment or fulfilment of his/her duties to Ward Solutions, Ward 
Solutions accepts no liability whatsoever for the content of this message or 
any attachment(s). Ward Solutions Ltd. Registered in Republic of Ireland at 
2054 Castle Drive, CityWest Business Campus, Dublin 24 Reg. No. 316165. 

Bug#811207: transition: libcutl

[GCS]

On Sat, Jan 16, 2016 at 11:34 PM, Jonathan Wiltshire  wrote:
> On 2016-01-16 20:17, Laszlo Boszormenyi (GCS) wrote:
>> [...], but I plan to upload soname 1.10 version. May I upload
>> it directly to Sid or should I target experimental first?
>> The only affected binary is odb which can be binNMUed. Libraries are
>> co-installable.
>
> If you have tested odb and it builds correctly with the new library, you may
> upload directly to sid.
 Yes, of course I've tested odb and it built correctly. Uploaded
libcutl 1.10 to Sid and built / installed on all primary
architectures; expect mips where it's still scheduled.

Regards,
Laszlo/GCS

Bug#811381: abiword: ftbfs with GCC-6

[Trevor Saunders]

Source: abiword
Severity: normal
Tags: upstream patch
Usertags: ftbfs-gcc-6

Dear Maintainer,

abiword fails to build with gcc-6.  This appears to be because g++ uses
C++ 11 by default which introduces several errors.  They include brace
initializers that use negative numbers to initialize unsigned variables,
"blah"foo not being valid because of operator "", and errors about
implicitly converting to bool.  The attached patch fixes enough of these
issues to get the package to compile, but it may not always be the best
way to resolve the issue.

-- System Information:
Debian Release: 8.2
  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_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- abiword-3.0.1.orig/plugins/collab/backends/service/xp/RealmProtocol.cpp
+++ abiword-3.0.1/plugins/collab/backends/service/xp/RealmProtocol.cpp
@@ -6,8 +6,8 @@ namespace protocolv1 {
 
 #define MAX_PACKET_DATA_SIZE 64*1024*1024
 		
-#define RPV1_PACKET_NONEXISTENT -2
-#define RPV1_PACKET_VARIABLE -1
+#define RPV1_PACKET_NONEXISTENT uint32_t(-2)
+#define RPV1_PACKET_VARIABLE uint32_t(-1)
 	
 static uint32_t body_size[6] = {
 	RPV1_PACKET_NONEXISTENT, /* 0: reserved */
--- abiword-3.0.1.orig/plugins/collab/backends/service/xp/soa_soup.cpp
+++ abiword-3.0.1/plugins/collab/backends/service/xp/soa_soup.cpp
@@ -163,7 +163,7 @@ namespace soup_soa {
 	
 	static bool _invoke(const std::string& /*url*/, const soa::method_invocation& /*mi*/, SoaSoupSession& sess, std::string& result) {
 		if (!sess.m_session || !sess.m_msg )
-			return soa::GenericPtr();
+			return false;
 
 		guint status = soup_session_send_message (sess.m_session, sess.m_msg);
 		if (!(SOUP_STATUS_IS_SUCCESSFUL (status) ||
--- abiword-3.0.1.orig/plugins/latex/xp/ie_exp_LaTeX.cpp
+++ abiword-3.0.1/plugins/latex/xp/ie_exp_LaTeX.cpp
@@ -1329,7 +1329,7 @@ void s_LaTeX_Listener::_outputData(const
 	m_pie->write(sBuf.c_str(),sBuf.size());
 }
 
-#define SUB(a,who) case a: subst = "\\(\\"who"\\)"; return true;
+#define SUB(a,who) case a: subst = "\\(\\" who"\\)"; return true;
 #define SUBd(a,who) case a: subst = who; return true;
 static bool _convertLettersToSymbols(char c, const char *& subst)
 {
--- abiword-3.0.1.orig/plugins/xslfo/xp/ie_exp_XSL-FO.cpp
+++ abiword-3.0.1/plugins/xslfo/xp/ie_exp_XSL-FO.cpp
@@ -1451,7 +1451,7 @@ void s_XSL_FO_Listener::_openSection(PT_
 	{ \
 		UT_UTF8String esc = szValue; \
 		esc.escapeXML(); \
-		buf += " "x"=\""; \
+		buf += " " x"=\""; \
 		buf += esc.utf8_str(); \
 		buf += "\""; \
 	}

Bug#811382: gosa: fails to install: ln: './bin': cannot overwrite directory

[Andreas Beckmann]

Package: gosa
Version: 2.7.4+reloaded2-7
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install. As
per definition of the release team this makes the package too buggy for
a release, thus the severity.

>From the attached log (scroll to the bottom...):

  Selecting previously unselected package gosa.
  (Reading database ... 
(Reading database ... 12111 files and directories currently installed.)
  Preparing to unpack .../gosa_2.7.4+reloaded2-7_all.deb ...
  Unpacking gosa (2.7.4+reloaded2-7) ...
  Setting up gosa (2.7.4+reloaded2-7) ...
  Making /gosa available in /etc/apache2/conf-available
  apache2_invoke: Enable configuration gosa
  Running in chroot, ignoring request.
  invoke-rc.d: policy-rc.d denied execution of reload.
  apache2_invoke: Enable module headers
  Running in chroot, ignoring request.
  invoke-rc.d: policy-rc.d denied execution of restart.
  Running in chroot, ignoring request.
  invoke-rc.d: policy-rc.d denied execution of reload.
  ln: './bin': cannot overwrite directory
  dpkg: error processing package gosa (--configure):
   subprocess installed post-installation script returned error exit status 1
  Errors were encountered while processing:
   gosa


cheers,

Andreas


gosa_2.7.4+reloaded2-7.log.gz
Description: application/gzip

Bug#811347: newer 1.3.2 debian package available for review

[Chris Knadle]

Hey, Tino.

Thanks for your quick response.

Tino Mettler:
> On Mon, Jan 18, 2016 at 07:02:32 +, Chris Knadle wrote:
>> Package: xca
>> Version: 1.0.0-2.1
>> Severity: wishlist
>>
>> Greetings Tino.
>>
>> I've put together a newer 1.3.2 version of xca and uploaded it to
>> mentors.debian.net for review:
>>
>>http://mentors.debian.net/package/xca
>>
>> This package would close #706539 and also adds a patch for adding back
>> CPPLFAGS dpkg-buildflags to Rules.mak which otherwise resets CPPFLAGS.
>>
>> It would be great if you could take a look.  I'm also willing to further
>> collaborate on the xca package if you're interested.
> 
> Hi,
> 
> first, thanks for your work on the xca package, as I'm too lazy to do
> it obviously. :-)

Heh.  Or you have other priorities.  ;-)

> I already prepared a new package for 1.3.1 which included major changes
> to debian/rules, but found an issue regarding certificate request
> generation. I was disturbed by real life too often to finalize the
> package after upstream released 1.3.2 with a fix for this. You can have
> a look on the 1.3.1 package here:
> 
> http://tikei.de/debian/xca/xca_1.3.1-1.dsc

Okay I had a quick look -- yep a change to dh in debian/rules is nice.

However you'll find the 'CF' environment variable that was used in xca-1.0.0
isn't used anymore, and 'prefix' now seems to be set via a --prefix option
to configure rather than as an environment variable.

After encapsulating CPPFLAGS in quotes ["$(CPPFLAGS)"] like the
xca-1.0.0-2.1 NMU (otherwise the build quickly fails) the 1.3.1-1 package
then fails to build with the following error:

---
In file included from imgres.cpp:9:0:
imgres.cpp:8799:44: warning: 'qInitResources__init_variable__' defined but
not used [-Wunused-variable]
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
^
/usr/include/qt4/QtCore/qglobal.h:941:21: note: in definition of macro
'Q_CONSTRUCTOR_FUNCTION0'
static const int AFUNC ## __init_variable__ = AFUNC();
 ^
imgres.cpp:8799:1: note: in expansion of macro 'Q_CONSTRUCTOR_FUNCTION'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
 ^
imgres.cpp:8799:24: note: in expansion of macro 'QT_MANGLE_NAMESPACE'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
^
---

I got something very similar when trying to call qmake-qt4 in the
debian/rules when working on the xca-1.3.2 package, but I don't see a call
to qmake-qt4 in the 1.3.1-1 package so I'm not sure what's causing this.

> I'll try to release a 1.3.2 package during the next few days.

Okay.  In the meantime I'll try to incorporate the work you've done to
switch to 'dh' to xca-1.3.2-0.1.  ;-)

Thanks much
   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#811373: python-stem: please restore tor-prompt as an executable

[Dererk]

tags 811373 +confirmed +pending
thanks

On 18/01/16 09:02, Jérémy Bobbio wrote:
> Source: python-stem
> Version: 1.3.0-1
> Severity: wishlist
>
> Hi!
>
> With the upload of python-stem/1.3.0-1, tor-prompt has been moved away
> from the standard PATH. In Jessie, typing “tor-prompt” works just fine.
>
> I don't see a reason why it cannot be provided as part of either
> python3-stem or a dedicated tor-prompt package. In any cases, a NEWS
> file to warn users of the change is probably required.
>
> Thanks!
Hi Jeremy!

You're absolutely right. This seems to have been introduced by an NMU
and I went ahead and move it away.

Should be fixed now on the queue.

Thanks for the heads-up!


Cheers,

Dererk

-- 
BOFH excuse #449:
greenpeace free'd the mallocs




signature.asc
Description: OpenPGP digital signature

Bug#811315: getdns: FTBFS[kfreebsd]: needs getentropy implementation

[Steven Chamberlain]

Hi Guillem,

Guillem Jover wrote:
> Steven Chamberlain wrote:
> > getdns FTBFS on kfreebsd because it lacks a getentropy implementation
> > for the FreeBSD kernel.  But there is one already in LibreSSL Portable
> > we can use, and works fine here.
> 
> BTW, libbsd has also a getentropy(3) implementation (lifted too from
> LibreSSL), which is currently not exposed but if people want to use it
> I could make it public, instead of embedding this in all sorts of
> places. The difference being that libbsd is already in Debian, while
> LibreSSL is not.
> 
>   

I'm really glad you asked about this.  The number of projects embedding
arc4random implementations, copied from OpenBSD or OpenSSH/LibreSSL
Portable has me worried.  I wanted to raise this with the security team,
I may follow up on debian-devel shortly.

I think the only use case for getentropy is arc4random, so perhaps don't
export getentropy(3), but lets try to standardise on one implementation
of arc4random (in libbsd?) and try to get more people using that?

It would be nice to have the kernel-specific parts (getentropy) confined
to libbsd, and that may become even more important if applications start
sandboxing (e.g. can't read /dev/urandom any more, have to use sysctls).
Or if getrandom(2) becomes standard, we'd only need to implement it in
one place (as a supplement / eventual replacement to getentropy(3)).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[Thomas Schmitt]

Hi,

Michal Suchanek wrote:
> -eltorito-alt-boot is not documented option of xorriso.

You need to look into man xorrisofs for the options of the -as mkisofs
emulation.

 -eltorito-alt-boot
  Finalize the current El Torito boot catalog entry  and  begin  a
  new  one.  A boot image file and all its necessary options shall
  be specified before option -eltorito-alt-boot.  All  further  El
  Torito  boot  options  apply  to the new catalog entry. Up to 32
  catalog entries are possible.


> So any bootloader is made primary by leaving out -eltorito-alt-boot.

There is no "primary" or "secondary" on the level of boot images
and loaders. (Of course you may call them this way in your project.)

There are first, second, third ... El Torito boot images or MBR, GPT,
APM partition entries.
The sequence is just needed because not all can be first in the list.

The boot firmware inspects the medium for its known lures,
picks a tasty one, and follows it to the boot loader or kernel.


> You can probably use only one legacy bootloader but syslinux-efi and
> grub-efi use different files so it should be possible to install both.
> I am not sure how selecting one or the other would work, though.

You can offer several EL Torito boot images for BIOS, indeed.
It will depend on your BIOS what it does in this case.

There can be only one MBR, though. So you would have to hop
by MBR x86 code to a standalone program which chooses among
the BIOS suitable El Torito boot images.

With EFI it makes few sense to offer more than one El Torito
boot image or EFI System Partition. UEFI 2.4 rather prescribes to
handle all alternatives inside the FAT filesystem. The firmware
will start the \EFI\BOOT\BOOT*.EFI binary which it deems suitable
for its processor type.
This binary is quite free in its further proceedings.


Have a nice day :)

Thomas

Bug#811347: newer 1.3.2 debian package available for review

[Tino Mettler]

On Mon, Jan 18, 2016 at 07:02:32 +, Chris Knadle wrote:
> Package: xca
> Version: 1.0.0-2.1
> Severity: wishlist
> 
> Greetings Tino.
> 
> I've put together a newer 1.3.2 version of xca and uploaded it to
> mentors.debian.net for review:
> 
>http://mentors.debian.net/package/xca
> 
> This package would close #706539 and also adds a patch for adding back
> CPPLFAGS dpkg-buildflags to Rules.mak which otherwise resets CPPFLAGS.
> 
> It would be great if you could take a look.  I'm also willing to further
> collaborate on the xca package if you're interested.

Hi,

first, thanks for your work on the xca package, as I'm too lazy to do
it obviously. :-)

I already prepared a new package for 1.3.1 which included major changes
to debian/rules, but found an issue regarding certificate request
generation. I was disturbed by real life too often to finalize the
package after upstream released 1.3.2 with a fix for this. You can have
a look on the 1.3.1 package here:

http://tikei.de/debian/xca/xca_1.3.1-1.dsc

I'll try to release a 1.3.2 package during the next few days.

Regards,
Tino

Bug#748490: Ping? Any update on mongodb 2.6 packaging?

[Apollon Oikonomopoulos]

Hi all,

As far as the MongoDB 2.4 to 2.6 transition goes, it is supported 
upstream[1] as a "binary-compatible “drop-in” upgrade" and 
application-side compatibility can be checked in advance by running
db.upgradeCheckAllDBs() on a 2.6 client connected to the 2.4 server. In 
that respect, the transition is far less of a problem than the 
2.0-to-2.4 transition needed for a Wheezy to Jessie upgrade. That said, 
I'm in favor of uploading 2.6 to unstable using the mongodb source name 
(and not mongodb-2.6) and then providing a Jessie backport.

Since we are in the process of upgrading to MongoDB 2.6 at work, I've 
rolled out a 2.6.11 package, trying to benefit from the changes done 
both in Ubuntu and László's updated package. For anyone interested, the 
source (signed with my DD key) is at

  https://dmesg.gr/packages/mongodb_2.6.11-0.1.dsc

I've cleaned up the patches, and done some packaging overhaul, including 
making hardened buildflags work. The changelog since 2.4.14-3 lists 
every change done, although some attribution may be missing (apologies 
for that). I've already tested the clients on our infrastructure, and we 
will start rolling out the server package soon on Jessie.

Regards,
Apollon

[1] https://docs.mongodb.org/manual/release-notes/2.6-upgrade/


signature.asc
Description: PGP signature

Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package

[Stefan Ahlers]

Dear mentors,

after the first review of my draft of the tomahawk-player package, I
discussed the problem with the developers of the player and I commented
all point of the review. Unfortunately, I didn't get any further
response and so I really do not know what to do next.

Because of this circumstance, I ask you to help me to solve the licence
and third-party issues. I want to bring tomahawk-player to debian but at
the moment, I do not know how.

Kind regards,
Stefan Ahlers

Bug#807763: Looking for help to solve licence and third-party issues of the tomahawk-player package

[Gianfranco Costamagna]

Hi,

>after the first review of my draft of the tomahawk-player package, I
>discussed the problem with the developers of the player and I commented
>all point of the review. Unfortunately, I didn't get any further
>response and so I really do not know what to do next.
>
>Because of this circumstance, I ask you to help me to solve the licence
>and third-party issues. I want to bring tomahawk-player to debian but at
>the moment, I do not know how.


please ping me when the jreen is accepted, I'll go in a new review spin.
BTW, are clementine images the same as the tomahawk-player has?
so in this case if clementine is accepted and in Debian I think the images
are DFSG.
please point to the sources, and look if the copyright shows them.
http://metadata.ftp-master.debian.org/changelogs/main/c/clementine/unstable_copyright

We might even end up in an RC bug against clementine :)

cheers,

G.

Bug#811385: adplay: ftbfs with gcc-6

[Trevor Saunders]

Package: adplay
Severity: normal
Tags: upstream
Usertags: ftbfs-gcc-6

Dear Maintainer,

adplay fails to build with gcc 6 because adplay.cc:92 tries to
initialize cfg.subsong which is an unsigned int with -1 which is invalid
in C++11.

The error from gcc is:

adplay.cc:98:1: error: narrowing conversion of '-1' from 'int' to
'unsigned int' inside { } [-Wnarrowing]
 };
  ^

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

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

Bug#811387: RM: php-math-biginteger/1.0.2-2

[Mattia Rizzolo]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: rm

php-math-biginteger is kept in testing because of php-horde-mapi which
depends on it.

though php-seclib (from src:phpseclib) has a (versioned) Provides for
it.

So I think this is going to need a manual hint to be removed.

See also:
https://release.debian.org/transitions/html/auto-php-math-biginteger-rm.html
https://bugs.debian.org/811360

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#811347: newer 1.3.2 debian package available for review

[Chris Knadle]

Chris Knadle:
[...]
> After encapsulating CPPFLAGS in quotes ["$(CPPFLAGS)"] like the
> xca-1.0.0-2.1 NMU (otherwise the build quickly fails) the 1.3.1-1 package
> then fails to build with the following error:

Edit: the actual build failure looks like it might be lack of finding a
crypto library:

---
In file included from imgres.cpp:9:0:
imgres.cpp:8799:44: warning: 'qInitResources__init_variable__' defined but
not used [-Wunused-variab
le]
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
^
/usr/include/qt4/QtCore/qglobal.h:941:21: note: in definition of macro
'Q_CONSTRUCTOR_FUNCTION0'
static const int AFUNC ## __init_variable__ = AFUNC();
 ^
imgres.cpp:8799:1: note: in expansion of macro 'Q_CONSTRUCTOR_FUNCTION'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
 ^
imgres.cpp:8799:24: note: in expansion of macro 'QT_MANGLE_NAMESPACE'
 Q_CONSTRUCTOR_FUNCTION(QT_MANGLE_NAMESPACE(qInitResources))
^
for i in  /build/xca-1.3.1/img/imgres.o; do echo $i; done > .build-stamp
make[3]: Leaving directory '/build/xca-1.3.1/img'
mkdir -p misc
make -C misc -f /build/xca-1.3.1/misc/Makefile \
VPATH=/build/xca-1.3.1/misc
make[3]: Entering directory '/build/xca-1.3.1/misc'
for i in ; do echo $i; done > .build-stamp
make[3]: Leaving directory '/build/xca-1.3.1/misc'
g++ -DXCA_PREFIX=\"/usr/share/xca\" -DETC=\"/etc\"
-DDOCDIR=\"/usr/share/doc/xca\" -g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -DQT_SHARED -I/usr/include/qt4
-I/usr/include/qt4/QtGui -I/usr/include/qt4 -I/usr/include/qt4/QtCore -Wall
-Wextra -O2 -Wl,-z,relro @lib/.build-stamp @widgets/.build-stamp
@img/.build-stamp @misc/.build-stamp -lltdl  -lcrypto-lQtGui -lQtCore -o xca
/usr/bin/ld: cannot find -lcrypto-lQtGui
collect2: error: ld returned 1 exit status
Makefile:68: recipe for target 'xca' failed
make[2]: *** [xca] Error 1
make[2]: Leaving directory '/build/xca-1.3.1'
dh_auto_build: make -j1 all returned exit code 2
debian/rules:14: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/build/xca-1.3.1'
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
---

   -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#811392: tahoe-lafs: fails to run

[guido]

Package: tahoe-lafs
Version: 1.10.2-2
Severity: grave
Justification: renders package unusable

Dear Maintainer,

   * What led up to the situation?

Installed tahoe-lafs using apt-get, the process went without any issues but 
when trying to launch it it and dropped the following error

Traceback (most recent call last):
  File "/usr/bin/tahoe", line 3, in 
from allmydata.scripts import runner
  File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line 386, in 

_vers_and_locs_list, _cross_check_errors = 
get_package_versions_and_locations()
  File "/usr/lib/python2.7/dist-packages/allmydata/__init__.py", line 256, in 
get_package_versions_and_locations
for p in pkg_resources.require(install_requires)])
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 962, 
in require
needed = self.resolve(parse_requirements(requirements))
  File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 849, 
in resolve
raise DistributionNotFound(req, requirers)
pkg_resources.DistributionNotFound: The 'twisted-web>=2.5.0' distribution was 
not found and is required by foolscap

Thanks for your work!



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

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

Versions of packages tahoe-lafs depends on:
ii  net-tools1.60+git20150829.73cef8a-2
ii  python   2.7.11-1
ii  python-cffi  1.4.2-2
ii  python-characteristic14.3.0-1
ii  python-crypto2.6.1-6
ii  python-cryptography  1.1.1-1
ii  python-enum341.0.4-3
ii  python-foolscap  0.8.0-1
ii  python-nevow 0.11.1-2
ii  python-openssl   0.15.1-2
ii  python-pkg-resources 18.8-1
ii  python-pyasn10.1.9-1
ii  python-pyasn1-modules0.0.7-0.1
ii  python-pycparser 2.14+dfsg-2
ii  python-pycryptopp0.6.0.20120313-1+b1
ii  python-service-identity  14.0.0-1
ii  python-setuptools18.8-1
ii  python-simplejson3.8.1-1
ii  python-six   1.10.0-1
ii  python-twisted   15.5.0-4
ii  python-zfec  1.4.5-2
ii  python-zope.interface4.1.3-1
pn  python:any   

tahoe-lafs recommends no packages.

tahoe-lafs suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#748490: Ping? Any update on mongodb 2.6 packaging?

[GCS]

Hi,

On Mon, Jan 18, 2016 at 1:29 PM, Apollon Oikonomopoulos
 wrote:
> As far as the MongoDB 2.4 to 2.6 transition goes, it is supported
> upstream[1] as a "binary-compatible “drop-in” upgrade" and
> application-side compatibility can be checked in advance by running
> db.upgradeCheckAllDBs() on a 2.6 client connected to the 2.4 server. In
> that respect, the transition is far less of a problem than the
> 2.0-to-2.4 transition needed for a Wheezy to Jessie upgrade. That said,
> I'm in favor of uploading 2.6 to unstable using the mongodb source name
> (and not mongodb-2.6) and then providing a Jessie backport.
 The Wheezy -> Jessie path missed the 2.2 version and providing
mongodb-version package names helps to avoid this.
But sure, let the names remain as-is.

> Since we are in the process of upgrading to MongoDB 2.6 at work, I've
> rolled out a 2.6.11 package, trying to benefit from the changes done
> both in Ubuntu and László's updated package.
 May you share your experience? Any manual interaction was needed?

> I've already tested the clients on our infrastructure, and we
> will start rolling out the server package soon on Jessie.
 Please keep us posted.

Thanks,
Laszlo/GCS

Bug#811393: RFS: flint -- C library for arbitrary-precision ball arithmetic

[Julien Puydt]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I'm looking for a sponsor for a new package:

* Package name: arb
  Version : 2.8.1
  Upstream Author : Fredrik Johansson
* URL : https://github.com/fredrik-johansson/arb
* License : GPL-2+
  Programming Lang: C
  Description : C library for arbitrary-precision floating-point 
ball arithmetic


Arb is a C library for high-performance arbitrary-precision 
floating-point ball (mid-rad interval) arithmetic. It supports complex 
numbers, polynomials, matrices, and evaluation of special functions, all 
with rigorous error bounding.


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


  http://mentors.debian.net/package/flint-arb


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

dget -x 
http://mentors.debian.net/debian/pool/main/f/flint-arb/flint-arb_2.8.1-1.dsc


I plan to maintain this package as part of the debian-science team:
Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=debian-science/packages/arb.git

Vcs-Git: git://anonscm.debian.org/debian-science/packages/arb

Thanks,

Snark on #debian-science

Bug#809956: matplotlib: FTBFS with libpng16

[Sandro Tosi]

Hey Tobias,

> those rebuilts!) - I'm preparing a new release of matplotlib where I
> disabled the PDF build (which is the one using the latex sphinx
> backend), so this bug should be "implicitly" fixed by that

a new release of mpl has been uploaded to sid and it builds on all the
release archs: https://buildd.debian.org/status/package.php?p=matplotlib
- I guess this bug can be closed or do you want to re-test the latest
version in your build env?

-- 
Sandro "morph" Tosi
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#811395: jessie-pu: package ardour/1:2.8.16+git20131003-4

[Sebastian Ramacher]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

I'd like to update ardour to fix #810754 in jessie. libs/pbd/dmalloc.c has a
commercial restriction, but can safely be removed. The attached debdiff does
that. That changelog is:

ardour (1:2.8.16+git20131003+dfsg1-1~deb8u1) jessie; urgency=medium

  * Repack to remove libs/pdb/dmalloc.cc. (Closes: #810754)
  * debian/patches/debian/patches/190_exclude_dmalloc.patch: Do not build
dmalloc.cc.
  * debian/copyright:
- Add libs/pdb/dmalloc.cc to Files-Excluded.
- Remove libs/pdb/dmalloc.cc paragraph.

 -- Sebastian Ramacher   Mon, 18 Jan 2016 16:10:25 +0100

Cheers
-- 
Sebastian Ramacher
diff --git a/debian/changelog b/debian/changelog
index 0f30581..749f61a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+ardour (1:2.8.16+git20131003+dfsg1-1~deb8u1) jessie; urgency=medium
+
+  * Repack to remove libs/pdb/dmalloc.cc. (Closes: #810754)
+  * debian/patches/debian/patches/190_exclude_dmalloc.patch: Do not build
+dmalloc.cc.
+  * debian/copyright:
+- Add libs/pdb/dmalloc.cc to Files-Excluded.
+- Remove libs/pdb/dmalloc.cc paragraph.
+
+ -- Sebastian Ramacher   Mon, 18 Jan 2016 16:10:25 +0100
+
 ardour (1:2.8.16+git20131003-4) unstable; urgency=medium
 
   * Upload to unstable.
diff --git a/debian/copyright b/debian/copyright
index 7862a79..f11f5ca 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -3,6 +3,7 @@ Upstream-Name: Ardour
 Upstream-Contact: Paul Davis 
 Source: http://ardour.org/download
 Copyright: 1998-2010, Paul Davis
+Files-Excluded: libs/pbd/dmalloc.cc
 
 Files: *
 Copyright: 1998-2010, Paul Davis
@@ -456,10 +457,6 @@ Files: ./libs/vamp-plugins/AmplitudeFollower.cpp
 Copyright: 2006, Dan Stowell
 License: Expat and other-nopromo-Chris
 
-Files: ./libs/pbd/dmalloc.cc
-Copyright: 1995, Gray Watson
-License: other-noncommercial-Watson
-
 Files: ./libs/surfaces/powermate/interface.cc
 Copyright: Harrison Audio, LLC, 2007
 License: UNKNOWN
@@ -615,14 +612,6 @@ License: other-Apple
  STRICT LIABILITY OR OTHERWISE, EVEN IF APPLE HAS BEEN ADVISED OF THE
  POSSIBILITY OF SUCH DAMAGE.
 
-License: other-noncommercial-Watson
- Permission to use, copy, modify, and distribute this software for any
- NON-COMMERCIAL purpose and without fee is hereby granted, provided that
- the above copyright notice and this permission notice appear in all
- copies, and that the name of Gray Watson not be used in advertising or
- publicity pertaining to distribution of the document or software
- without specific, written prior permission.
-
 License: GPL
  This program is free software; you can redistribute it and/or modify it
  under the terms of the GNU General Public License as published by the
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 059dcc5..27d917c 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -3,6 +3,8 @@
 [DEFAULT]
 pristine-tar = True
 sign-tags = True
+debian-branch = jessie
+upstream-branch = upstream.jessie
 
 [git-buildpackage]
 compression = bzip2
diff --git a/debian/patches/190_exclude_dmalloc.patch 
b/debian/patches/190_exclude_dmalloc.patch
new file mode 100644
index 000..388aa06
--- /dev/null
+++ b/debian/patches/190_exclude_dmalloc.patch
@@ -0,0 +1,14 @@
+Description: Exclude dmalloc.cc from building
+Author: Sebastian Ramacher 
+Bug-Debian: https://bugs.debian.org/810754
+
+--- ardour-2.8.16+git20131003.orig/libs/pbd/SConscript
 ardour-2.8.16+git20131003/libs/pbd/SConscript
+@@ -25,7 +25,6 @@ convert.cc
+ copyfile.cc
+ controllable.cc
+ enumwriter.cc
+-dmalloc.cc
+ epa.cc
+ error.cc
+ file_subst.cc
diff --git a/debian/patches/series b/debian/patches/series
index 6fa4858..1243ca3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@
 160_kfreebsd.patch
 170_template-ftbfs.patch
 180_aubio.patch
+190_exclude_dmalloc.patch
diff --git a/libs/pbd/dmalloc.cc b/libs/pbd/dmalloc.cc
deleted file mode 100644
index 0e73094..000
--- a/libs/pbd/dmalloc.cc
+++ /dev/null
@@ -1,102 +0,0 @@
-/*
- * file that facilitates C++ program debugging.
- *
- * Copyright 1995 by Gray Watson
- *
- * This file is part of the dmalloc package.
- *
- * Permission to use, copy, modify, and distribute this software for any
- * NON-COMMERCIAL purpose and without fee is hereby granted, provided
- * that the above copyright notice and this permission notice appear
- * in all copies, and that the name of Gray Watson not be used in
- * advertising or publicity pertaining to distribution of the document
- * or software without specific, written prior permission.
- *
- * Please see the PERMISSIONS file or contact the author for information
- * about commercial licenses.
- *
- * Gray Watson makes no representations about the suitability of the
- * software described herein for any purpose.  It is provided "as is"
- * without express or implied warranty.

Bug#811394: transition: libimobiledevice

[Andreas Beckmann]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Control: forwarded -1 
https://release.debian.org/transitions/html/auto-libimobiledevice.html

An uncoordinated transition for libimobiledevice4 -> libimobiledevice6
has been started some time ago, the new library has migrated to testing
already.

Once libimobiledevice is rebuilt against libusbmuxd4, binNMUs should be
started.

List or rdepends:

level 2:
  gvfs
  ideviceinstaller
  ifuse (not in testing, RC buggy)
  ipheth
  libgpod
  upower
  usbmuxd
level 3:
  clementine
  gtkpod

These packages already had sourceful uploads for unrelated reasons and
built successfully (according to ben):
  amarok
  digikam
  rhythmbox

This time I haven't tried to build anything, the maintainer should have
done this first ...

Ben file:

https://release.debian.org/transitions/html/auto-libimobiledevice.html
looks good.


Andreas

Bug#811384: texlive-fonts-extra: inconsolata: missing Euro sign

[Norbert Preining]

Hi Thorsten,

On Mon, 18 Jan 2016, Thorsten Glaser wrote:
> list of supported characters, but am having trouble with € (Euro sign).

Indeed, my test program 
\documentclass{article}
\usepackage[T1]{fontenc}
\usepackage[utf8]{inputenc}
\usepackage{zi4}
\begin{document}
\texttt{Hello World, 30€}
\end{document}
did not work either.

I am not sure if it is supposed to work, but please contact 
upup-stream Michael Sharpe about this, as this is not a Debian
specific problem but happens also in TeX Live, so it needs
to be fixed (or explained) by upupstream

Thanks.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0  ACF0 6CAC A448 860C DC13

Bug#811396: awscli: Erroneous dependency on python-botocore

[Dagfinn Ilmari Mannsåker]

Package: awscli
Version: 1.9.9-2
Severity: normal

The versioned dependency on botocore is declared on python-botocore,
which pulls in the Python 2.x version. It should be python3-botocore
instead.

-- System Information:
Debian Release: 8.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (300,
  'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages awscli depends on:
ii  python-botocore   1.3.9-1
ii  python3   3.4.2-2
ii  python3-botocore  1.3.9-1
ii  python3-colorama  0.3.2-1
ii  python3-docutils  0.12+dfsg-1
ii  python3-rsa   3.1.4-1
pn  python3:any   

awscli recommends no packages.

awscli suggests no packages.

-- no debconf information

-- 
"I use RMS as a guide in the same way that a boat captain would use
 a lighthouse.  It's good to know where it is, but you generally
 don't want to find yourself in the same spot." - Tollef Fog Heen

Bug#811397: isc-dhcp-server: Location of dhcpd.conf changed

[Stefan Baier]

Package: isc-dhcp-server
Version: 4.1.1-P1-15+squeeze9
Severity: normal

Hi maintainers,

after an automatic update of the isc-dhcp-server package from
squeeze-lts sources, the dhcp-Daemon does not start properly. The server
runs with Squeeze (6.0.10).

The reason is that the default Location of the Config-File moved from
/etc/dhcp/dhcpd.conf in Version 4.1.1-P1-15+squeeze8 to /etc/dhcpd.conf
in 4.1.1-P1-15+squeeze9.

Services which automatically start this daemon (like corosync)
would not work properly anymore.

It could be verified by checking the content of the dhcpd-File in the
appropriate *.deb Archives with:
# strings dhcpd | grep "dhcpd.conf"

My workaround is to set a softlink between old and new location.
# ln -s /etc/dhcp/dhcpd.conf /etc/dhcpd.conf


Kind regards,
Stefan

-- 
// Stefan Baier (M.Eng.), IT-System Ingenieur, +49385/30 200 372,
ba...@planet-ic.de
//
// IT- & Software-Systemhaus, Internet Service und Web Agentur
//
// PLANET IC GmbH, Mettenheimer Straße 9-15, 19061 Schwerin
// Registergericht Schwerin HRB 6762, Geschäftsführer Andreas Scher
// Telefon 0385 30200 200, Telefax 0385 30200 190, www.planet-ic.de



signature.asc
Description: OpenPGP digital signature

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

A quick update on my grub-efi work:

1) I have noticed I have missed to give execution permissions to many 
files when I rebased.


These are:
scripts/build/binary_grub-efi
scripts/build/binary_syslinux-efi
scripts/build/efi-image
scripts/build/grub-cpmodules

You can find additional commits to fix this situation on:
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
and
https://github.com/adrian15/live-build/commits/syslinux-efi-2016
.

(I will probably do another rebase in another branch in the future with 
other of your suggestions and these fixes.)



2) I have released Rescatux 0.40 beta 5 based on: 
https://github.com/adrian15/live-build/tree/rescatux-0.40b5 (The patches 
you have already seen + execution permissions fixed) . It is built by using:

--bootloaders="syslinux,grub-efi" .

You can find more information about it and download links on:

http://www.supergrubdisk.org/2016/01/18/rescatux-0-40-beta-5-released/

Remember that if you want to test it into a USB drive you need to do the 
'dd' if you want it to work ok and that means DESTROYING your data in 
the USB drive.



adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software 
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/

Bug#748490: Ping? Any update on mongodb 2.6 packaging?

[Apollon Oikonomopoulos]

On 15:09 Mon 18 Jan , László Böszörményi wrote:
> Hi,
> 
> On Mon, Jan 18, 2016 at 1:29 PM, Apollon Oikonomopoulos
>  wrote:
> > As far as the MongoDB 2.4 to 2.6 transition goes, it is supported
> > upstream[1] as a "binary-compatible “drop-in” upgrade" and
> > application-side compatibility can be checked in advance by running
> > db.upgradeCheckAllDBs() on a 2.6 client connected to the 2.4 server. In
> > that respect, the transition is far less of a problem than the
> > 2.0-to-2.4 transition needed for a Wheezy to Jessie upgrade. That said,
> > I'm in favor of uploading 2.6 to unstable using the mongodb source name
> > (and not mongodb-2.6) and then providing a Jessie backport.
>  The Wheezy -> Jessie path missed the 2.2 version and providing
> mongodb-version package names helps to avoid this.
> But sure, let the names remain as-is.

Unfortunately, there seems to be no easy solution for this problem.  
Since upstream only supports transitions between consecutive stable 
releases, Debian should really provide packages for all intermediate 
versions to facilitate upgrades. But yes, in the Wheezy -> Jessie case, 
using a different package name (although not source name), would at 
least guarantee that no automatic upgrades would take place.

> 
> > Since we are in the process of upgrading to MongoDB 2.6 at work, I've
> > rolled out a 2.6.11 package, trying to benefit from the changes done
> > both in Ubuntu and László's updated package.
>  May you share your experience? Any manual interaction was needed?

Sofar I've run db.upgradeCheckAllDBs() against one of our clusters with 
a 500 GB dataset and tens of millions of documents. All-in-all it 
emitted errors regarding mostly dots in field names (which has been a 
restriction since at least 2.2) and just 4 (!) key-too-long documents.  
I've seen RDBMS migrations that are much worse than this, plus at least 
now we can get a glimpse of what we should fix *before* actually 
upgrading the server :).

> > I've already tested the clients on our infrastructure, and we
> > will start rolling out the server package soon on Jessie.
>  Please keep us posted.

We will soon upgrade our development instances, so I will let you know.

Regards,
Apollon

Bug#811371: Acknowledgement (chromium: unwanted redirection in Chromium)

[R. Maddox]

I have found what was the problem:

Today I have seen that only when this extension is turned on, immediately, I 
get unwanted Chrome redirection.

I get unreasonable unwanted redirection to third party sites, and by using 
localhost server. Here is the log:

::1 - - [18/Jan/2016:16:01:17 +0100] "GET 
/protected/crm/cgi-bin/image.cgi?image=32469.jpg HTTP/1.1" 200 4043 
"http://localhost/protected/crm/index.cgi?action=runpearl=show_contact_update=Run+Report=list_contacts_id=32469;
 "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/47.0.2526.80 Safari/537.36"
::1 - - [18/Jan/2016:16:16:00 +0100] "GET /to.php?subid=16 HTTP/1.1" 404 496 
"http://www.free-merchants.com/partner/promokod_aliexpress-by-alibabacom; 
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/47.0.2526.80 Safari/537.36"
::1 - - [18/Jan/2016:16:16:00 +0100] "GET /protected/crm/index.cgi HTTP/1.1" 
200 5107 "http://localhost/to.php?subid=16; "Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36"
::1 - - [18/Jan/2016:16:16:06 +0100] "GET /protected/crm/index.cgi HTTP/1.1" 
200 5109 "http://localhost/protected/crm/index.cgi; "Mozilla/5.0 (X11; Linux 
x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 
Safari/537.36"
::1 - - [18/Jan/2016:16:16:12 +0100] "GET /to.php?subid=16 HTTP/1.1" 404 496 
"http://www.free-merchants.com/partner/promokod_aliexpress-by-alibabacom; 
"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/47.0.2526.80 Safari/537.36"
::1 - - [18/Jan/2016:16:16:12 +0100] "GET /protected/crm/index.cgi HTTP/1.1" 
200 5112 "http://localhost/to.php?subid=16; "Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36"

I have just now removed the extension.

There are no unwanted redirections any more.

Reported abuse to Google.

Bug#810534: borgbackup backport to jessie

[Antoine Beaupré]

On 2016-01-18 07:52:41, Danny Edel wrote:
> Hi Antoine,
>
> Now that borgbackup is clear to enter and stay in testing again, it may
> be time to revisit the backport to stable : )
>
> On 01/09/2016 04:57 PM, Antoine Beaupré wrote:
>> from what i understand, there are two dependencies that need to be
>> backported:
>> 
>>  * setuptools-scm: backported by Gianfranco already, but out of date
>>(1.8 backported vs 1.10 in stretch)
>
> I don't think that this is a showstopper.
>
> According to setup.py[1] borgbackup only requires 1.7 (this is mirrored
> to d/control Build-Depends), which is satisfied already in jessie-backports.
>
>
> [1]:
> https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/setup.py?id=dc168cf8cc7f50870dd1aca8c2329660a7017f4f#n260
>
>>  * python3-msgpack: backport missing. zigo contacted, said he would
>>backport himself. i'll open a bug report about this on msgpack to
>>track that
>
> Is there any news on this?  I tested a no-change-rebuild in a
> jessie-backports pbuilder (seemed to go fine, but I don't know how to
> correctly verify that), and was able to compile borgbackup with the
> resulting package.

The bug report is in:

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

no news from the other maintainer, i suggest you take it there...

make sure that borg really runs with the new msgpack, because there are
serious performance problems with the older one...

> Right now borgbackup-doc built this way has privacy breach (loads
> javascripts from external url when browsing local doc), which does not
> happen when building it on sid.
>
> Any thoughts?

I am not sure it's an issue that warrants blocking the backport - it's a
bug in the toolchain, not specific to borg, no?

a.
-- 
The secret of life is to have no fear; it's the only way to function.
- Stokely Carmichael

Bug#810535: python-msgpack: backport to jessie

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, I did ask on -backports, and seems it needs a new upload

[14:07:20]  hi, asking again: does anybody know what
happened to python-msgpack backport from zigo?
[14:11:24]  Hmm?  I don't see it in the pool and neither in
the NEW queue.  Was it uploaded?  The reject mails go to a special
mailinglist, did you check there?
[14:12:03]  Hmm, the reject mails don't seem to go to the
backports-changes mailinglist.
[14:12:28]  Ah, but to the regular debian-backports list :)
[14:13:02]  LocutusOfBorg: If you find anything there and it
doesn't enlighten you, give us a call.  If you don't find it there
rather ask zigo if it was uploaded at all.
[14:15:20]  I remember zigo told me he was uploaded,
and I remember I personally saw it on the new queue
[14:15:27] 
https://ftp-master.debian.org/backports-new.html
[14:15:29]  here I mean
[14:15:39]  this is why I'm asking here :)
[14:15:53]  I might have done a bad mistake, but I
remember it
[14:15:55]  no idea, I don't track every package in the NEW
queue
[14:16:08]  I'll go in the list
[14:16:14]  to check it
[14:16:21]  its either on the change list (if accepted) or
on the usual backports list (if rejected)
[14:16:31]  but there is nothing for december or january
[14:18:51]  I remember almost clearly that all the
openstack packages were uploaded in a row
[14:19:15]  I remember that pain too
[14:19:19] * LocutusOfBorg is searching
[14:21:54] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-12-28.log.html
[14:22:37]  and?
[14:22:48] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-12-17.log.html
[14:32:32]  here the request I did
[14:32:33] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-11-09.log.html
[14:32:39]  but nothing shown on mail lists
[14:32:52]  I just have my memory and zigo confirmation
[14:33:21] -BTS/#debian-backports-
nvidia-graphics-drivers-legacy-304xx 304.131-1~bpo70+1 uploaded to
wheezy-backports by Andreas Beckmann (anbe)
https://tracker.debian.org/nvidia-graphics-drivers-legacy-304xx
[14:33:29] -BTS/#debian-backports- nvidia-graphics-modules
340.96+3.16.0+1~bpo70+1 uploaded to wheezy-backports by Andreas
Beckmann (anbe) https://tracker.debian.org/nvidia-graphics-modules
[14:35:06]  LocutusOfBorg: we can't help you.
[14:43:35] * aborrero has quit (Remote host closed the connection)
[14:45:08]  I hope zigo will reupload :)
[14:45:26]  formorer, Rhonda thanks a lot for the pointer
s


I'll upload on delayed/7 a no change bpo and wait for zigo :)

cheers,

Gianfranco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWnQboAAoJEPNPCXROn13ZTacQALg6AaKD42QVL82pZJ7PWgt8
ycRycdOrtVw7RsSJg8vAUSwANvE077HSM1ZlLV/o3akwuPwkzckoNLFYNo57vee1
FF6KHhrKem2YM5zecz3KjPgJ//7EFmVrhSq7h6OdsCNcba7Lju9mFiAbajMLYW3G
JvcZt5oMBqnqm5Jg+QGhM6zl+Hwce15Cd5tPvX+bKCjxZ89Bx8kTWqOX6mKIf1fp
e3Myo0kLW+uL0QofIuwK3zEHV2mHmiBuATFp2R2T8krZfg1BT0Xkaq8h+2e2OyF9
pW2uvLNGVpcDGS76WwW4kyN4SdX17hcvbtjWOEQ9p/54UFsOM4jG1w24/ieV+xU/
smFC557YDUSOuvPK1U+4X9N/0BX43HLev4zj4wlKZztc0VtRq7xaCZO9UmbqjSeY
nCphsh26/O9IhAsE+/7LSAPlPw2altY3cRDAN/5el3dG+YiHxqLTRxYcrmazaDWX
kaYCRD5QaFFnBAM3+FVwAPIHvigqKoByEk0RC2ALcfQBa7GHqwOwU2hppE5jloSG
fm6If5CWV7/3AeA81qoKxEF5DvNjD5zGcIxyOqoBgJwltc+GchQ9IZez1ukBTmfm
oqG+kk+0Arolk4LCIME4tRCkCLZ7JFnh9ekHXO99HHYxunEXc9A+oIxO7Rhp5kIf
f/GPR46WQvUDV6f62kcW
=nnMj
-END PGP SIGNATURE-

Bug#811341: ufoai-server: fails to remove: update-rc.d: error: cannot find a LSB script for ufoai-server

[Markus Koschany]

Control: tags -1 moreinfo

Am 18.01.2016 um 04:05 schrieb Andreas Beckmann:
> Package: ufoai-server
> Version: 2.5-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to remove.
> 
>>From the attached log (scroll to the bottom...):
> 
>   Removing ufoai-server (2.5-1) ...
>   update-rc.d: error: cannot find a LSB script for ufoai-server
>   dpkg: error processing package ufoai-server (--remove):
>subprocess installed post-removal script returned error exit status 1


Hi,

I tried to reproduce this error but on my system the installation and
removal of ufoai-server works as expected. Could you elaborate on your
system configuration? I assume you ran piuparts on a non-systemd system?
Do I have to provide an init script even if ufoai-server fails to build
from source on architectures that don't support systemd?

Regards,

Markus






signature.asc
Description: OpenPGP digital signature

Bug#810535: python-msgpack: backport to jessie

[Gianfranco Costamagna]

control: tags -1 patch
control: tags -1 pending

Hi, this is the patch for changelog
+msgpack-python (0.4.6-1~bpo8+1) jessie-backports; urgency=medium
+
+  * Rebuild for jessie-backports.
+
+ -- Gianfranco Costamagna   Mon, 18 Jan 2016 
16:38:44 +0100
+

I didn't change anything else
(I just did a dch --bpo)


cheers,

Gianfranco



Il Lunedì 18 Gennaio 2016 16:42, Gianfranco Costamagna 
 ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi, I did ask on -backports, and seems it needs a new upload

[14:07:20]  hi, asking again: does anybody know what
happened to python-msgpack backport from zigo?
[14:11:24]  Hmm?  I don't see it in the pool and neither in
the NEW queue.  Was it uploaded?  The reject mails go to a special
mailinglist, did you check there?
[14:12:03]  Hmm, the reject mails don't seem to go to the
backports-changes mailinglist.
[14:12:28]  Ah, but to the regular debian-backports list :)
[14:13:02]  LocutusOfBorg: If you find anything there and it
doesn't enlighten you, give us a call.  If you don't find it there
rather ask zigo if it was uploaded at all.
[14:15:20]  I remember zigo told me he was uploaded,
and I remember I personally saw it on the new queue
[14:15:27] 
https://ftp-master.debian.org/backports-new.html
[14:15:29]  here I mean
[14:15:39]  this is why I'm asking here :)
[14:15:53]  I might have done a bad mistake, but I
remember it
[14:15:55]  no idea, I don't track every package in the NEW
queue
[14:16:08]  I'll go in the list
[14:16:14]  to check it
[14:16:21]  its either on the change list (if accepted) or
on the usual backports list (if rejected)
[14:16:31]  but there is nothing for december or january
[14:18:51]  I remember almost clearly that all the
openstack packages were uploaded in a row
[14:19:15]  I remember that pain too
[14:19:19] * LocutusOfBorg is searching
[14:21:54] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-12-28.log.html
[14:22:37]  and?
[14:22:48] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-12-17.log.html
[14:32:32]  here the request I did
[14:32:33] 
http://irc.mapreri.org/logs/oftc/%23debian-python/2015/%23debian-python_
2015-11-09.log.html
[14:32:39]  but nothing shown on mail lists
[14:32:52]  I just have my memory and zigo confirmation
[14:33:21] -BTS/#debian-backports-
nvidia-graphics-drivers-legacy-304xx 304.131-1~bpo70+1 uploaded to
wheezy-backports by Andreas Beckmann (anbe)
https://tracker.debian.org/nvidia-graphics-drivers-legacy-304xx
[14:33:29] -BTS/#debian-backports- nvidia-graphics-modules
340.96+3.16.0+1~bpo70+1 uploaded to wheezy-backports by Andreas
Beckmann (anbe) https://tracker.debian.org/nvidia-graphics-modules
[14:35:06]  LocutusOfBorg: we can't help you.
[14:43:35] * aborrero has quit (Remote host closed the connection)
[14:45:08]  I hope zigo will reupload :)
[14:45:26]  formorer, Rhonda thanks a lot for the pointer
s


I'll upload on delayed/7 a no change bpo and wait for zigo :)

cheers,

Gianfranco
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWnQboAAoJEPNPCXROn13ZTacQALg6AaKD42QVL82pZJ7PWgt8
ycRycdOrtVw7RsSJg8vAUSwANvE077HSM1ZlLV/o3akwuPwkzckoNLFYNo57vee1
FF6KHhrKem2YM5zecz3KjPgJ//7EFmVrhSq7h6OdsCNcba7Lju9mFiAbajMLYW3G
JvcZt5oMBqnqm5Jg+QGhM6zl+Hwce15Cd5tPvX+bKCjxZ89Bx8kTWqOX6mKIf1fp
e3Myo0kLW+uL0QofIuwK3zEHV2mHmiBuATFp2R2T8krZfg1BT0Xkaq8h+2e2OyF9
pW2uvLNGVpcDGS76WwW4kyN4SdX17hcvbtjWOEQ9p/54UFsOM4jG1w24/ieV+xU/
smFC557YDUSOuvPK1U+4X9N/0BX43HLev4zj4wlKZztc0VtRq7xaCZO9UmbqjSeY
nCphsh26/O9IhAsE+/7LSAPlPw2altY3cRDAN/5el3dG+YiHxqLTRxYcrmazaDWX
kaYCRD5QaFFnBAM3+FVwAPIHvigqKoByEk0RC2ALcfQBa7GHqwOwU2hppE5jloSG
fm6If5CWV7/3AeA81qoKxEF5DvNjD5zGcIxyOqoBgJwltc+GchQ9IZez1ukBTmfm
oqG+kk+0Arolk4LCIME4tRCkCLZ7JFnh9ekHXO99HHYxunEXc9A+oIxO7Rhp5kIf
f/GPR46WQvUDV6f62kcW
=nnMj
-END PGP SIGNATURE-

-- 
To unsubscribe, send mail to 810535-unsubscr...@bugs.debian.org.

Bug#811398: ITP: ruby-interception -- Provides a cross-platform ability to intercept all exceptions as they are raised.

[Hanno Zulla]

Package: wnpp
Severity: wishlist
Owner: Hanno Zulla 

* Package name: ruby-interception
  Version : 0.5
  Upstream Author : Conrad Irwin
* URL : https://rubygems.org/gems/interception
* License : MIT
  Programming Lang: Ruby
  Description : Provides a cross-platform ability to intercept all 
exceptions as they are raised.

Packaging as dependency of Sonic Pi (ITP #796550)

Bug#811376: texlive-fonts-extra: Missing dependency on fonts-inconsolata

[Vincent Lefevre]

Hi Norbert,

On 2016-01-19 00:09:24 +0900, Norbert Preining wrote:
> Hi Vincent,
> 
> > As documented, texlive-fonts-extra intends to provide the inconsolata
> > font, but it no longer depends on fonts-inconsolata:
> 
> Intended. The fonts shipped in the inconsolata TeX package are
> slightly modified to provide further glyphs, and thus the fonts
> are included and the texlive packages do not need to depend
> on fonts-inconsolata anymore: See
>   /usr/share/texlive/texmf-dist/fonts/opentype/public/inconsolata/

This was a bit confusing because usually, the fonts are also available
for the system (e.g. "fc-match Inconsolata"), and this is no longer
the case for Inconsolata (unless the package is re-added manually).

Also note that the current fonts-inconsolata package provides a
test file /usr/share/doc/fonts-inconsolata/textest.pdf.gz, which
I assume that it was built with TeX, and this could also lead to
some confusion because one now has two Inconsolata fonts that may
not match.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#810822: ITP: MooseFS

[Dmitry Smirnov]

On Mon, 18 Jan 2016 07:12:04 AM Jakub Kruszona-Zawadzki wrote:
> We may make official clone of GPL'ed version on GitHub if it change
> anything.

I'm sure it would be very helpful in long term.


> 99.9% of my time I spend on GPL'ed version. Now there is
> only one feature in PRO version that is not available in GPL version. We
> do not plan to change that (maybe in the future exchange this feature to
> another).

Fair enough. Thank you for explanation.


> > Debian already have MooseFS' fork -- LizardFS. To my knowledge at the
> > moment MooseFS do not offer noticeable advantages over LizardFS while
> > the latter seems to have slightly more features.
> 
> You are very wrong. We have users who switched from LizardFS. Stability,
> efficiency for example. Quite important advantages. Not for everyone, but
> at least for serious users.

I understand your passion for MooseFS but I am not convinced.


> > For quite a while LizardFS is developed with community using public VCS
> > and bug tracker (GitHub) as well as Gerrit code review system and
> > continuous integration system. LizardFS have more development
> > transparency than MooseFS ever had.
> 
> And in case of file system it is not good idea.
 
Strongly disagreed. Transparency is very important. Code review is important. 
VCS is useful. Continuous integration helps to test every change. Community 
are those who are interested to help improving your product and share 
experience so you won't end up alone. Neglecting all those won't get you 
anywhere...


> > Please note that IMHO MooseFS versus LizardFS situation have many
> > similarities with MySQL vs. MariaDB situation where poor Oracle's
> > governance and focus on proprietary addons discourage community from
> > working with them. (MySQL is not as bad as MooseFS because MySQL have
> > public bug tracker).
> You are not right. MariaDB is developed by original author of MySQL, so the
> spirit of MySQL now is in MariaDB.

I'm talking about pragmatic backporting of bugfixes not abstract "spirit of 
MySQL" or fan club of the original founder.


> I invented MooseFS and I'm still developing MooseFS.

I can't thank you enough for your great work. Thank you sincerely for the 
amazing job you have done.


> Also in terms of
> money. We do not make money on MooseFS. The PRO version is just for us to
> help developing it at all. Let's say that thanks to pro version of MooseFS
> we are able to make GPL version of MooseFS. Thanks to that I'm able to
> work 8 hours a day developing MooseFS, so we made PRO version to actually
> improve developing of GPL version.

Fair enough.


> > As I object to introduction of MooseFS to Debian I would object to
> > introduction of MySQL if MariaDB were already available.
> 
> Why? People should have right to choose.

I've already explained some strong reasons. Diversity and choice are not 
necessary good as there is harm from fragmentation and duplication of 
efforts. Every package have maintenance cost. So far I don't recognise 
benefits from introducing almost similar competitive software merely to 
encourage confusion among our users. I'd like to be convinced that MooseFS is 
superiour but I don't see enough supporting evidence.
In some areas MooseFS is worse, at least due to lack of VCS and bug tracker.


> > With all due respect to MooseFS's former innovations and legacy I think
> > for now it would be best to refrain from debianising MooseFS and
> > re-evaluate situation in the future if there will be any development.
> 
> What kind of "development" are you talking about?

Situational. I meant if/when situation is changed.

-- 
Regards,
 Dmitry Smirnov.

---

Free speech is the bedrock of liberty and a free society. And yes, it
includes the right to blaspheme and offend.
-- Ayaan Hirsi Ali, 2010


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

Bug#811345: setupcon not run

[Samuel Thibault]

Control: reassign -1 console-setup
Control: merge -1 759657

Sebastien Hinderer, on Mon 18 Jan 2016 07:05:51 +0100, wrote:
> Virtual consoles of 25x80 are more comfortable for me so these settings
> appear in /etc/default/console-setup:
> 
> SCREEN_WIDTH=80
> SCREEN_HEIGHT=25
> 
> However at boot time these settings are not taken into account and I
> have to run setupcon manually.

This is most probably a duplicate of 759657 ("console-setup w/ systemd
forgets font setting"), try to add 

ACTION=="add", SUBSYSTEM=="vtconsole", KERNEL=="vtcon*", RUN+="/bin/setupcon"

to a new /etc/udev/rules.d/90-setupcon.rules file

Samuel

Bug#811353: Proxy settings in apt will not get updated after initial values set

[Sebastian Krümling]

Package: cdrom/installation-reports
Version: debian 8.2 netinstall iso downloaded 2016-18-01
Severity: Important


When entered wrong proxy settings in first place, reentered proxy addresses
will not update the apt configuration, apt will constantly use the inital
wrong proxy settings.
After some attempts i installed the only base system and after login
"apt-configuration dump" revealed the first, wrong proxy address and port.

Current workarounds are restart of the debian installer or update apt
config after base system installation.

Bug#811350: apt-cacher-ng: Cronjob fails when a proxy is set for downloads

[Danny Edel]

Package: apt-cacher-ng
Version: 0.8.8-1~bpo8+1

Dear Maintainer,

I am getting this message from my apt-cacher-ng cron job:

/etc/cron.daily/apt-cacher-ng:
Error: cannot fetch
http://localhost:3142/acng-report.html?doExpire=Start+Expiration=aOe,
HTTP/1.0 404 Not Found

If I log in on the machine, and try to fetch the URL with curl, it works
just fine, but if I execute /etc/cron.daily/apt-cacher-ng I get the same
error message as above.

I checked with strace -f -e connect /etc/cron.daily/apt-cacher-ng and it
sends the request to the upstream proxy server that apt-cacher-ng uses
to access the Debian mirror.


If I comment out the Proxy: line in /etc/apt-cacher-ng/zz_debconf.conf
the expiration task starts normally.


I am not sure if it's intended behaviour that the expiration task uses a
proxy to connect back to the machine running apt-cacher-ng, so I'm
filing this bug report.


I am using the version in jessie-backports repository, in case that is
relevant.


Thank you,

- Danny

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Dmitry Smirnov]

On Mon, 18 Jan 2016 06:53:05 AM Jakub Kruszona-Zawadzki wrote:
> On 15 Jan, 2016, at 15:04, Dmitry Smirnov  wrote:
> > Except for promoting MooseFS I do not see any benefits from introducing
> > MooseFS to Debian but there are numerous cons.
> 
> Absolutely the same I can say about LizardFS.

Can you be more specific please?


> > As far as I'm aware that was deliberate choice in order to allow seamless
> > upgrades from MooseFS. I think renaming is planned but it is a low
> > priority thing.
> 
> Ok. Two years ago maybe it might sense, but now it is only confusing. You
> can't switch from MooseFS 2.0+ to LizardFS (and vice versa) because forks
> are not compatible any more, so why not to change binary names?

That's right but it is not a big problem since one would hardly use MooseFS 
and LizardFS binaries together. There might be some secondary benefits as 
compatible utility names could be used by user scripts (that would have to be 
adjusted for rename). I agree, perhaps these days it would be nice to finish 
renaming but this is a minor thing... Let's not discuss that here any 
further... There should be corresponding LizardFS bug for this.


> The think is that we have totally
> different goals. In MooseFS we want to have very sturdy, reliable product.

This is unfair to suggest that LizardFS do not strive to have reliable 
product.


> This is why I don't want to publish unfinished code and this is why we
> don't want to have public code repository. I'm considering making public
> code mirror on GitHub or similar place, but with committed only published
> sources, not every change I made.

LizardFS put all contributions - even minor commits through Gerrit code 
review. Their commits are conservative - not too frequent but certainly 
careful.

There is no harm to your users if your VCS is publicly accessible.
Testers and external developers might find it useful and regular users should 
use stable releases.

There might be another reason: MySQL do not expose their VCS because they do 
not want to publish their proprietary code. I suspect MooseFS might have 
similar concerns.


> Yes, we do not have public bug tracker.
> Now we use just sourceforge list. Nevertheless this is good idea to have
> public bug tracker. We will do it ASAP. I can understand necessity of
> having such. I've just recently found a bug in fuse and didn't know where
> to post it. The same might be with MooseFS.

Indeed bug tracker will be very useful even if you only use it internally.
I recommend to consider Redmine which is used by Ceph, Opennebula and many 
others.


> Do you know why people choose MooseFS? We have a lot of similar products.
> We have GlusterFS, Ceph, BeeGFS, XtreemeFS etc. All our clients claim that
> they have chosen MooseFS because of stability and reliability, not number
> of features. This is File System we are talking about, not some christmas
> toy.

While features are also important my own experience confirms that Ceph is 
rubbish and XtreemFS and others are not far away. MooseFS is superiour to all 
those storage systems but its governance made it impossible for me to choose 
it. Hence I'm in favour of LizardFS.


> This is why I only accepted code from community that didn't have
> issues (at least obvious).
> LizardFS is full of such small issues. I know
> many scenarios in LizardFS which lead to data loss/corruption. Sometimes
> it is not good idea to accept everything to your code.

It would be truly great if you could support your claims. You seems to 
suppose that LizardFS bugs were introduced by careless community 
contributions but I do not recall even single case where LizardFS bug was not 
originated either from old MooseFS code or from LizardFS's own development.
Certainly community is not to be blamed for bugs in LizardFS.


> We are very open to
> our community and we do everything to make our users happy (yes users -
> users who use GPL version and who don't pay us). For me all GPL users are
> as much important as PRO users.

That's very nice. Although contributing to MooseFS without VCS and bug 
tracker is not easy...


> The think is that we have a lot of users (probably more than LizardFS - of
> course it's unprovable)

It is entirely possible that MooseFS still have more customers even despite 
loss of those who prefer LizardFS. But popularity is a poor criteria. How is 
it suppose to influence our decision?


> and all of them should have right to choose. This is called democracy.

You seems to mistake freedom of choice for democracy. Democracy is not what 
we use to justify introducing of software to Debian. Also see Mencken's quote 
about democracy below.


> MooseFS is available in almost all other OS'es in standard ports/packages.

MooseFS packaging is immature and do not meet Debian standards of quality.


> > Thank you for interesting insights about projects history.
> 
> There is more. And it's pity that you even help them.

I'm not sorry for helping 

Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system

[Jakub Kruszona-Zawadzki]

On 18 Jan, 2016, at 8:35, Dmitry Smirnov  wrote:

> On Mon, 18 Jan 2016 07:23:30 AM Jakub Kruszona-Zawadzki wrote:
>> On 15 Jan, 2016, at 15:10, Dmitry Smirnov  wrote:
>>> I had a glimpse at the packaging in the source archive 3.0.69 and I think
>>> it needs much more work before it could be uploaded (let alone my
>>> objections against introducing MooseFS to Debian). There are too many
>>> issues to list...
>> Could you enlight me? 'debian' folder looks almost the same in MooseFS and
>> LizardFS. What issues are you talking about? Some examples?
> 
> Please note that official Debian packaging is quite different from what you 
> can find in upstream repository. LizardFS team is not competent with 
> packaging and they barely touched it as far as I recall.
> 
> Obvious way to improve packaging would be to address Lintian warnings, 
> introduce support for Systemd etc. Sorry I don't have time for in-depth 
> review and at the moment I have no intention to sponsor MooseFS...

ok. Thank you. We have systemd support. We have it in our "rpm" tree, but it is 
probably very easy to adapt it to "debian" subtree.

> 
> 
>> Believe me or not, but we are very open to change some things in MooseFS.
>> As you maybe know we change licence of open source version to GPL and made
>> it freely available, so we always try to adapt to community necessities.
> 
> 
> That is very nice indeed. Thank you.
> 
> -- 
> Regards,
> Dmitry Smirnov.
> 
> ---
> 
> Success consists of going from failure to failure without loss of enthusiasm.
>-- Winston Churchill

-- 
Regards,
Jakub Kruszona-Zawadzki
- - - - - - - - - - - - - - - -
Segmentation fault (core dumped)
Phone: +48 602 212 039

Bug#811349: nvidia-driver-bin: 343.36-3 driver blocks startup in a periodic state

[Ara Keary]

Package: nvidia-driver-bin
Version: 340.96-4
Severity: critical
Justification: breaks the whole system

Dear maintainers,

updating the nvidia drivers from 340.96-4 to 343.36-3 (new version in unstable)
renders the system unusable: after installation and restart, display (in text
mode!) becomes impermanent, entering in a very fast quasi-periodic oscillation
between a black screen and text console login.

No text could be entered while attempting to log in. I did not insist, fearing
that the state of the system could damage the video card.

Restarting in Debian Recovery mode and reverting to 340.96-4 (as i had to do to
fill this bug report) solves the problem.

Report bug also states :
  nvidia-driver/install-even-if-unsupported-gpu-exists: false
  nvidia-driver/check-for-unsupported-gpu: true

I'm not sure this is the right package agains which to report the bug.

Best,

Ara



-- Package-specific info:
uname -a:
Linux host-32-141 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5 (2016-01-04) x86_64
GNU/Linux

/proc/version:
Linux version 4.3.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.3.1
20160101 (Debian 5.3.1-5) ) #1 SMP Debian 4.3.3-5 (2016-01-04)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.96  Sun Nov  8 22:33:28 PST
2015
GCC version:  gcc version 5.3.1 20160114 (Debian 5.3.1-6)

lspci 'VGA compatible controller [0300]':
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GK106GLM [Quadro
K2100M] [10de:11fc] (rev a1) (prog-if 00 [VGA controller])
DeviceName: 0
Subsystem: Hewlett-Packard Company GK106GLM [Quadro K2100M] [103c:2254]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: nvidia
Kernel modules: nvidia

dmesg:
[0.00] ACPI: SSDT 0x5DFC5000 001A24 (v01 HPQOEM NVIDIAGF
0001 INTL 20130927)
[0.00] Console: colour VGA+ 80x25
[4.313512] vgaarb: setting as boot device: PCI::01:00.0
[4.313513] vgaarb: device added:
PCI::01:00.0,decodes=io+mem,owns=io+mem,locks=none
[4.313515] vgaarb: loaded
[4.313515] vgaarb: bridge control possible :01:00.0
[4.585995] Linux agpgart interface v0.103
[6.844098] nvidia: module license 'NVIDIA' taints kernel.
[6.850680] vgaarb: device changed decodes:
PCI::01:00.0,olddecodes=io+mem,decodes=none:owns=io+mem
[6.850937] [drm] Initialized nvidia-drm 0.0.0 20150116 for :01:00.0 on
minor 0
[6.850942] NVRM: loading NVIDIA UNIX x86_64 Kernel Module  340.96  Sun Nov
8 22:33:28 PST 2015
[6.954434] snd_hda_intel :01:00.1: Handle VGA-switcheroo audio client
[7.450839] input: HDA NVidia HDMI/DP,pcm=3 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input19
[7.450891] input: HDA NVidia HDMI/DP,pcm=7 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input20
[7.450931] input: HDA NVidia HDMI/DP,pcm=8 as
/devices/pci:00/:00:01.0/:01:00.1/sound/card1/input21
[   70.558494] nvidia_uvm: Loaded the UVM driver, major device number 243

Device node permissions:
crw-rw+ 1 root video 226,   0 Jan 18 08:29 /dev/dri/card0
crw-rw-rw-  1 root root  243,   0 Jan 18 08:30 /dev/nvidia-uvm
crw-rw-rw-+ 1 root root  195,   0 Jan 18 08:29 /dev/nvidia0
crw-rw-rw-+ 1 root root  195, 255 Jan 18 08:29 /dev/nvidiactl
video:x:44:

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Jan 18 08:29 /etc/alternatives/glx ->
/usr/lib/nvidia
lrwxrwxrwx 1 root root   44 Jan 18 08:29 /etc/alternatives/glx--
libEGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   48 Oct  8 17:36 /etc/alternatives/glx--libGL.so-
x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Oct  8 17:36 /etc/alternatives/glx--libGL.so-
x86_64-linux-gnu -> /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Jan 18 08:29 /etc/alternatives/glx--
libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Jan 18 08:29 /etc/alternatives/glx--
libGL.so.1-i386-linux-gnu -> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 18 08:29 /etc/alternatives/glx--
libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Jan 18 08:29 /etc/alternatives/glx--
libGL.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   50 Jan 18 08:29 /etc/alternatives/glx--
libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-
gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Jan 18 08:29 /etc/alternatives/glx--
libGLESv1_CM.so.1-x86_64-linux-gnu -> /usr/lib/x86_64-linux-
gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   47 Jan 18 08:29 /etc/alternatives/glx--

Bug#810853: RFS: moosefs/2.0.83-1 [ITP] -- fault tolerant, reliable, highly available, highly performing, scaling-out network distributed file system

[Dmitry Smirnov]

On Mon, 18 Jan 2016 07:23:30 AM Jakub Kruszona-Zawadzki wrote:
> On 15 Jan, 2016, at 15:10, Dmitry Smirnov  wrote:
> > I had a glimpse at the packaging in the source archive 3.0.69 and I think
> > it needs much more work before it could be uploaded (let alone my
> > objections against introducing MooseFS to Debian). There are too many
> > issues to list...
> Could you enlight me? 'debian' folder looks almost the same in MooseFS and
> LizardFS. What issues are you talking about? Some examples?

Please note that official Debian packaging is quite different from what you 
can find in upstream repository. LizardFS team is not competent with 
packaging and they barely touched it as far as I recall.

Obvious way to improve packaging would be to address Lintian warnings, 
introduce support for Systemd etc. Sorry I don't have time for in-depth 
review and at the moment I have no intention to sponsor MooseFS...


> Believe me or not, but we are very open to change some things in MooseFS.
> As you maybe know we change licence of open source version to GPL and made
> it freely available, so we always try to adapt to community necessities.


That is very nice indeed. Thank you.

-- 
Regards,
 Dmitry Smirnov.

---

Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill


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

Bug#513235: gnome-keyring: selects wrong key when multiple ssh identities are used

[Vincent Bernat]

 ❦ 27 janvier 2009 17:21 +0100, Josselin Mouette  :

>> >> I regularily log into a system which uses different ssh keys to select 
>> >> different 
>> >> configurations.  This fails if gnome-keyring-daemon is running.  It seems 
>> >> to use
>> >> previously learned keys even if you specify "ssh -i ", or use the
>> >> IdentityFile keyword in ~/.ssh/config.
>> >
>> > It would be interesting to see whether this happens if you use ssh-agent
>> > instead of gnome-keyring. If you add the first key to the agent, do you
>> > see the same behavior with "ssh -i key2" ?
>> 
>> Just running ssh-agent isn't a problem.  But you're right that any key
>> added to the agent seems to be used before other keys.  If I add the key
>> to ssh-agent, then it will be used first.
>
> So indeed, ssh is trying the keys proposed by the agent before those
> passed with the -i option. This looks like the root cause to me, since
> command-line arguments should have priority over things proposed by an
> external process. 

The solution is to use IdentitiesOnly option. The linked bug report
highlights that and there was no real evidence this wasn't working as
expected. It works as expected for me.

I propose to close this bug report (and as I randomly stumbled on it, I
am unlikely to remember that in a few days).
-- 
Suspicion always haunts the guilty mind.
-- Wm. Shakespeare


signature.asc
Description: PGP signature

Bug#811329: mstflint: Please use dh_autotools-dev to update config.{sub,guess} for new ports

[Niels Thykier]

Control: tags -1 moreinfo

On Mon, 18 Jan 2016 01:26:56 +0100 Artur Rona  wrote:
> Package: src:mstflint
> Version: 4.1.0+1.46.gb1cdaf7-1
> Tags: patch
> Usertags: origin-ubuntu ubuntu-patch xenial
> 
> In Ubuntu, we've applied the attached patch to achieve the following:
> 
>* debian/rules: Update config.{sub,guess} correctly with 
> dh_autotools-dev.
> 
> We thought you might be interested in doing the same.

Hi Artur,

A very recent change to debhelper applies a similar change by default.
Are you sure this patch is still needed with debhelper/9.2016011{4,5}?

Thanks,
~Niels




signature.asc
Description: OpenPGP digital signature

Bug#811351: linux-image-4.3.0-0.bpo.1-kirkwood: MMC does not work on OpenRD Client / fix pending

[Rick Thomas]

Package: src:linux
Version: 4.3.3-5~bpo8+1
Severity: normal

Dear Maintainer,

The 4.3.0.0 kernel on an "OpenRD Client" fails to recognize the SD card -- 
there is no mmc device shown by lsblk.

This is fixed by using a modified DTB file provided by Aaro Koskinen.
Fix tested by Rick Thomas.
Martin Michlmayr has the details.


-- Package-specific info:
** Version:
Linux version 4.3.0-0.bpo.1-kirkwood (debian-ker...@lists.debian.org) (gcc 
version 4.9.2 (Debian 4.9.2-10) ) #1 Debian 4.3.3-5~bpo8+1 (2016-01-07)

** Command line:
console=ttyS0,115200

** Tainted: C (1024)
 * Module from drivers/staging has been loaded.

** Kernel log:
[7.702388] NET: Registered protocol family 10
[7.707889] systemd[1]: Inserted module 'ipv6'
[7.714743] systemd[1]: Set hostname to .
[8.185269] systemd[1]: Cannot add dependency job for unit 
display-manager.service, ignoring: Unit display-manager.service failed to load: 
No such file or directory.
[8.203342] systemd[1]: Starting Forward Password Requests to Wall Directory 
Watch.
[8.211470] systemd[1]: Started Forward Password Requests to Wall Directory 
Watch.
[8.219225] systemd[1]: Expecting device dev-ttyS0.device...
[8.236795] systemd[1]: Starting Remote File Systems (Pre).
[8.252761] systemd[1]: Reached target Remote File Systems (Pre).
[8.259054] systemd[1]: Starting Dispatch Password Requests to Console 
Directory Watch.
[8.267366] systemd[1]: Started Dispatch Password Requests to Console 
Directory Watch.
[8.275428] systemd[1]: Starting Paths.
[8.288760] systemd[1]: Reached target Paths.
[8.293257] systemd[1]: Starting Encrypted Volumes.
[8.308756] systemd[1]: Reached target Encrypted Volumes.
[8.314360] systemd[1]: Starting Arbitrary Executable File Formats File 
System Automount Point.
[8.336767] systemd[1]: Set up automount Arbitrary Executable File Formats 
File System Automount Point.
[8.346341] systemd[1]: Expecting device 
dev-disk-by\x2duuid-d5b98715\x2df529\x2d4170\x2d8559\x2d6f9fae4ac1e9.device...
[8.368782] systemd[1]: Expecting device 
dev-disk-by\x2duuid-806d1dac\x2d2026\x2d4b31\x2d977d\x2df47f0f9b7207.device...
[8.392770] systemd[1]: Starting Root Slice.
[8.404756] systemd[1]: Created slice Root Slice.
[8.409591] systemd[1]: Starting User and Session Slice.
[8.424758] systemd[1]: Created slice User and Session Slice.
[8.430643] systemd[1]: Starting Delayed Shutdown Socket.
[8.444761] systemd[1]: Listening on Delayed Shutdown Socket.
[8.450649] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[8.468761] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[8.475867] systemd[1]: Starting Journal Socket (/dev/log).
[8.492758] systemd[1]: Listening on Journal Socket (/dev/log).
[8.498852] systemd[1]: Starting udev Control Socket.
[8.512762] systemd[1]: Listening on udev Control Socket.
[8.518332] systemd[1]: Starting udev Kernel Socket.
[8.532758] systemd[1]: Listening on udev Kernel Socket.
[8.538225] systemd[1]: Starting Journal Socket.
[8.552759] systemd[1]: Listening on Journal Socket.
[8.557930] systemd[1]: Starting System Slice.
[8.572760] systemd[1]: Created slice System Slice.
[8.577823] systemd[1]: Started File System Check on Root Device.
[8.584037] systemd[1]: Starting system-systemd\x2dfsck.slice.
[8.600764] systemd[1]: Created slice system-systemd\x2dfsck.slice.
[8.607171] systemd[1]: Starting system-getty.slice.
[8.624758] systemd[1]: Created slice system-getty.slice.
[8.630294] systemd[1]: Starting system-serial\x2dgetty.slice.
[8.648761] systemd[1]: Created slice system-serial\x2dgetty.slice.
[8.655241] systemd[1]: Starting Increase datagram queue length...
[8.675792] systemd[1]: Starting Create list of required static device nodes 
for the current kernel...
[8.703721] systemd[1]: Starting udev Coldplug all Devices...
[8.734742] systemd[1]: Started Set Up Additional Binary Formats.
[8.746369] systemd[1]: Starting Load Kernel Modules...
[8.771856] systemd[1]: Mounted Huge Pages File System.
[8.792795] systemd[1]: Mounting POSIX Message Queue File System...
[8.819522] systemd[1]: Mounting Debug File System...
[8.843315] systemd[1]: Starting Slices.
[8.868822] systemd[1]: Reached target Slices.
[8.875562] systemd[1]: Starting Remount Root and Kernel File Systems...
[8.908840] systemd[1]: Mounted Debug File System.
[8.926006] EXT4-fs (sdb2): re-mounted. Opts: errors=remount-ro
[8.932879] systemd[1]: Mounted POSIX Message Queue File System.
[8.956788] systemd[1]: Started Increase datagram queue length.
[8.976779] systemd[1]: Started Create list of required static device nodes 
for the current kernel.
[8.996885] systemd[1]: Started Load Kernel Modules.
[9.016818] systemd[1]: Started Remount Root and Kernel File Systems.
[9.084783] systemd[1]: Started udev Coldplug all Devices.
[

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Jakub Kruszona-Zawadzki]

On 18 Jan, 2016, at 8:25, Dmitry Smirnov  wrote:

> On Mon, 18 Jan 2016 06:53:05 AM Jakub Kruszona-Zawadzki wrote:
>> On 15 Jan, 2016, at 15:04, Dmitry Smirnov  wrote:
>>> Except for promoting MooseFS I do not see any benefits from introducing
>>> MooseFS to Debian but there are numerous cons.
>> 
>> Absolutely the same I can say about LizardFS.
> 
> Can you be more specific please?
> 

To have "only" LizardFS in your repository you promote LizardFS and I don't 
know why?

> 
>>> As far as I'm aware that was deliberate choice in order to allow seamless
>>> upgrades from MooseFS. I think renaming is planned but it is a low
>>> priority thing.
>> 
>> Ok. Two years ago maybe it might sense, but now it is only confusing. You
>> can't switch from MooseFS 2.0+ to LizardFS (and vice versa) because forks
>> are not compatible any more, so why not to change binary names?
> 
> That's right but it is not a big problem since one would hardly use MooseFS 
> and LizardFS binaries together. There might be some secondary benefits as 
> compatible utility names could be used by user scripts (that would have to be 
> adjusted for rename). I agree, perhaps these days it would be nice to finish 
> renaming but this is a minor thing... Let's not discuss that here any 
> further... There should be corresponding LizardFS bug for this.

Ok.

> 
> 
>> The think is that we have totally
>> different goals. In MooseFS we want to have very sturdy, reliable product.
> 
> This is unfair to suggest that LizardFS do not strive to have reliable 
> product.
> 

Maybe they want, but they do not have it. Number of issues in they github is 
huge (of course since we do not have public bug track we can't compare :) )

But we will change that. There will be official source tree of GPL'ed MooseFS 
in GitHub.

> 
>> This is why I don't want to publish unfinished code and this is why we
>> don't want to have public code repository. I'm considering making public
>> code mirror on GitHub or similar place, but with committed only published
>> sources, not every change I made.
> 
> LizardFS put all contributions - even minor commits through Gerrit code 
> review. Their commits are conservative - not too frequent but certainly 
> careful.

No comment.

> 
> There is no harm to your users if your VCS is publicly accessible.
> Testers and external developers might find it useful and regular users should 
> use stable releases.

I agree. As I mentioned we will change that. There will be official MooseFS 
source code on GitHub.

> 
> There might be another reason: MySQL do not expose their VCS because they do 
> not want to publish their proprietary code. I suspect MooseFS might have 
> similar concerns.

We will not publish our proprietary code (as for now), but it doesn't mean that 
we will not publish GPL'ed MooseFS. As I wrote. GPL'ed version is almost full 
MooseFS. I even plan to publish master failover in GPL'ed version (not full HA 
as we have it in PRO, but failover as in LizardFS). I have to convince our 
investor, but I hope that it will be doable. I'm very pro free software and I 
think that there should be no "pro" version of MooseFS (my personal opinion), 
but life is sometimes brutal and unfair.

> 
> 
>> Yes, we do not have public bug tracker.
>> Now we use just sourceforge list. Nevertheless this is good idea to have
>> public bug tracker. We will do it ASAP. I can understand necessity of
>> having such. I've just recently found a bug in fuse and didn't know where
>> to post it. The same might be with MooseFS.
> 
> Indeed bug tracker will be very useful even if you only use it internally.
> I recommend to consider Redmine which is used by Ceph, Opennebula and many 
> others.

Yes. We use Redmine internally, but I agree that having public bug tracking is 
the best, because all users will have access to that.

> 
> 
>> Do you know why people choose MooseFS? We have a lot of similar products.
>> We have GlusterFS, Ceph, BeeGFS, XtreemeFS etc. All our clients claim that
>> they have chosen MooseFS because of stability and reliability, not number
>> of features. This is File System we are talking about, not some christmas
>> toy.
> 
> While features are also important my own experience confirms that Ceph is 
> rubbish and XtreemFS and others are not far away.

This time I agree with you in 100% :)

> MooseFS is superiour to all 
> those storage systems but its governance made it impossible for me to choose 
> it. Hence I'm in favour of LizardFS.

I hope that it will change some day. Did you even try to test MooseFS 3.0? 
Compare to LizardFS? 

If you need PRO licence to do some test then let me know - We will send it.

> 
> 
>> This is why I only accepted code from community that didn't have
>> issues (at least obvious).
>> LizardFS is full of such small issues. I know
>> many scenarios in LizardFS which lead to data loss/corruption. Sometimes
>> it is not good idea to accept everything to your code.
> 
> 

Bug#811355: pcmanfm: Modified time defaults to 2012-09-15 instead of current date

[Andreas Neudecker]

Package: pcmanfm
Version: 1.2.3-1.1
Severity: normal

Dear Maintainer,

in the Tools menu go to Find files... -> Search Files(box) -> Properties(tab).
The "Last Modified Time" always defaults to September 15, 2012 instead of the
current date. And since the month and year selectors are no drop-down lists it
requires a lot of clicks to get to a date close to present. It would be great
if this dialogue could default to "today" or at least remember the previously
selected date.

Regards

Andreas




-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

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

Versions of packages pcmanfm depends on:
ii  libatk1.0-0  2.18.0-1
ii  libc62.19-22
ii  libcairo21.14.4-1
ii  libfm-gtk4   1.2.3-1
ii  libfm4   1.2.3-1
ii  libfontconfig1   2.11.0-6.3
ii  libfreetype6 2.6.1-0.1
ii  libgdk-pixbuf2.0-0   2.32.2-1
ii  libglib2.0-0 2.46.2-1
ii  libgtk2.0-0  2.24.28-1
ii  libpango-1.0-0   1.38.1-1
ii  libpangocairo-1.0-0  1.38.1-1
ii  libpangoft2-1.0-01.38.1-1
ii  libx11-6 2:1.6.3-1

Versions of packages pcmanfm recommends:
ii  gnome-icon-theme   3.12.0-1
ii  gvfs-backends  1.26.2-1
ii  gvfs-fuse  1.26.2-1
ii  oxygen-icon-theme  4:4.14.0-1
ii  policykit-1-gnome  0.105-2
ii  tango-icon-theme   0.8.90-5

pcmanfm suggests no packages.

-- no debconf information

Bug#783919: news on ocaml-llvm bindings ?

[Pierre Chifflier]

On Sat, Jan 16, 2016 at 01:56:36PM +0100, Sylvestre Ledru wrote:
> Le 11/01/2016 20:56, Pierre Chifflier a écrit :
> > tags 783919 +patch
> > thanks
> >
> > On Thu, Nov 26, 2015 at 01:33:19PM +0100, Sylvestre Ledru wrote:
> >> I will be happy to apply a patch if you have any.
> >>
> > Hi Sylvestre,
> >
> > Here is a patch for llvm-toolchain-3.6. It is now possible to build it
> > with the bindings enabled, since ocaml-ctypes >= 0.4 has transitioned
> > [1].
> >
> I tried to build it for an upload but it failed with:
> 
> debian/rules override_dh_install
> make[1]: Entering directory '/tmp/buildd/llvm-toolchain-3.6-3.6.2'
> dh_install --fail-missing
> dh_install: libllvm-3.6-ocaml-dev missing files: /usr/lib/ocaml/llvm-3.6
> dh_install: missing files, aborting
> debian/rules:368: recipe for target 'override_dh_install' failed
> make[1]: *** [override_dh_install] Error 2
> 
> Does it ring a bell?
> 
> Thanks
> S
> 

Hi Sylvestre,

I'm not sure of the reason, I have built in a clean chroot. This might
be caused by something in the build environment.

Basically this means that the bindings were not built. You should check
(in order):
- that you are using the configure version, not the cmake one
- that you ocaml packages are up to date (especially ocaml-ctypes, we
  might want to add a versioned build dependency)
- that the patch was applied, especially the debian/rules part (which
  removes the --disable-bindings and adds --with-ocaml-libdir=...)
- that ocaml and libs were correctly detected (this is written at the
  beginning of config.log)

Hope that helps.

Cheers,
Pierre

Bug#796956: Explanation

[Bálint Réczey]

Hi Lisandro,

2016-01-15 15:16 GMT+01:00 Lisandro Damián Nicanor Pérez :
> severity 796956 important
> thanks
>
> OK everyone this is really not a serious bug (actually I still don't think
> this is a bug at all). I'll keep it open until we get Qt 5.6 into the archive
> with a "fix".
>
> Let's start with the basics: sadly libqt5xcbqpa5 is a missnamed package. it
> should have been something along qt5-xcb-platform-plugin... because it's a
> plugin which happens to ship a private lib (that's why we accidentally
> misnamed it).
>
> Now the reasoning: Qt 5 now works with "platform" plugins and not necessarily
> just on X. That means that as long as you don't depend on X-exclusive stuff
> (or any other platform-dependant code) you can run a Qt5 app on the
> frambuffer, Wayland and other interesting places.
>
> So, strictly speaking, libqt5xcbqpa5 (which again should have been named as a
> plugin) is not a strict dependency, and thus the recommendation. And people
> not using recommendations should handle it by hand.
Since a missing libqt5xcbqpa5 would make applications crash on X which is far
more popular than framebuffer or Wayland it does not seem to be a good idea to
handle it as a pure recommendation.

Libqt5xcbqpa5 being a true plugin or not is a semantic question. Users probably
does not call a component a plugin, when and application does not start at all
on their system. Developers can call those plugins, but making them mandatory
can make users not to think about that question.

...
> I'm now leaving this non-bug opened as important just to let people now that
> there is really no bug and how to solve this issue. I will close it with Qt
> 5.6.x if we get to merge the plugins.
5.6.x is beta in experimental and I can't tell when it enters
unstable. If it does not
get uploaded to unstable in a few days with a good chance of migrating
to testing
soon please upload a fix to 5.5.x.
Otherwise wireshark would have to be updated twice, once for adding
libqt5xcbqpa5 as a dependency and once for removing it for Qt 5.6.x.

Fixing this bug for Qt fixes many other packages and it will be fixed in Qt
anyway thus please consider updating Qt 5.5 in a few days. This problem
may be an "important" one in Qt, but for every other package affected it
creates an RC bug.

Thanks,
Balint

Bug#757770: RFH: pgadmin3 -- graphical administration tool for PostgreSQL

[Christoph Berg]

Re: Denis Briand 2016-01-15 <20160115201632.GA27428@emachines>
> Hello Christoph,
> 
> Any volunteer?
> I could help you if you are OK.
> I could start by bug triage.
> 
> I use pgadmin3 for my IT studies and I'm debian maintainer:
> https://qa.debian.org/developer.php?login=debian%40denis-briand.fr

Hi Denis,

as said on the mailing list and IRC, thanks, and welcome!

Christoph
-- 
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Hohenzollernstr. 133, 41061 Mönchengladbach
Geschäftsführung: Dr. Michael Meskes, Jörg Folz, Sascha Heuer
pgp fingerprint: 5C48 FE61 57F4 9179 5970  87C6 4C5A 6BAB 12D2 A7AE

Bug#805577: iceweasel: Iceweasel contains Pocket which is considered non-free

[Sylvestre Ledru]

Le 18/01/2016 00:51, Louis-Philippe Véronneau a écrit :
> This is indeed a very serious problem and should at least be
> acknowledged by the maintainers.
>
> Can you do something about this?
>
>
The client code is free [1].
Even if the server part is not, I don't see the point of this bug.
Firefox also propose services based Yahoo or Google services. Both of them are 
not free either.

Cheers,
Sylvestre
[1] https://dxr.mozilla.org/mozilla-central/source/browser/extensions/pocket

Bug#811356: libllvm3.5: LLVM assembler during execution of glxgears and other

[Joey Schulze]

Package: libllvm3.5
Version: 1:3.5.2-1
Severity: important

Dear Maintainer,

there seems to be a problem in the jessie version of libllvm3.5.

It seems the current version uses opcodes that are not supported by
the hardware and thus causes the program to fail.

For example:

$ glxgears
LLVM ERROR: Cannot select: intrinsic %llvm.x86.sse41.pblendvb

The same happens to xine and vlc.

/proc/cpuinfo says:

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 76
model name  : Intel(R) Pentium(R) CPU  N3700  @ 1.60GHz
stepping: 3
microcode   : 0x35e

Regards

Joey

-- System Information:
Debian Release: 8.2
  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=C, LC_CTYPE=en_US.ISO-8859-1 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libllvm3.5 depends on:
ii  libc6  2.19-18+deb8u1
ii  libedit2   3.1-20140620-2
ii  libffi63.1-2+b2
ii  libgcc11:4.9.2-10
ii  libstdc++6 4.9.2-10
ii  libtinfo5  5.9+20140913-1+b1
ii  multiarch-support  2.19-18+deb8u1
ii  zlib1g 1:1.2.8.dfsg-2+b1

libllvm3.5 recommends no packages.

libllvm3.5 suggests no packages.

-- no debconf information

-- 
Whenever you meet yourself you're in a time loop or in front of a mirror.

Please always Cc to me when replying to me on the lists.

Bug#811287: Clang: should pull libomp5 AND/OR libomp-dev package for OpenMP support

[Sylvestre Ledru]

Le 17/01/2016 17:50, Roman Lebedev a écrit :
> Package: clang-3.8
> Version: 1:3.8~svn257294-1~exp1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> For OpenMP support, clang requires libomp5 library.
> Currently, clang package does not depend on libomp5 package,
> so one needs to manually install libomp5 package.
It does not "require" libomp5. It is necessary when building with OpenMP.
OpenMP usage being a niche, I am not sure we want to add another dependency on 
clang.

Sylvestre

Bug#811327: wireshark-gtk: provide wireshark command via alternatives

[Bálint Réczey]

Control: tags -1 confirmed

Hi Olaf,

2016-01-18 1:19 GMT+01:00 Olaf Meeuwissen :
...
> Dear Maintainer,
>
> I just switched from the Qt version (see 811036) and was slightly
> surprised there was no wireshark command, only a wireshark-gtk.
>
> It'd be nice to have a wireshark command no matter which version is
> installed.  This shouldn't be too difficult using the alternatives
> mechanism.
This has been raised before in #80575:
...
>> Wouldn't it make sense if the meta-package wireshark
>> depends on either wireshark-qt | wireshark-gtk
>> (or vice versa)? :-)
> Sure, I'll fix that in the next upload.
>
>>
>> And that if both are installed, root can configure
>> via update-alternatives which one should be invoked
>> with just "wireshark"
...
> Many members of the Wireshark development team would like to phase out
> the GTK+ UI completely and this may happen before the Stretch release,
> in Wireshark 2.2.
> I have not implemented the alternatives system based switching to
> migrating away from it in the next major release, but I'm not absolutely
> sure if it is the best strategy and I'm open to implementing it if I get
> more feedback from users, for example here.
I still think having the alternatives system in place would be nice and if we
release Stretch with the GTK+ version I'll consider implementing it or merging
a patch (hint, hint ;-)) implementing it.

Cheers,
Balint

Bug#810702: Generate initiator name on install, not first boot

[Ritesh Raj Sarraf]

Hello James,

On Mon, 2016-01-18 at 09:52 +, James Page wrote:
> Well I guess that if D-I in Debian does not support installing to
> iSCSI targets, then this is not consumable, but I think the patch is
> still applicable IMHO (just in case someone does do that enablement
> work - one less thing to understand that's broken in test). 

Yes. The patch is fine to be included, and we will add it.

I was just checking to see if there was anything in queue for D-I.


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."



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

Bug#811352: linux 4.4-rc8: i915: "[drm] stuck on render ring" on resume

[Julian Andres Klode]

Control: forwarded -1 https://bugs.freedesktop.org/show_bug.cgi?id=92998
Control: tag -1 upstream

On Mon, Jan 18, 2016 at 09:21:50AM +0100, Julian Andres Klode wrote:
> Package: src:linux
> Version: 4.4~rc8-1~exp1
> Severity: normal
> 
> I'm not sure if that's the right package to report this bug, it could
> also be mesa, the X11 driver, or maybe even gnome-shell. Anyway, I don't
> think I have seen this with 4.3:
> 
> Often, when resuming the GPU hangs, and gnome-shell thus exits and then
> restarts, delaying usable resume by about 13 seconds.
> 
> I'm running xserver-xorg-video-intel 2.99.917+git20151217-1~exp1 from
> experimental (as unstable has a few bugs fixed in there), and libdrm
> 2.4.65-3. Neither have been upgraded recently, so it is
> likely the kernel causing the issue, as this is a very recent
> problem.

This seems to be https://bugs.freedesktop.org/show_bug.cgi?id=92998,
which is caused by commit 101b506a7fc7be3f0d0a337ade270eb5eb5a2857:

  drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset

at least according to some comments in the bug report.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Bug#810842: [a...@debian.org: Bug#810842: igv: libsam-java is gone]

[olivier sallou]

Le jeu. 14 janv. 2016 à 16:44, Andreas Tille  a écrit :

> Hi Olivier,
>
> On Thu, Jan 14, 2016 at 11:54:08AM +, olivier sallou wrote:
> > > Cool.  Thanks for checking.  Would you do the upload yourself
> (preferably
> > > by also upgrading to the latest version)?  If you have time constraints
> > > feel free to commit your test to Git and I'll take over.
> > >
> > I have no time right now, but I can do it quite soon if it is fine for
> you.
>
> OK, since this was actually really easy I saved your time for this one
> and did igv leaving you hopefully some time resource for factqc


I have fixed compil issue for fastqc, I have pushed the update (
d/patches/adapt_to_htslib.patch)

do you want I push the package or do you plan other fixes?

Olivier

and
> which is even more burning for me the issue of tracer in the beast
> package I described here:
>
>
> https://lists.alioth.debian.org/pipermail/debian-med-packaging/2016-January/038124.html
>
> I hope that's a good deal for you. ;-)
>
> Kind regards
>
>  Andreas.
>
> --
> http://fam-tille.de
>

Bug#810884: Info received (Bug#810884: Acknowledgement (freeradius: auth-user-pass with file credentials not re-read when tunnel re-start if auth-nocache enabled))

[Michał B]

This is duplicate and should be closed. Sorry for the mess.

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

Regards,
Mike.

Bug#799861: lintian: false positive in "source-is-missing" when dealing with .js

[Alberto Garcia]

I have the same problem with lintian 2.5.39.1 and webkit2gtk:

E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/Views/ActivateButtonNavigationItem.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/External/CodeMirror/clojure.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/External/CodeMirror/sql.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/External/ESLint/eslint.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/External/Esprima/esprima.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/Protocol/Legacy/6.0/InspectorBackendCommands.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/Protocol/Legacy/7.0/InspectorBackendCommands.js
E: webkit2gtk source: source-is-missing 
Source/WebInspectorUI/UserInterface/Protocol/Legacy/8.0/InspectorBackendCommands.js

Here are some of the affected files:

https://anonscm.debian.org/cgit/pkg-webkit/webkit.git/tree/Source/WebInspectorUI/UserInterface/Views/ActivateButtonNavigationItem.js?id=refs/heads/wk2/unstable
https://anonscm.debian.org/cgit/pkg-webkit/webkit.git/tree/Source/WebInspectorUI/UserInterface/External/CodeMirror/sql.js?id=refs/heads/wk2/unstable

Berto

Bug#752566: openvpn: --auth-user-pass FILE' and '--auth-nocache' problem

[Michał B]

OpenVPN package should be upgraded accrding to those upstream bugs:
https://community.openvpn.net/openvpn/ticket/225 (main)
https://community.openvpn.net/openvpn/ticket/308 (duplicate)
https://community.openvpn.net/openvpn/ticket/248 (duplicate)

This problem occurs when package from Jessie is used. Problem doesn't 
occur when upstream latest package is used.


Regards,
Mike

Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)

[adrian15]

El 18/01/16 a las 07:31, Michal Suchanek escribió:

Hello,

thanks for working on this.

On 18 January 2016 at 05:24, adrian15  wrote:

In my last message I forgot to CC many people who are involved in this bug
so I'm going to refer to my former message, CC some people and finally point
you to my repo/branches where you might find interesting commits.


1) My original message with attached patches (which you can download to your
email program and reply from there) can be found at:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153


2) Repo / Branches:

* efi_support_based_on_debian_cd  (
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd )
: Original dirty branch where I worked in both syslinux-efi and grub-efi
bootloaders at the same time

* efi_support_based_on_debian_cd_rebased (
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
) : The same branch rebased to have minimal useful commits. syslinux-efi was
removed from it because it did not boot.


I have checked what EFI platforms I have and it seems neither would be
bootable with this.

1) a Windows tablet that needs signed bootloader - signed grub is
available as non-free package (because it cannot be modified to not
break the signature) and presumably allows booting on such systems
without going through the unlocking stuff which may break your windows
installation.
Yeah, that's the Microsoft Secure Boot. debian-cd people are working on 
bringing it into official Debian CDs. There is not a fixed date for that 
but everything points that it will be finished within 2016. Once they 
manage to do so I'll see how easy it is to port into this work.


You can always try virtual systems. This is how I currently test this:

kdesudo "kvm -bios /usr/share/ovmf/OVMF.fd -cdrom rescatux-0.40b3.iso 
-boot d -m 512"


.


2) a mac mini which probably needs a GPT and the bootloader stored on
a HFS+ volume or something. Also the bootloader needs to be 'blessed'.
Command for that exists in grub and crashes. Never got this working on
an USB stick.
Well, I have not mentioned that this implementation (based on debian-cd 
team work) also would support intel based mac systems because it has an 
additional HFS+ volume.


I also have a mac book pro myself and the 'hybrid' version of Super 
Grub2 Disk 2.02s3 works for me (when using ALT key at boot). I don't 
remember having blessed it so... I'm unsure about the need (or not) to 
bless it.


So, the 'hybrid' Super Grub2 Disk 2.02s3 also has an additional HFS+ 
partition (as our current implementation here in these patches) put in 
place for mac book compatibility so I guess that this build will also 
boot in my system but I still need to test it.




As to the primary and secondary bootloader - how is the efi bootloader
secondary? It boots the same as the legacy bootloader. You probably
want a concept of compatible bootloaders - that is pairs of
bootloaders that can be installed alongside on the same medium.

* What is it a secondary bootloader?

It's what happens when you request mkisofs that your bootloader to be 
boot in second place or as a second partition. I don't know how it 
actually works.


So in grub-efi we just add to the xorriso options:

-eltorito-alt-boot \
 -e boot/grub/efi.img \
 -no-emul-boot \
 -isohybrid-gpt-basdat \
 -isohybrid-apm-hfsplus

And in syslinux-efi (currently) we add:

-eltorito-alt-boot \
 --efi-boot boot/efi.img \
 -append_partition 2 0x01 \
 binary/boot/efi.img

.

So, I guess the -eltorito-alt-boot does the magic but I'm not sure. 
Maybe someone else can explain it better than me.



* About current compatible bootloaders.
The technology is there. I mean. This is what it's currently available:

binary_grub-efi : Secondary bootloader
binary_grub-legacy : Primary bootloader
binary_grub-pc : Primary bootloader
binary_syslinux : Primary bootloader
binary_syslinux-efi : Secondary bootloader

so that means, in theory you can request one of these 9 combinations:

grub-legacy
grub-pc
syslinux

grub-legacy,grub-efi
grub-pc,grub-efi
syslinux,grub-efi

grub-legacy,syslinux-efi
grub-pc,syslinux-efi
syslinux,syslinux-efi


Why can't you request:

grub-efi
or
grub-efi,syslinux-efi

?

Because nobody has coded grub-efi installed as a primary bootloader yet. 
But the 'framework' is there.


You either need to improve binary_grub-efi or create another script file 
that does its job when ' Is_Primary_Bootloader "grub-efi" ' is true.




Unless
the user requests two bootloaders that are incompatible the medium can
be created.

Ignoring bootloaders is not a good idea. If the user requested
something that is not possible the build should report an error and
stop.
Yeah, that it's hard to implement from the perspective of a single 
bootloader script. So I decided not to implement it.


You could add an additional script or function named: 
check_compatible_bootable_pairs (as you propose) but then you need to 
maintain that 

Bug#810822: ITP: MooseFS Debian repository contains a fork of MooseFS

[Jakub Kruszona-Zawadzki]

On 18 Jan, 2016, at 10:04, Dmitry Smirnov  wrote:

> On Mon, 18 Jan 2016 09:16:25 AM Jakub Kruszona-Zawadzki wrote:
>>> This is unfair to suggest that LizardFS do not strive to have reliable
>>> product.
>> 
>> Maybe they want, but they do not have it. Number of issues in they github
>> is huge (of course since we do not have public bug track we can't compare
>> :) )
> 
> Number of bugs is not a metric of quality.

Really?

> Remember that bugs are also items 
> on developers' TO DO list.
> I reported more LizardFS bugs than anyone else (up to 100) and I'm using 
> LizardFS because it survived vigorous testing.

Did you ever tried huge installations? 3PB, 100mln of files?

> Bugs are also different: some 
> are feature requests, some are not critical for data integrity etc.
> I'm not aware of release-critical bugs without fix but of course there might 
> be some.
> 
> 
>> Hence I'm in favour of LizardFS.

Your choice. I don't have problem with that, but please don't be against us.

>> 
>> I hope that it will change some day. Did you even try to test MooseFS 3.0?
>> Compare to LizardFS?
> 
> So far I've seen no compelling reasons to switch away from LizardFS - not 
> until MooseFS become more open. At the moment IMHO LizardFS is the only 
> choice (and GfarmFS is close second). Also I have no time to try MooseFS. 
> Maybe one day I'll try it but I'll have to justify the effort...

So you shouldn't say bad words about MooseFS. We test LizardFS (and others - 
like Ceph, Gluster etc.) on regular basis.

I understand that it is time-consuming, but I hope that you will find time in 
the future and give it a try.

> 
> 
>> If you need PRO licence to do some test then let me know - We will send it.
> 
> Thank you for your kind offer but no. :) I will only evaluate what's free and 
> suitable for Debian.

ok. :)

> 
> 
>> Simple example of LizardFS wrongdoings. First change they made was to
>> accept chunks with bigger version than version set in master. Chunk
>> version mismatch was in this case for a reason. This can lead to
>> acceptance chunk with wrong data inside. They change it because there were
>> problems with version synchronization (problem originated from original
>> MooseFS). To fix that you should fix synchronization, not just accept
>> everything.
> 
> Interesting, thank you.
> 
> 
>> Maybe because huge part of our users are also Debian users and you may want
>> to make their life easier.
> 
> Makes sense.
> 
> 
>> I don't know if you are aware of this or not, but
>> we have in Poland new government chosen in democratic poll, and they are
>> just ... stupid (horribly stupid and radical).
> 
> I feel your pain. I feel ashamed of our Australian government. :(
> 
> Popularity polls are poor foundation for decision making. But as Winston 
> Churchill once said, "It has been said that democracy is the worst form of 
> government except all the others that have been tried."...

Exactly.

> 
> 
>> I didn't know that. Can you help us to improve that (I understand that you
>> do not have time and don't want to involve, but maybe there is some
>> documentation, some hints - how to improve that)?
> 
> Here you can find some generic links to documents describing packaging for 
> Debian:
> 
>http://mentors.debian.net/qa
> 
> Lintian checks (including pedantic and experimental ones) provide useful 
> hints for areas that can benefit from improvements.
> 
> Also you can refer to official LizardFS packaging which have numerous 
> improvements over "upstream" packaging: 
> 
>https://anonscm.debian.org/cgit/collab-maint/lizardfs.git
> 
> Feel free to ask questions in mentor's mail list. If you CC to me I'll try to 
> answer as well if time allows.

Thanks a lot. This is very helpful, we will check that. I remember porting to 
official freebsd ports - PITA, but what to do. There are rules and we 
(developers) should obey them.

> 
> 
>> This is your decision who you are helping. If you believe in them then help
>> them, but at least try not to be against us. I'm still inventor of MooseFS
>> and I hope that I still make a good job with MooseFS.
> 
> I'm not agains you or MooseFS. Even though at the moment I'm in favour of 
> LizardFS I'm sure LizardFS would not be where it is now without solid 
> foundation of MooseFS.

Thanks for saying that, because at the beginning I had a feeling that you are 
against us.

We are still making this solid foundation (i hope :) ).

> 
> -- 
> All the best,
> Dmitry Smirnov.
> 
> ---
> 
> Odious ideas are not entitled to hide from criticism behind the human
> shield of their believers' feelings.
>-- Richard Stallman

-- 
Regards,
Jakub Kruszona-Zawadzki
- - - - - - - - - - - - - - - -
Segmentation fault (core dumped)
Phone: +48 602 212 039

Bug#810702: Generate initiator name on install, not first boot

[James Page]

Hi Folks

On Mon, Jan 18, 2016 at 9:09 AM, Ritesh Raj Sarraf 
wrote:

> On Mon, 2016-01-18 at 09:52 +0100, Martin Pitt wrote:
> > I'm afraid I really don't know much about open-iscsi and the details
> > why this patch was introduced. James, would be great if you can
> > provide some background.
> >
>
> One reason to have support in the installer is to have your rootfs on a
> SAN device. Anaconda has had it for years. So I'm sure these patches
> must have the same intent for Ubuntu Enterprise LTS.
>

That is the case; I used todo most of the install to iSCSI target testing
at the time, and this got picked up during testing one release.


> > Ubuntu debian-installer does have some differences, but it's
> > generally the same. Does d-i really start services during
> > installation? I would have expected it to install a temporary
> > policy-rc.d, as presumably many services would fail in
> > the d-i environment still. Then calling update-initramfs would put
> > the
> > dummy initiator config into the generated initrd which would fail to
> > boot.
> >
> > But supposedly you tried to set up open-iscsi in the Debian
> > installer.
> > Does that work, or maybe Debian's d-i does not even offer to set up
> > open-iscsi? Ubuntu's does, that might be the important difference
> > here.
>
> I think D-I currently does not have the support. There was a patch from
> Ubuntu, some years ago, for an open-iscsi udeb, which is already part
> of the packaging. But I never did see the relevant D-I part for the
> installer.


Well I guess that if D-I in Debian does not support installing to iSCSI
targets, then this is not consumable, but I think the patch is still
applicable IMHO (just in case someone does do that enablement work - one
less thing to understand that's broken in test).

Bug#809509: Processed: retitle 809509 to gcc-6: Please build with -mcpu=ultrasparc on sparc64 when building 32-bit binaries

[John Paul Adrian Glaubitz]

Hi Jose!

On 01/05/2016 11:21 AM, Jose E. Marchesi wrote:
> Right.  cpu_32, cpu_64, tune_32 and tune_64 are not supported in sparc*
> targets yet.
> 
> I will prepare a patch for that and send it upstream.

Any news on this issue?

Adrian

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

Bug#811315: getdns: FTBFS[kfreebsd]: needs getentropy implementation

[Guillem Jover]

Hi!

On Sun, 2016-01-17 at 21:42:03 +, Steven Chamberlain wrote:
> Package: getdns
> Version: 0.9.0-1
> Severity: normal
> Tags: patch

> getdns FTBFS on kfreebsd because it lacks a getentropy implementation
> for the FreeBSD kernel.  But there is one already in LibreSSL Portable
> we can use, and works fine here.

BTW, libbsd has also a getentropy(3) implementation (lifted too from
LibreSSL), which is currently not exposed but if people want to use it
I could make it public, instead of embedding this in all sorts of
places. The difference being that libbsd is already in Debian, while
LibreSSL is not.

  

Thanks,
Guillem

Bug#811358: RM: firestring -- RoQA; orphaned; low popcon; last update 2007

[Iain R. Learmonth]

Package: ftp.debian.org
Severity: normal

Hi,

Please remove firestring from unstable.

This package has not seen an update since 2007, is orphaned, and has
only 1 recent user as reported by popcon.

See also #804371 where warning was given that removal would be
requested, with no reply.

Thanks,
Iain.

Bug#775310: ikiwiki: git mv on directories results in git merge/overwrite errors

[Simon McVittie]

Control: tags 775310 + moreinfo

On Tue, 13 Jan 2015 at 22:31:57 +, lkcl wrote:
> as i am editing a site over which i do not have direct sysadmin control
> (cannot re-generate the wiki by hand nor correct errors in its operation)

I would not particularly recommend the ikiwiki CGI for this particular
use-case, except in very constrained/predictable situations like the one
set up by ikiwiki-hosting. Making a normally-interactive version control
system fully automated is not something that ikiwiki's maintainers can
make 100% reliable in our spare time.

I would recommend either shared hosting with a shell (there are specific
instructions for NearlyFreeSpeech and DreamHost on its wiki, but most
similar providers should work); a virtual machine that you control (I
use ikiwiki-hosting on a VM from mythic-beasts.com); or the hosting
service branchable.com, for which ikiwiki-hosting was written,
and which is co-maintained by the original author of ikiwiki.

If these are not an option for your site, I will need information from
the sysadmin of your ikiwiki installation.

> to reproduce:
> 
> * create some files and subdirectories (any method is ok)
> * using direct git access (bypassing ikiwiki) perform
>   a "git mv" operation
> * perform a direct "git push" operation.

Using direct git access to what? What repositories do you have here?
Is it a typical ikiwiki git arrangement like this?

e.g. a laptop| VCS server   |  web server
 |  |
mywiki---|-->   mywiki.git  |-> $srcdir -> $destdir
   push  git hook   ikiwiki

where mywiki and $srcdir are both non-bare git clones of the bare git
repository mywiki.git, and you are doing the "git mv"/"git commit"
in your local clone on your laptop or whatever, then pushing to the
VCS server?

> the only method of recovery is to have sysadmin rights *on the target
> system* (which is not available in this specific instance) and to
> perform a manual recovery.
> 
> ideally such a manual override / recovery should be available as
> an option on the preferences/admin page.

What is involved in this manual recovery? Do you have a specific
proposed action that ikiwiki should take to recover?

> error: Your local changes to the following files would be overwritten by 
> merge:
>   community_ideas/laptop_13in.mdwn

This means that at some point in the past, there was a change to this
file on the server (probably via the CGI) which was not committed correctly.
Obviously, that isn't something that's meant to happen in the first place.

Is there anything about that file in the web server's error log?
(ask your sysadmin)

Are there any other uncommitted changes? (ask your sysadmin to run
"git status" in the wiki's working copy, which is the directory that
was configured as the $srcdir for ikiwiki)

If the sysadmin runs something like

git commit -a -m "import uncommitted changes from web server"

in the srcdir, as the uid that would run the CGI hook and with the
environment variables that would typically be seen by the CGI hook,
what happens?

One thing that might have broken commits is that recent versions of git
will refuse to commit if the user (in ikiwiki's case, whatever user will
run the CGI hook) doesn't have a configured git identity. The next
ikiwiki release will work around this by using "IkiWiki "
as a fallback. If this is what's happening, your sysadmin can resolve
this in current ikiwiki by setting GIT_COMMITTER_NAME="IkiWiki" and
GIT_COMMITTER_EMAIL="ikiwiki.info" (or any other suitable placeholder)
in the CGI script's environment.

S

Bug#811364: wicd-gtk: status's icons -Status of wireless network- doesnt show in the interface of Wicd

[DAHMANI]

Package: wicd-gtk
Version: 1.7.3-1
Severity: minor

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: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), 
(500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.3.0-1-686-pae (SMP w/2 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 wicd-gtk depends on:
ii  python-glade2  2.24.0-4
ii  python-gtk22.24.0-4
pn  python:any 
ii  wicd-daemon1.7.3-1

Versions of packages wicd-gtk recommends:
ii  gksu   2.0.2-9
ii  python-notify  0.1.1-4

wicd-gtk suggests no packages.

Versions of packages wicd depends on:
ii  wicd-daemon  1.7.3-1

Versions of packages wicd-daemon depends on:
ii  adduser  3.113+nmu3
ii  dbus 1.10.6-1
ii  debconf  1.5.58
ii  ethtool  1:4.2-1
ii  iproute2 4.3.0-1
ii  iputils-ping 3:20121221-5+b2
ii  isc-dhcp-client  4.3.3-5
ii  lsb-base 9.20160110
ii  net-tools1.60+git20150829.73cef8a-2
ii  psmisc   22.21-2.1
ii  python-dbus  1.2.0-2+b4
ii  python-gobject   3.18.2-2
ii  python-wicd  1.7.3-1
pn  python:any   
ii  wireless-tools   30~pre9-8
ii  wpasupplicant2.3-2.3

Versions of packages wicd-daemon recommends:
ii  rfkill  0.5-1

Versions of packages wicd-daemon suggests:
pn  pm-utils  

Versions of packages python-wicd depends on:
pn  python:any  

-- debconf information:
* wicd/users:

Bug#811050: dnssec-tools broken with perl 5.22

[Ondřej Surý]

Hi Gregor and Petr,

I just uploaded 2.2 to unstable. Could you try it? I don't run it
everywhere as my primary signer is in my signature :)

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server

On Sun, Jan 17, 2016, at 18:43, gregor herrmann wrote:
> Control: tag -1 + upstream fixed-upstream
> 
> On Fri, 15 Jan 2016 08:02:34 +0100, Petr Čech wrote:
> 
> > it seems because of changes in perl 5.22 rollrec/zonesigner/... fail with 
> > following error messages:
> > 
> > UNIVERSAL does not export anything at 
> > /usr/share/perl5/Net/DNS/SEC/Tools/tooloptions.pm line 19.
> > BEGIN failed--compilation aborted at 
> > /usr/share/perl5/Net/DNS/SEC/Tools/tooloptions.pm line 19.
> > Compilation failed in require at /usr/sbin/zonesigner line 52.
> > BEGIN failed--compilation aborted at /usr/sbin/zonesigner line 52.
> 
> Cf.
> https://metacpan.org/pod/release/RJBS/perl-5.22.0/pod/perldelta.pod#use-UNIVERSAL-...-is-now-a-fatal-error
> 
>   Importing functions from UNIVERSAL has been deprecated since v5.12,
>   and is now a fatal error. use UNIVERSAL without any arguments is
>   still allowed.
>  
> 
> Seems to be fixed in the 2.2 tarball at 
> http://www.dnssec-tools.org/download/dnssec-tools-2.2.tar.gz
> (by removing the line from tools/modules/tooloptions.pm).
> 
> Cheers,
> gregor
> 
> -- 
>  .''`.  Homepage https://info.comodo.priv.at/ - OpenPGP key
>  0xBB3A68018649AA06
>  : :' : Debian GNU/Linux user, admin, and developer - 
>  https://www.debian.org/
>  `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation
>  Europe
>`-   NP: Ludwig Hirsch: Asta
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)

Bug#811354: brian: FTBFS: TypeError: histogram() got an unexpected keyword argument 'new'

[Chris Lamb]

Source: brian
Version: 1.4.1-3
Severity: serious
Justification: fails to build from source
User: reproducible-bui...@lists.alioth.debian.org
Usertags: ftbfs
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

brian fails to build from source in unstable/amd64:

  [..]

  brian.stateupdater: INFO Solving linear equations numerically
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  In file included from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1781:0,
   from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/ndarrayobject.h:18,
   from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
   from 
/home/lamby/temp/cdt.20160118093221.T7TISOkJO9/brian-1.4.1/build/.cache/scipy/python27_compiled/sc_90e487a2aefd5b25f36d2d8f047c1c640.cpp:23:
  
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/npy_1_7_deprecated_api.h:15:2:
 warning: #warning "Using deprecated NumPy API, disable it by " "#defining 
NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
   #warning "Using deprecated NumPy API, disable it by " \
^
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.threshold   : WARNING  Using codegen PythonThreshold
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.threshold   : WARNING  Using codegen PythonThreshold
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.threshold   : WARNING  Using codegen PythonThreshold
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.HomogeneousPoissonThreshold: WARNING  HomogeneousPoissonThreshold 
cannot generate enough spikes.
  brian.threshold   : WARNING  Using codegen CThreshold
  brian.equations   : INFO Free variables: ['second']
  brian.stateupdater: INFO Linear model: using exact updates
  brian.stateupdater: INFO Solving linear equations numerically
  In file included from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/ndarraytypes.h:1781:0,
   from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/ndarrayobject.h:18,
   from 
/usr/lib/python2.7/dist-packages/numpy/core/include/numpy/arrayobject.h:4,
   from 
/home/lamby/temp/cdt.20160118093221.T7TISOkJO9/brian-1.4.1/build/.cache/scipy/python27_compiled/sc_7cde335454d7a01c94e156351410d8fa0.cpp:22:
  

Bug#722729: moodle: Please provide a Wheezy backport

[Joost van Baal-Ilić]

tag 722729 wontfix
retitle 722729 Please provide a backport
thanks

As Thijs wrote in sept 2013: "We use the package on Wheezy".  We still do that,
as of now, on wheezy / oldstable.  As Thijs, I don't believe investing time in
supplying a formal backport is wise.

Bye,

Joost

-- 
Joost van Baal-Ilić   http://abramowitz.uvt.nl/
 Tilburg University
mailto:joostvb.uvt.nl   The Netherlands


signature.asc
Description: Digital signature