date:20151217

Bug#807527: initramfs-tools: Please provide an API or best practices for custom initramfs hook configuration

2015-12-17 Thread Jonas Meurer

Am 11.12.2015 um 15:35 schrieb Guilhem Moulin:
> On Fri, 11 Dec 2015 at 00:54:03 +, Ben Hutchings wrote:
>> On Thu, 2015-12-10 at 12:15 +0100, Jonas Meurer wrote:
>>> Hi there,
>>>
>>> On Thu, 10 Dec 2015 02:52:11 +0100 Guilhem Moulin 
>>> wrote:
 AFAIK there is no documentation for where users should set variables to
 configure an initramfs hook.  There are a couple of workaround, all
 hacky and/or relying on undocumented properties of initramfs-tools(8):

   1/ Setting said variable in initramfs.conf(5).  (Since hook scripts
  are executed is sub-shells the variable need to be exported.)  This
  is somewhat ugly since initramfs.conf(5) is the configuration file
  *for mkinitramfs*, not for the hook files.

   2/ Using /usr/share/initramfs-tools/conf-hooks.d/$hook.  This is an
  undocumented (short of an entry in the changelog) hack.  Also
  unless that file is marked as a conffile (which violates the
  policy) user modifications are wiped upon upgrade.
>>>
>>> If I got it right (didn't find documentation about it), the current
>>> purpose of conf-hooks.d seems to be to configure *mkinitramfs* in a
>>> proper way required by the hook scripts, not to set configuration
>>> variables for the hook scripts themselves, no?
>>
>> The only documentation I'm aware of is in the changelog:
>>
>>   * mkinitramfs: Export MODULES, allows hook scripts to act accordingly.
>> (closes: #421658) Add /usr/share/initramfs-tools/conf-hooks.d for hooks
>> options on mkinitramfs run. Do not land in initramfs.
> 
> Please consider adding it to the mkinitramfs manpage, too.  Package
> maintainers can't rely on something that's only documented in the
> manpage, IMHO.

I guess that Guilhem meant "... something that's only documented in the
changelog". And I agree with him, that the purpose and limitations of
conf-hooks.d directory should be properly documented somewhere in the
mkinitramfs(8) manpage.

>> No, I am not going to add any more half-baked shell script parsing.
>> 
>> Also, it doesn't make any sense to me, to put hook-specific
>> configuration into a namespace shared across all hooks.  You can
>> always add a configuration file to your own package and source it in
>> your hook script.
> 
> Using /etc/$package/initramfs adds a useless directory level for
> packages that only ship initramfs hook and script.  The directory
> /etc/default is shared, also.

I understand that Ben will not add the solution that we prefer and
suggest. But I still believe that some "standardized" way to make a
initramfs hook script configurable would be a benefit.

Especially I don't like the idea to add yet another new config file for
the hook scripts. Thus I suggest the following: in cryptsetup, we use
the conf-hook.d/cryptroot file for both the main mkinitramfs and the
hook script configuration. Variables for the hook script will use a
special namespace (like CRYPTROOT_*) and will be exported. Moulin could
use the same scheme for dropbear (with DROPBEAR_* namespace).

Ben, would you be ok with adding the /etc/initramfs-tools/conf-hooks.d
equivalent directory in addition to
/usr/share/initramfs-tools/conf-hooks.d? That way, at least custom
changes of the hook script config would be supported in a proper way.

If we can agree on that, then the following changes would be needed in
initramfs-tools:

1/ add support for /etc/initramfs-tools/conf-hooks.d (already
   implemented in the patch I submitted)
2/ properly document purpose and limitations of conf-hooks.d directories

Cheers
 jonas

signature.asc
Description: OpenPGP digital signature

Bug#796345: transition: perl 5.22

2015-12-17 Thread Niko Tyni

On Wed, Dec 16, 2015 at 10:38:19PM +0200, Niko Tyni wrote:
> On Wed, Dec 16, 2015 at 12:47:48AM +0100, Emilio Pozuelo Monfort wrote:
> > Control: tags -1 confirmed
> 
> > Let's do this.
> 
> Thanks. I've just uploaded perl_5.22.1-1 to unstable.

We seem to have missed bugs for runtime dependencies on perl5 and
perl5-base. There are 16+2 affected packages or so if my grep-dctrl fu
is correct.

There's no particular hurry with getting rid of Provides: perl5 and
perl5-base, so I suppose I will reinstate them for now with 5.22.1-2
and file bugs so we can drop them some time later after this transition.

I'll also add Steven's workaround for #796798 (FTBFS on kfreebsd-*)
while at it.
-- 
Niko Tyni   nt...@debian.org

Bug#800771: ITP: telegram-purple -- Adds support for Telegram to libpurple

2015-12-17 Thread BenWiederhake.GitHub


Since there's somewhere a guideline saying that we should sometimes
post updates:



- Debianisation is technically complete, see
https://mentors.debian.net/package/telegram-purple


Still the same: technically complete. This is not the obstacle.


- Translation is coming along nicely, but we still desparately need
Russion and Brazilian translators:
https://www.transifex.com/telegram-purple-developers/telegram-purple/


Translations are mainly complete, at least the major ones.


- Our development branches aren't merged yet, and there are one or
two things we want to fix before pushing into Debian.


I consider 1.2.2 too incomplete to be packaged for Debian, that's why I
skip this version. I plan to RFS as soon as we reach 1.2.3.

This is NOT a call for help, just a "report".

Cheers,
Ben Wiederhake

Bug#805323: Bug #805323: graphite2 ARM HP PA FTBFS

2015-12-17 Thread Rene Engelhard

Hi Tim,

On Thu, Dec 17, 2015 at 11:37:20AM +0700, Tim Eves wrote:
>Hi Rene,
> 
>I've posted a reply to the bug directly on the [1]linux.debian.bugs.dist
>Google Group but it hasn't shown up yet. I'm not sure if it has not gone
>through or I'm being impatient, but in case it's the former:

That's probably because -bugs-dist is a Mailing list just mirrored to google
groups and -bugs-dist is not supposed to be posted directly to. (every bug gets
sent there...)

Mails to bugs go to n...@bugs.debian.org and then get recorded in the bug log
and send to the maintainer.

>The bug has been fixed in commit 594d92c0c0efbd3a87a32260f57e502200c351a7
>"Fix misaligned access on ARM and HP PA processors during collision".
> 
>It was a non-32 bit aligned 32bit read, some processors (ARM) are stricter
>about this than others (Intel), which could explain the fact it built fine
>on other BE archs.
> 
>We have been regularly testing against armhf on the Qemu Versatile Express
>emulator, under which it turns out this bug is not reproducible.  Once we
>tried with real hardware (RPi B+) it showed up.

Thanks.

Regards,

Rene

Bug#808201: DEPRECATION: this package will be replaced by ruby-minitar

2015-12-17 Thread Markus Frosch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Source: ruby-archive-tar-minitar
Version: 0.5.2-3
Severity: important

As suggested in my pkg-ruby-extras thread [1] this source will be
replaced by ruby-minitar, which is a newer version of minitar and as it
seems to be, the persitent new upstream name.

The new package will provide a transactional package
"ruby-archive-tar-minitar", and this source should be removed once
ruby-minitar is uploaded.

Comments are welcome!

Cheers
Markus Frosch

[1]
https://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2015-December/028348.html

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

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

- -- 
mar...@lazyfrosch.de / lazyfro...@debian.org
http://www.lazyfrosch.de
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJWcnA4AAoJEPJhXZqrmHtu03AH/RgR8VmGU7eg422VLPP6rg3Q
0P5vj8p9VNbDRBFgqwL/D6v6/fC8PjjtrO6a0eEb+AorVDDEHtmzH9DIJ/L19aDp
iw/tSE2A0+vIbe2mzC5ZMS43oC5aToaEcuL/pkxKaEv2tSsbbncBIjMSymuiEYQQ
NGLlFyWlik7WzCGMmUU1TP8V/dqYZGNpp5LuWlSpQV3lPuJne7O4zvizjjkT6b0r
SywSotUYkTZssYNY2yrAtu9fqxz6lwUWWUo2fjin1wkIFgHeMjwowaaMkIE5BW2X
IUK66jxg8NPzYaAdTr5Yu4jXvBGA91TAmSpEugy9QYVec4myOH/Uuxkd5yZlVPY=
=iHPN
-END PGP SIGNATURE-

Bug#808093: gnome-panel: text color is the same of background

2015-12-17 Thread Dmitry Shachnev

Control: severity -1 wishlist
Control: tags -1 -unreproducible -moreinfo
Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=759576

Hi Sandro,

On Thu, Dec 17, 2015 at 07:09:30AM +, Sandro Tosi wrote:
> using gnome-tweak-tool to set the global dark theme helped (see
> attachment) but now it's grey, while I'd rather it to be black, do you
> know how to change that value (and maybe also how to make the text in
> bold)? trying to find information about themes in gnome-fallback is so
> hard, as most of the articles are about gnome-shell :/
>
> and funnily enough, the login-after-lock-screen env has a nice black
> bar, with test in white and bold (but cant take a screenshot for
> obvious reason), that's what I want :)
>
> Thanks for your help!

I agree it would be nice if one can set both background and text colors for
the panel, so I have created an upstream bug for that. Feel free to comment
there!

If you have selected the dark theme in gnome-tweak-tool, then you can set
the background (back) to black in the preferences dialog (the text color will
remain white).

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#796345: redhat-cluster/libdlm + lvm + perl transition

2015-12-17 Thread Ferenc Wagner

Emilio Pozuelo Monfort  writes:

> On 16/12/15 00:12, Ferenc Wagner wrote:
>
>> Niko Tyni  writes:
>> 
>>> So the proper way out seems to be a separate libdlm source package, as
>>> discussed in [1]. Ferenc, do I understand right that a new pacemaker
>>> package is a blocker for this? Is that because the current pacemaker
>>> would be broken by the libdlm update?
>> 
>> No: the new DLM package depends on the new Pacemaker package.  I'm
>> already testing them, there's only some cleanup remaining before they
>> can be uploaded.  Both will go through NEW though, so it will take some
>> time.
>
> I can speed things up if they block a transition... Got an eta for this?

That sounds useful!  I expect to get pacemaker_1.1.13-1 ready for upload
today, taking some shortcuts.  I'll try to contact my usual sponsor, but
other interested parties can also step in. :)  If no serious issue
surfaces during this process, we can quickly repeat for DLM.

>> Then LVM will have to be rebuilt against the new DLM, and you
>> will be free to kick redhat-cluster out of the archive (I hope nothing
>> else depends on it).
>
> Checking reverse dependencies...
> # Broken Depends:
> gfs2-utils: gfs2-cluster [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> gfs2-utils [amd64 arm64 armel armhf i386 mips mipsel powerpc 
> ppc64el s390x]
> lvm2: clvm [amd64 arm64 armel armhf i386 mips mips64el mipsel powerpc ppc64el 
> s390x]
>
> # Broken Build-Depends:
> gfs2-utils: libccs-dev (>= 3.1.0)
> libcman-dev (>= 3.1.0)
> libdlm-dev (>= 3.1.0)
> libdlmcontrol-dev (>= 3.1.0)
> libfence-dev (>= 3.1.0)
> liblogthread-dev (>= 3.1.0)
> lvm2: libcman-dev (> 2)
>   libdlm-dev (> 2)
> ocfs2-tools: libdlm-dev
>  libdlmcontrol-dev

Thanks.  We will take care of gfs2-utils and ocfs2-tools soon, those are
also maintained by the HA team.
-- 
Regards,
Feri.

Bug#808202: ITP: pbbarcode -- annotate PacBio sequencing reads with barcode information

2015-12-17 Thread Afif Elghraoui

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team 
Control: block 787977 by -1

* Package name: pbbarcode
  Version : 0.8.0
  Upstream Author : Pacific Biosciences 
* URL : https://github.com/PacificBiosciences/pbbarcode
* License : BSD
  Programming Lang: Python
  Description : annotate PacBio sequencing reads with barcode information

The pbbarcode package provides tools for annotating PacBio sequencing reads
with barcode information. Typically, pbbarcode is called in context of a
SMRTPipe workflow as opposed to directly on the command line, however, users
are encouraged to utilize the command-line utility directly, as more options
are available.
.
This package is part of the SMRTAnalysis suite.

This package will be maintained by the Debian Med team.

Bug#807909: apt-cacher-ng: 403 when apt is trying to download appstream data

2015-12-17 Thread Laurent Bigonville


Le 14/12/15 21:30, Laurent Bigonville a écrit :

Le 14/12/15 17:24, Eduard Bloch a écrit :

Hallo,
* Laurent Bigonville [Mon, Dec 14 2015, 01:28:29PM]:

Package: apt-cacher-ng
Version: 0.8.7-1
Severity: normal

Hello,

With the new appstream package, there is a new apt hook which download
the appstream data from the debian mirror.

When apt is set to use apt-cacher-ng, I get a 403 for these .yml.gz
files.

I guess these files should be white listed and cached?

Yeah, probably. Not sure how expiration task will cope with them but we
could try following:

echo "VfilePatternEx:.*yml.gz" > /etc/apt-cacher-ng/ymltest.conf
systemctl restart apt-cacher-ng

OK this seems to work.
Ah well no, it's also downloading an iconpack in tar.gz I think and I'm 
getting the following error:


Err:14 http://ftp.nl.debian.org/debian sid/main DEP-11 64x64 Icons
  Writing more data than expected (7314093 > 7248557)

Cheers,

Laurent Bigonville

Bug#808200: game-data-packager: Quake 4 DVD details missing

2015-12-17 Thread Simon McVittie

Package: game-data-packager
Version: 43
Severity: wishlist
Tags: help

If you have an original Quake 4 DVD or other unpatched media (but not a
version that already has the patches, like the Steam release), we would
like to know the sizes, sha1sums and sha256sums of the files
that match these md5sums.

English/French/Italian/Spanish version:

a9f6a2e4bf8e193591954f75d1d39f85  q4base/game000.pk4 (unpatched/retail)
2cabddd692e214c78c20a464da43f1ef  q4base/zpak_french.pk4
4ee7eb637cde6bcfe3a9ffac5e4579dd  q4base/zpak_italian.pk4
36eee38e6c2dce12986f7192a5a996e5  q4base/zpak_spanish.pk4

Censored German version:

b4b1f8e5d3dd0a4a862453a6abf9a424  q4base/game000.pk4 (unpatched/retail)
e4c42f172ee4d81c7c43a82761e9816c  q4base/pak001.pk4
6ceb1be5ffe81a1da5795a4bd129eb85  q4base/pak002.pk4
c35fce5cb94bd4dfd5a8305ed9c93097  q4base/pak003.pk4
ce95f67b0e385683fae6d8dab28d85c5  q4base/pak004.pk4
ad9421a76cda3786c83f1e7b95196a1a  q4base/pak005.pk4
e0ef17afebbb088e7139986ba9e417d6  q4base/pak006.pk4
52cc00f832e643f51c42bafbbdf30b60  q4base/pak007.pk4
854e063fd4944bbdf10ed213b9f3a731  q4base/pak008.pk4
c66b39400bf688d8ed78222c28be3d7b  q4base/pak009.pk4
099899344357f204ff8ac9362d0986e7  q4base/pak010.pk4
c3a93f43ce0e505fa8acf12be6929f4b  q4base/pak011.pk4
684df5107936fbc0f946a2019fb7c370  q4base/pak012.pk4
b8e075ddbfc6b5cf41bc49cafd8aeaea  q4base/zpak_english.pk4

Thanks,
S

Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Christophe

I am not sure to understand correctly...
I currently have the same behavior with Stretch without sid/experimental
repository, and I see binutils is not ready to migrate from testing, so no
partial updates here I think.
I  do not understand how libc6-dev came built with an unavailable binutils
version on Stretch.

Christophe

Bug#808181: libc6: Upgrade can make the linker unusable

2015-12-17 Thread Emmanuel Charpentier

Dear developers,

I've just got bitten by this bug. About 3 millimeters from my carotid
artery...

This bugs effectively renders my system unusable for compilation
purposes : even extremely mundane uses, such as upgradng some R
packages, is now impossible.

Suggestions :

1) The gravity of this bug should be elevated : it renders the system
unusable at least for some mundane uses.
2) The upgrade to glibc should be conditioned to the upgrade of
binutils
3) A workaround should be posted on this bug report as soon as possible
(upgrade to unstable's binutils ?), and possibly publicized by larger
means (finding this bug is not obvious for pedestrian users like
me...).

Sincerely yours,

--
Emmanuel Charpentier

Bug#742429: isenkram: Please use PackageKit

2015-12-17 Thread Petter Reinholdtsen


Control: tags -1 +help

[Julian Andres Klode]
> Increasing the severity of the bug to prepare for the upcoming
> removal of aptdaemon.

Thank you for the heads up.  I have not had time to try to figure out a
replacement, and hope someone can help me out.

-- 
Happy hacking
Petter Reinholdtsen

Bug#808203: When under tests --root= and dpkg hooks don't run well together

2015-12-17 Thread Didier Roche

Package: dpkg
Version: 1.18.3

In a project (Ubuntu Make), I have my small tests running as non root,
but this one needs to install packages.
What I did until now is to use (as apt is used to fetch packages from a
local repo) a "fakeroot dpkg --root" wrapper with a local crafted
directory to simulate, add packages and architectures to test that
everything is behaving as expected. You can see that testbed setup at
https://github.com/ubuntu/ubuntu-make/blob/master/tests/small/test_requirements_handler.py#L54
for instance.

The issue started recently with pkg-config shipping a post-invoke hook
in /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config.
As this isn't running in a real chroot (I didn't want to deboostrap for
the small tests, just telling to apt and dpkg "please fetch from this
path and install there", the system config (good for testing) and hooks
are run. However, /usr/share/pkg-config-dpkghook isn't aware about
--root= option, and it's trying to do things system-wise like unlinking
some architectures pkg-config files (which fortunately fails as non root).

I wonder what's the correct way to handle this. I didn't find any way to
tell dpkg to not run the post-invoke hooks, only to add some to the
linked list of actions. I'm not even sure if this is the correct choice.
Also, as the hook is harcoding paths, I can't "hide" it as non root (as
a bindmount would enable me to).

What do you think is the best direction for such case? dpkg growing an
option for this? Having the hook being aware it's not running in a real
environment?

1 2 3 >

1 - 100 of 207 matches

Mail list logo