Bug#738855: initscripts: Skip killing process starting with @

[Dmitrijs Ledkovs]

Package: initscripts
Version: 2.88dsf-41
Severity: normal
Tags: patch

Dear Maintainer,

There is convention starting that processes whos name starts with '@'
shouldn't be killed. It is used to indicate that process is needed to
manage root device / cleanly unmount the root filesystem.

At least mdadm supports it for it's 'mdmon' process which is daemon
needed to manage containers (aka fakeraid controllers - Intel Matrix
Raid and DDF).

I've implemented a patch using pgrep, thus it's optional code in
sendsigs if pgrep is not available.

Regards,

Dimitri.

>From 79c394b5430104e208a8dffb2903d6bcc0ff2559 Mon Sep 17 00:00:00 2001
From: Dimitri John Ledkov 
Date: Thu, 13 Feb 2014 13:53:36 +
Subject: [PATCH] In sendsigs, skip killing process who's name starts with '@'.

---
 debian/changelog   |  4 
 debian/src/initscripts/etc/init.d/sendsigs | 13 +
 2 files changed, 17 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index ac3f0a0..501c6e6 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,12 @@
 sysvinit (2.88dsf-52) UNRELEASED; urgency=low
 
+  [ Petter Reinholdtsen ]
   * Replace debian/watch with file available from
 http://qa.debian.org/cgi-bin/watchfile.cgi?package=sysvinit .
 
+  [ Dimitri John Ledkov ]
+  * In sendsigs, skip killing process who's name starts with '@'.
+
  -- Petter Reinholdtsen   Thu, 13 Feb 2014 13:23:35 +0100
 
 sysvinit (2.88dsf-51) unstable; urgency=low
diff --git a/debian/src/initscripts/etc/init.d/sendsigs b/debian/src/initscripts/etc/init.d/sendsigs
index 04bd03c..2563314 100755
--- a/debian/src/initscripts/etc/init.d/sendsigs
+++ b/debian/src/initscripts/etc/init.d/sendsigs
@@ -58,6 +58,19 @@ do_stop () {
 		done
 	fi
 
+	# A convention is starting that process whos name starts with
+	# '@' shouldn't be killed by systeminit, as typically those
+	# processes are started to manage the root filesystem. Skip
+	# killing those as well.
+	#
+	# TODO: don't use pgrep...
+	#
+	if [ -x /usr/bin/pgrep ]; then
+	for pid in $(pgrep -f '^@'); do
+		OMITPIDS="${OMITPIDS:+$OMITPIDS }-o $pid"
+	done
+	fi
+
 	# Flush the kernel I/O buffer before we start to kill
 	# processes, to make sure the IO of already stopped services to
 	# not slow down the remaining processes to a point where they
-- 
1.9.rc1

Bug#738833: release.debian.org: transition tracker for python3.4 as supported

[Dmitrijs Ledkovs]

Package: release.debian.org
Severity: wishlist
User: release.debian@packages.debian.org
Usertags: transition

Dear Release team,

python3.4 is added as a supported version, please setup a tracker to
transition / rebuild packages to pick up 3.4 as supported.

I think something like that should do:

Affected: .build-depends ~ /python3(all)?-dev|python3.3|python3/
Good: .depends ~ /python3 \(<< 3\.5\)/ | (!.depends ~ /python3 \(<< 3\.5\)/ & 
.depends ~ /libpython3\.3/ & .depends ~ /libpython3\.4/) | .depends ~ 
/python3.4/
Bad: .depends ~ /python3 \(<< 3\.4\)/ | .breaks ~ /python \(>= 3\.4\)/ |
(.depends ~ /libpython3\.3/ & !.depends ~ /libpython3\.4/)

Or use same stanzas as were used for 3.2(default) + 3.3(supported)
transition.

Regards,

Dimitri.

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

Kernel: Linux 3.13.0-8-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#731594: [pkg-ntp-maintainers] Bug#731594: debian-installer: time synchronisation should be installed by default

[Dmitrijs Ledkovs]

reassign 731594 openntpd
retitle 731594 Please make openntpd package priority standard
thanks

On 7 December 2013 23:00, Thiemo Nagel  wrote:
> Hi Bdale,
>
> thank you for your input! Using openntpd sounds very good. Who is the
> person to make the decision?
>

reassigning to openntpd package.

Regards,

dmitrijs.

> Best,
> Thiemo
>
> On Sat, Dec 7, 2013 at 6:22 PM, Bdale Garbee  wrote:
>> Dmitrijs Ledkovs  writes:
>>
>>> Servers that rarely (re)configure network or boot, can also setup cron
>>> to call to ntpdate or install an NTP client daemon when they are first
>>> configured.
>>
>> FWIW, calling ntpdate from cron is a *horrible* idea.
>>
>> Since I agree that having time sync be a default part of a Debian
>> installation would be a good idea, let me put a few thoughts down here
>> and articulate what I think we should do.
>>
>> On a system like a server with at least one fixed-configuration network
>> interface, unless the hardware clock has completely failed, the initial
>> system time won't be grossly off, and just installing an ntp daemon is a
>> better plan.  Even if the hardware clock *has* failed, Debian's ntp
>> packaging uses the -g option to the daemon by default, so that once the
>> daemon has talked to enough peers/servers to know what time it is, it
>> will always slew the clock one time no matter how far off it is at
>> daemon launch.
>>
>> On a client system like a notebook that only has dynamic network
>> connectivity, and may not be on the net at all at boot, the best
>> strategy seem to be to rely on the hardware clock at boot and only worry
>> about network time sync when there's networking available.  For the past
>> couple years, I've been using the openntpd package on my notebook, which
>> has an if-up.d script that does a force-reload on each network interface
>> up event, and in practice I've been quite happy with the results.
>>
>> I looked at chrony briefly several years ago and wasn't impressed, but
>> I'm peripherally aware that it has been worked on quite a bit since then
>> and probably deserves another look.  It claims to have been specifically
>> written to handle well the case of a system that's not always on the net.
>>
>> Looking at the size of the packages, ntp is largest due to the inclusion
>> of drivers for various reference clocks, etc.  Chrony is also a very
>> large package, ntpdate is much larger than you'd expect, and openntpd is
>> quite small by comparison to either ntp or chrony.  Here are the Size:
>> and Installed-Size: values for each based on the current sid packages:
>>
>>   ntp  559578 1226
>>   chrony   395400   743
>>   ntpdate   81930   227
>>   openntpd  64068   103
>>
>> I care a lot about the size of our base install, and openntpd seems to
>> do everything I need just fine as far as I can tell.  So, without going
>> off to study chrony which I really don't know at all, if I were making
>> this decision, I'd be inclined to make openntpd standard, avoid ntpdate
>> entirely, and assume users who really want to run stratum-1 NTP servers
>> know how to install and optimally configure ntp.
>>
>> Bdale


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

Bug#731594: debian-installer: time synchronisation should be installed by default

[Dmitrijs Ledkovs]

On 7 December 2013 15:09, Thiemo Nagel  wrote:
> Hi Dmitrijs,
>
> thank you for your reply! The proposed solution sounds good, except
> for servers which rarely (re)configure their network. Is there another
> option that would work for servers, too?
>

Servers that rarely (re)configure network or boot, can also setup cron
to call to ntpdate or install an NTP client daemon when they are first
configured.

Regards,

Dmitrijs.



> Best,
> Thiemo
>
> On Sat, Dec 7, 2013 at 2:24 PM, Dmitrijs Ledkovs  wrote:
>> reassign 731594 ntpdate
>> retitle 731594 Please make ntpdate package priority standard
>> thanks
>>
>> On 7 December 2013 10:25, Thiemo Nagel  wrote:
>>>
>>> Package: debian-installer
>>> Severity: normal
>>> Tags: d-i
>>>
>>> Hello,
>>>
>>> I think that a modern OS should take care of time synchronisation without
>>> requiring user intervention. As far as I can see, Debian doesn't install any
>>> kind of NTP client by default. (I'd guess that it falls back behind Mac and
>>> Windows in this regard. Even my mobile phone synchronises time 
>>> automatically.)
>>>
>>> Thus, I'd suggest to install as part of the base system an NTP package
>>> (eg. ntp, openntpd, chrony) configured to act as client only.
>>>
>>> This issue has already been discussed nine years ago, however I believe that
>>> user's expectations have changed through the passage of time and thus a 
>>> fresh
>>> look at the topic may be warranted.
>>>
>>> http://bugs.debian.org/397649
>>>
>>
>> I fully agree that ntp client should be installed by default. Checking
>> dependencies of the available candidates (such that we can see what
>> other packages they pull into standard set):
>> * ntp - libopts25 (optional)
>> * ntpdate - all good
>> * openntpd - all good
>> * chrony - timelimit (optional)
>>
>> Nothing too scary.
>>
>> The other concern raised was people on intermittent and metered
>> connections (3G / dial-up), who may not want to have a daemon running
>> that can't do anything, nor a daemon that would establish unwanted
>> internet connections. To this extend ntpdate is the best package, as
>> it is only executed upon network configuration without a long running
>> daemon, nor periodic cron job.
>>
>> To resolve this bug report one of the above packages should become
>> priority standard. From d-i point of view, any would do =)
>>
>> I recommend for ntpdate to become such one. Therefore I am reassigning
>> this bug to package "ntpdate" for its maintainer to consider this
>> change.
>>
>> Regards,
>>
>> Dmitrijs.


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

Bug#731594: debian-installer: time synchronisation should be installed by default

[Dmitrijs Ledkovs]

reassign 731594 ntpdate
retitle 731594 Please make ntpdate package priority standard
thanks

On 7 December 2013 10:25, Thiemo Nagel  wrote:
>
> Package: debian-installer
> Severity: normal
> Tags: d-i
>
> Hello,
>
> I think that a modern OS should take care of time synchronisation without
> requiring user intervention. As far as I can see, Debian doesn't install any
> kind of NTP client by default. (I'd guess that it falls back behind Mac and
> Windows in this regard. Even my mobile phone synchronises time automatically.)
>
> Thus, I'd suggest to install as part of the base system an NTP package
> (eg. ntp, openntpd, chrony) configured to act as client only.
>
> This issue has already been discussed nine years ago, however I believe that
> user's expectations have changed through the passage of time and thus a fresh
> look at the topic may be warranted.
>
> http://bugs.debian.org/397649
>

I fully agree that ntp client should be installed by default. Checking
dependencies of the available candidates (such that we can see what
other packages they pull into standard set):
* ntp - libopts25 (optional)
* ntpdate - all good
* openntpd - all good
* chrony - timelimit (optional)

Nothing too scary.

The other concern raised was people on intermittent and metered
connections (3G / dial-up), who may not want to have a daemon running
that can't do anything, nor a daemon that would establish unwanted
internet connections. To this extend ntpdate is the best package, as
it is only executed upon network configuration without a long running
daemon, nor periodic cron job.

To resolve this bug report one of the above packages should become
priority standard. From d-i point of view, any would do =)

I recommend for ntpdate to become such one. Therefore I am reassigning
this bug to package "ntpdate" for its maintainer to consider this
change.

Regards,

Dmitrijs.


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

Bug#731543: acpid: add init script ordering for lightdm

[Dmitrijs Ledkovs]

Package: acpid
Version: 1:2.0.20-1
Severity: normal

Dear Maintainer,

please consider applying below patch, which orders acpid relative to
lightdm the same way it is ordered with respect to other display
managers (kdm, gdm3, xdm).

Regards,

Dmitrijs.

diff -u acpid-2.0.20/debian/acpid.init acpid-2.0.20/debian/acpid.init
--- acpid-2.0.20/debian/acpid.init
+++ acpid-2.0.20/debian/acpid.init
@@ -3,8 +3,8 @@
 # Provides:  acpid
 # Required-Start:$remote_fs $syslog
 # Required-Stop: $remote_fs $syslog
-# X-Start-Before:kdm gdm3 xdm
-# X-Stop-After:  kdm gdm3 xdm
+# X-Start-Before:kdm gdm3 xdm lightdm
+# X-Stop-After:  kdm gdm3 xdm lightdm
 # Default-Start: 2 3 4 5
 # Default-Stop:  
 # Short-Description: Start the Advanced Configuration and Power Interface daemon
diff -u acpid-2.0.20/debian/changelog acpid-2.0.20/debian/changelog
--- acpid-2.0.20/debian/changelog
+++ acpid-2.0.20/debian/changelog
@@ -1,3 +1,10 @@
+acpid (1:2.0.20-1.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Specify in acpid.init to start before lightdm and stop after lightdm.
+
+ -- Dmitrijs Ledkovs   Fri, 06 Dec 2013 13:57:00 +
+
 acpid (1:2.0.20-1) unstable; urgency=low
 
   * Imported Upstream version 2.0.20 (Closes: #719659)

Bug#730636: [Debian-med-packaging] Bug#730636: Fwd: Debian Bug "Do not always set CMAKE_BUILD_TYPE to Release"

[Dmitrijs Ledkovs]

On 5 December 2013 11:50, Mathieu Malaterre  wrote:
> Control: tags -1 = wontfix
>
>
> -- Forwarded message --
>
>
> Hi Mathieu,
>
> regarding this bug:
>
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730636
>
> I talked to JC from Kitware (who contributed the patch), and his advice
> is the following:
>
>> After setting the env:
>>
>> export CXXFLAGS=
>>
>> and configuring passing
>>
>> -DCMAKE_BUILD_TYPE:STRING=None
>>
>>
>> None of the default flags related to either Debug, Release,
>> RelWithDebInfo, .. are used. Only the one specified using CXXFLAGS.
>> This was confirmed after doing a small experiment.

BUILD_TYPE:STRING=None is the cmake default. One shouldn't
override/reselect anything else. Please see CMake documentation.
Default BUILD_TYPE shouldn't change across different packages using
CMake, as that breaks transparent inclusion / building CMake packages.
If such change is desired, it should be done by CMake, in CMake
upstream, not on per package change.
This will bite us later on...

=(


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

Bug#606825: mingw-w64 triplets/ostable

[Dmitrijs Ledkovs]

On 3 December 2013 22:42, Stephen Kitt  wrote:
> Hi Guillem,
>
> On Sat, Aug 11, 2012 at 03:34:07PM +0200, Stephen Kitt wrote:
>> On Wed, 8 Aug 2012 13:01:03 +0200, Guillem Jover  wrote:
>> > Sorry, I thought I had replied but it appears that was not the case,
>> > it was on my radar to come back to it anyway, thanks for the reminder.
>> >
>> > The main issue I have with this request is that the upstream triplet just
>> > seems wrong, as it encodes part of the ABI in the vendor field. That's
>> > AFAIR, from reading the thread back then.
>> >
>> > For dpkg tools the vendor is irrelevant, and having to take it into
>> > account would imply changing the underlaying infrastructure which
>> > might not be a problem per se, if the reason for requiring this wan't
>> > wrong.
>>
>> I take it you're referring to the "w64" portion, differenciating MinGW-w64
>> from MinGW? I've been using the attached patch (which I'll explain further
>> down...) with pretty good results; what would break in dpkg if we wanted
>> correct support for the vendor? Currently I can specify "mingw64-x86" as an
>> architecture; wouldn't it be possible to have a "mingw-x86" architecture,
>> with the appropriate entries in triplettable and ostable, for MinGW support
>> without any other changes?
>>
>> > I'm not sure if it's too late now to consider changing the triplet
>> > upstream, I should probable have brought this up long time ago, but
>> > then it seemed to be pretty settled down already. :/
>>
>> I think it is too late, everyone else (MinGW-w64, the many projects using
>> it, and the various other distributions supporting it) has already switched
>> to it.
>>
>> > OTOH, is dpkg buildable and usable at all on mingw-w64 systems? I
>> > understand though that there might be reasons to want the architecture
>> > supported so that cross-building is allowed, but then the request does
>> > not seem pressing, and that's one of the reasons I've not acted on it
>> > before.
>>
>> As Dmitrijs explained in his reply, all the MinGW-w64 stuff in Debian is
>> likely to only ever support cross-compilation, not end up being a full
>> architecture hosted on Windows. The main reason to have the support in dpkg
>> is to start building the infrastructure required for a partial architecture,
>> so we can more easily provide libraries etc. (see for example
>> http://bugs.debian.org/671437).
>
> Is there any chance the attached version could go in? It's against
> current git, minus the previous changes to cputable which were wrong.
>
> Now that Debian is increasingly cross-buildable, and with sbuild and
> cross-build-essential providing an excellent environment to work in,
> it would be great to have mingw-w64 support in dpkg... Unless you have
> objections of course!
>

I've carefully reviewed the whole thread and re-reviewed the proposed patch:

* vendor tag is _not_ used to encode API/ABI, GNU_SYSTEM is
"w64-mingw32" - GOOD (agreed by everyone in the thread)
* Debian.pm is correctly patched to disable features, which are not
support - GOOD
* no changes to cputable - GOOD [2]

Another point raised was:
* dpkg ported to w64-mingw32

Actually at the moment that's not needed at all, as at this stage
w64-mingw32 port will be purely cross-compiled and multiarch enabled
only, therefore dpkg is needed for the build_os.
Naturally building as many packages for w64-mingw32 platform as
possible will be a priority.

Please include patch as attached at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606825#182

If there are any other questions / concerns, please raise them now.


[1] if any bugs would arise from that, the porting team will provide
patches / upstream fixes as needed. in practice, we don't expect any
from well-behaved software.
[2] as noted in #611741, a generic implementation is not yet available
to map/select baseline CPU features on a per debian architecture (e.g.
i486 vs i686, ARMv5 vs ARMv6 vs ARMv7hf etc)


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

Bug#699434: grub-installer: support for Intel Matrix Raid

[Dmitrijs Ledkovs]

Hello again,

On 31 January 2013 12:40, Miquel van Smoorenburg  wrote:
> Package: grub-installer
> Version: 183
> Tags: patch
>
> See metabug 699430, http://bugs.debian.org/699430 :
> (debian-installer: support for Intel Matrix Raid (RST, imsm)
>
>   * Support for mdadm fakeraid (currently only IMSM formatted disks):
> - also detect mdadm fakeraid underneath lvm, if it's just one array
> - install grub on each disk of the underlying array
> - add md/0 entry to device.map so grub-probe works (for upgrades etc)
>

I've tried to perform a RAID0 & RAID1 stripped IMSM installation,
without LVM layer and grub-installer failed both times. I will
experiment more, cause I was staring out with incomplete intel raid
with leftover partitions/bootloaders.

Regards,

Dmitrijs.


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

Bug#699434: grub-installer: support for Intel Matrix Raid

[Dmitrijs Ledkovs]

Hello Miquel,

On 31 January 2013 12:40, Miquel van Smoorenburg  wrote:
> This is by far the most intrusive patch - all the others are trivial.
> Description:
>
> - move make_device_map() upwards so that we can call it earlier
>   in the script. Also, if $md_bootdev is set, add a (otherwise
>   unused) "(md/0)" entry to device.map - otherwise grub-probe
>   freaks out on upgrades.
> - add is_mdraid_bootable(). It checks if the device is a Intel
>   Matrix Raid device, in RAID1 mode. If not it returns false.
>   Otherwise it sets $md_dev, $md_devs, $md_super and $md_level,
>and returns true.


Why is it limited to only imsm && raid1 ?

mdadm supports "imsm" superblock format levels 0,1,5,10 & "ddf"
superblock format levels 0,1,3,4,5,1E,5E,5EE,6 with extensions of
there off (stripped, mirrored, concatenated and spanned).

Would it not be best to simply check for "imsm" || "ddf" superblock
types? Given that mdadm supports most of the above RAID levels.

All other changes look good.

Regards,

Dmitrijs.

> - if installing on an lvm device, it finds the underlying device,
>   and checks if it's a single mdraid array. If so $disc_under_lvm
>   is set.
> - if we're installing on a mdraid device and is_mdraid_bootable()
>   is true, we set $disc_offered to the mdraid device, and set
>   the $default_bootdev variable to all the underlying real disks.
> - when installing on an mdraid device, always create the grub device.map
> - do not try to guess the bootdevice if we already set $default_bootdev
>
> Note that effectively this patch does NOT change any existing
> behaviour if you are not trying to install on an Intel Matrix Raid
> RAID1 array. As that wasn't supported before anyway, there is
> no chance on regression.
>
> Thanks
>
> diff -ruN 00-ORIG/grub-installer-1.83/debian/changelog 
> grub-installer-1.83/debian/changelog
> --- 00-ORIG/grub-installer-1.83/debian/changelog2012-10-27 
> 06:07:35.0 +
> +++ grub-installer-1.83/debian/changelog2013-01-29 15:03:58.462971942 
> +
> @@ -1,3 +1,12 @@
> +grub-installer (1.83+1) unstable; urgency=low
> +
> +  * Support for mdadm fakeraid (currently only IMSM formatted disks):
> +- also detect mdadm fakeraid underneath lvm, if it's just one array
> +- install grub on each disk of the underlying array
> +- add md/0 entry to device.map so grub-probe works (for upgrades etc)
> +
> + -- Miquel van Smoorenburg   Tue, 29 Jan 2013 15:50:37 
> +0100
> +
>  grub-installer (1.83) unstable; urgency=low
>
>[ Milan Kupcevic ]
> diff -ruN 00-ORIG/grub-installer-1.83/grub-installer 
> grub-installer-1.83/grub-installer
> --- 00-ORIG/grub-installer-1.83/grub-installer  2012-10-25 01:01:57.0 
> +
> +++ grub-installer-1.83/grub-installer  2013-01-29 14:56:40.103337917 +
> @@ -217,6 +217,69 @@
> echo "$ids"
>  }
>
> +make_device_map () {
> +   # If you're preseeding (hd0) et al, stop - preseed OS device names
> +   # instead.  However, for backward compatibility we ensure that a
> +   # device.map exists if you do this.
> +   [ "$grub_version" = grub2 ] || return 0
> +   [ ! -e "$device_map" ] || return 0
> +   local no_floppy
> +   case $1 in
> +   \(fd*|fd*)
> +   no_floppy=
> +   ;;
> +   *)
> +   no_floppy=--no-floppy
> +   ;;
> +   esac
> +   $chroot $ROOT grub-mkdevicemap $no_floppy
> +   if [ -n "$md_bootdev" ]
> +   then
> +   # This is lame- shouldn't need this, but otherwise
> +   # grub-probe freaks out.
> +   echo "(md/0)$md_bootdev" >> $ROOT/boot/grub/device.map
> +   fi
> +}
> +
> +is_mdraid_bootable () {
> +   local device="$1"
> +   local mddisk=${device#/dev/}
> +   local super
> +   local level="`cat /sys/block/$mddisk/md/level 2>/dev/null ||:`"
> +   local array_metadata="`cat /sys/block/$mddisk/md/metadata_version 
> 2>/dev/null ||:`"
> +   case "$array_metadata" in
> +   external:/md*)
> +   local ctdisk=${array_metadata#external:/}
> +   ctdisk=${ctdisk%/*}
> +   super="`cat /sys/block/$ctdisk/md/metadata_version 
> 2>/dev/null ||:`"
> +   super=${super#external:}
> +   ;;
> +   esac
> +   # Right now mdadm only supports imsm fakeraid, and grub doesn't know
> +   # about it at all but raid1 works regardless. So restrict to imsm + 
> raid1.
> +   if [ "$level" = raid1 ] && [ "$super" = "imsm" ]
> +   then
> +   # Find the disks that make up the array to that grub can
> +   # be installed onto all of them. As soon as grub supports
> +   # imsm raid we should be able to install directly to the
> +   # md device instead.
> +   local mddisks="`echo /sys/block/$mddisk/md/dev-* |
> +   

Bug#730636: [Debian-med-packaging] Bug#730636: Do not always set CMAKE_BUILD_TYPE to Release

[Dmitrijs Ledkovs]

On 28 November 2013 10:34, Jörg Riesmeier  wrote:
>> dcmtk package is trying to set CMAKE_BUILD_TYPE to Release instead of
>> letting the user decide what best to use.
>> It would be nice to have an option to override this default, as Debian
>> requires specific compilation flags, which conflicts with what
>> CMAKE_BUILD_TYPE:Release sets.
>
>> I am attaching current patch.
>
> Your patch removes a patch that was contributed only recently by Jean-
> Christophe Fillion-Robin from Kitware (i.e. the publisher of CMake):
>
>   
> http://git.dcmtk.org/web?p=dcmtk.git;a=commit;h=1beff6732f65c4e364acbd7d4643a02ed02f82ee
>
> Also, as far as I can see, the "IF(NOT CMAKE_BUILD_TYPE AND NOT
> CMAKE_CONFIGURATION_TYPES)" statement should make sure that the build type is
> only set if it was undefined.
>
> Don't you agree?
>

No. In Debian, we want environment CFLAGS/CXXFLAGS etc to be honered
such that distribution default options are used (optimised with debug
symbols), hardenning-wrapper / buildflags.mk are applied, and if users
choose to rebuild with DEB_BUILD_OPTIONS (e.g. nostrip, etc) those are
also honred. In cmake buildtypes by default that matches to _not_
specifying any buildtype, such that cmake falls back to "default"
build type, in which case environment flags are used. There is no way
for upstream to guess/pick all of those combinations of options that
by policy all packges in Debian should support.

Regards,

Dmitrijs.


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

Bug#730650: samba: wheezy -> jessie upgrades may fail

[Dmitrijs Ledkovs]

Package: samba
Version: 2:4.0.10+dfsg-2
Severity: important

Dear Maintainer,

I did a couple simple upgrade tests from wheezy -> jessie and here are
results I got.

If wheezy chroot has "samba" package install -> upgrade to jessie "samba"
succeeds.

If wheezy chroot has "samba4" package install, upon upgrade "samba4"
package is removed, but its replacement, "samba", is not installed.

If wheezy chroot has "samba" and "samba4" packages installed, upon upgrade,
both are removed and samba-common-bin is held back.

It seems to me that: "samba4", "samba4-common-bin", "samba4-clients",
"samba4-testsuite", "winbind4" dummy transitional packages should be
provided by the src:samba/jessie package, such that systems with all
combinations of installed binaries from (src:samba/wheezy,
src:samba4/wheezy) are upgraded/migrated to binary packages from
src:samba/jessie.

Regards,

Dmitrijs.


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

Bug#730258: please add arch-specific BTS tags

[Dmitrijs Ledkovs]

On 23 November 2013 21:53, Don Armstrong  wrote:
> On Sat, 23 Nov 2013, Ivo De Decker wrote:
>> During a discussion about architecture qualification, the release team
>> concluded that it would be interesting to have a better way to track
>> architecture-specific bugs. It would be nice to have BTS tags for each
>> architecture that is currently in the archive. It might also make
>> sense to have tags for the architectures on debian-ports, to be able
>> to filter issues about these easily.
>
> This sounds reasonable; are only tags required, or do we need more
> infrastructure than that?
>
> These are the list of ports that I see:
>
> amd64
> armel
> armhf
> hurd-i386
> i386
> ia64
> kfreebsd-amd64
> kfreebsd-i386
> mips
> mipsel
> powerpc
> s390x
> sparc
> avr32
> sh
>
> What else am I missing? [I note that
> http://www.debian.org/ports/#portlist-released seems to have a
> reasonable list of ports, and
> http://anonscm.debian.org/viewvc/webwml/webwml/english/releases/sid/archive.data?view=markup
> has another; I'd like to reference a canonical location for ports
> (perhaps maintained by debian-ports or similar) so I don't have to
> figure out for myself which ports need a tag and what that tag should
> be, and which ports are just duplicates of other ports, and therefore
> don't need a tag.
>

There are 484 reports usertagged "debian-...@lists.debian.org arm64".
Please consider including "arm64" tag.

Regards,

Dmitrijs.


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

Bug#729698: libc0.1: wait6 is broken on 9.2+

[Dmitrijs Ledkovs]

The fix for this issue has been committed upstream:
http://svnweb.freebsd.org/base?view=revision&revision=258281

Can this be cherry picked into 9.2 kernel? Should this also be
included in the 10 & 11 kernels, or do those stay in experimental /
tracking svn head?

I can prepare the debdiffs.

Regards,

Dmitrijs.


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

Bug#729445: Workaround

[Dmitrijs Ledkovs]

On 19 November 2013 17:21, Martin Michlmayr  wrote:
> Here's a workaround for partman-basicfilesystem but obviously it would
> be nice if this could get fixed properly.
>

Very clever! =) i think to be honest, this is good enough.

Regards,

Dmitrijs.


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

Bug#729697: libc0.1: wait6 is broken on 9.2+

[Dmitrijs Ledkovs]

Package: libc0.1
Severity: serious

Dear Maintainer,
FreeBSD 9.2+ kernels have broken implementation of wait6 syscall.
In particular:
* if pointer to siginfo_t structured is passed
* and WEXITED is ORed in options

The return value of siginfo_t.si_status is wrong.

It is returned the same as "status", instead of result of
WEXITSTATUS(status).

Thus this is an "off-by-one" error, or more precisely off-by-bitmask
error.

A PR has been filed in FreeBSD at:
http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/184002

Affected kernels are 9.2+ all the way to HEAD.

I've chatted with developers on #bsddev and they are recognising that
this is a severe bug, as current behaviour doesn't comply with
freebsd/linux manpages, POSIX, other implmentations of waitid.

Furthermore, it appears that other functions that set values of
siginfo_t.si_status incorrectly in other parts of FreeBSD kernels.
E.g. sigwaitinfo() from stable/8 onwards...

The wait6 / waitid() calls are added in the eglibc2.18 debian packaging
branch. Therefore I request to do following:

* make wait6() a proper wrapper around wait6 syscall and correct
  si_status.

* make waitid implementation use the wait6() wrapper

An example patch against current waitid patch, as I don't know how to
make proper syscall wrapper functions, is attached.

Please advice if Debian kFreeBSD maintainers are willing to patch this
issue in the kernels ahead of FreeBSD releasing fixes / updates (at
least for the wait6 syscall)

Regards,

Dmitrijs.


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

Bug#729660: ITP: xemacs21 -- highly customizable text editor

[Dmitrijs Ledkovs]

On 15 November 2013 12:02, Mark Brown  wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mark Brown 
>
> * Package name: xemacs21
>   Version : 21.4.22
>   Upstream Author : XEmacs development team
>   URL : http://www.xemacs.org/
>   License : GPL
>   Programming Lang: C, elisp
>   Description : highly customizable text editor
>
> XEmacs is a full fledged programming language with a mail reader,
> news reader, info browser, web browser, calendar, specialized editor
> for more programming languages and other formats than most people
> encounter in a lifetime, and much more.
>
> While develoment on xemacs is very slow these days I find it much more
> visually pleasing than GNU emacs.
>

Why should Debian carry this package?

Which virtual packages are you planning to provide?

Regards,

Dmitrijs.


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

Bug#729344: lives: Incomplete port to libav 9

[Dmitrijs Ledkovs]

Package: lives
Severity: important
Version: 2.0.6~ds0-1
Tags: patch

Dear Maintainer,
I believe lives port to libav9 is incomplete, as build logs indicate
plenty of implicitly defined functions of deprecated libav APIs.

You can see some of them picked up by the automatic log scanner:
http://qa.debian.org/bls/packages/l/lives.html

I've started porting lives to libav 9, here is (probably incomplete) patch.

Regards,

Dmitrijs.

===File /tmp/lives-2.0.6~ds0/debian/patches/more-libav9.patch===
Description: Partial patch porting to libav 9.
Author: Dmitrijs Ledkovs 

--- lives-2.0.6~ds0.orig/lives-plugins/plugins/decoders/flv_decoder.c
+++ lives-2.0.6~ds0/lives-plugins/plugins/decoders/flv_decoder.c
@@ -754,7 +754,7 @@ static boolean attach_stream(lives_clip_
 
   if (!hasaudio) got_astream=TRUE;
 
-  priv->ctx=ctx = avcodec_alloc_context();
+  priv->ctx=ctx = avcodec_alloc_context3(NULL);
 
   sprintf(cdata->audio_name,"%s","");
 
--- lives-2.0.6~ds0.orig/lives-plugins/plugins/decoders/asf_decoder.c
+++ lives-2.0.6~ds0/lives-plugins/plugins/decoders/asf_decoder.c
@@ -1106,7 +1106,7 @@ static boolean attach_stream(lives_clip_
 
   pos1 = priv->input_position;
 
-  priv->st = av_new_stream(priv->s, 0);
+  priv->st = avformat_new_stream(priv->s, NULL);
 
   if (!priv->st) {
fprintf(stderr, "asf_decoder: Unable to create new stream for 
%s\n",cdata->URI);
--- lives-2.0.6~ds0.orig/lives-plugins/plugins/decoders/mpegts_decoder.c
+++ lives-2.0.6~ds0/lives-plugins/plugins/decoders/mpegts_decoder.c
@@ -1008,7 +1008,7 @@ static int mpegts_set_stream_info(lives_
return AVERROR(ENOMEM);
   memcpy(sub_pes, pes, sizeof(*sub_pes));
 
-  sub_st = av_new_stream(pes->stream, pes->pid);
+  sub_st = avformat_new_stream(pes->stream, NULL);
   if (!sub_st) {
av_free(sub_pes);
return AVERROR(ENOMEM);
@@ -1191,7 +1191,7 @@ static int mpegts_push_data(lives_clip_d
 
  /* stream not present in PMT */
  if (!pes->st) {
-   pes->st = av_new_stream(ts->stream, pes->pid);
+   pes->st = avformat_new_stream(ts->stream, NULL);
if (!pes->st)
  return AVERROR(ENOMEM);
pes->st->id = pes->pid;
@@ -1989,7 +1989,7 @@ static void pmt_cb(lives_clip_data_t *cd
 if (ts->pids[pid] && ts->pids[pid]->type == MPEGTS_PES) {
   pes = ts->pids[pid]->u.pes_filter.opaque;
   if (!pes->st) {
-   pes->st = av_new_stream(pes->stream, pes->pid);
+   pes->st = avformat_new_stream(pes->stream, NULL);
pes->st->id = pes->pid;
   }
   st = pes->st;
@@ -1997,7 +1997,7 @@ static void pmt_cb(lives_clip_data_t *cd
   if (ts->pids[pid]) mpegts_close_filter(ts, ts->pids[pid]); //wrongly 
added sdt filter probably
   pes = add_pes_stream(ts, pid, pcr_pid);
   if (pes) {
-   st = av_new_stream(pes->stream, pes->pid);
+   st = avformat_new_stream(pes->stream, NULL);
st->id = pes->pid;
   }
 } else {
@@ -2005,7 +2005,7 @@ static void pmt_cb(lives_clip_data_t *cd
   if (idx >= 0) {
st = ts->stream->streams[idx];
   } else {
-   st = av_new_stream(pes->stream, pid);
+   st = avformat_new_stream(pes->stream, NULL);
st->id = pid;
st->codec->codec_type = AVMEDIA_TYPE_DATA;
   }
@@ -2536,7 +2536,7 @@ static int lives_mpegts_read_header(live
 
 /* only read packets */
 
-st = av_new_stream(s, 0);
+st = avformat_new_stream(s, NULL);
 if (!st)
   goto fail;
 av_set_pts_info(st, 60, 1, 2700);
@@ -3064,7 +3064,7 @@ static boolean attach_stream(lives_clip_
 return FALSE;
   }
 
-  priv->ctx = ctx = avcodec_alloc_context();
+  priv->ctx = ctx = avcodec_alloc_context3(NULL);
 
   if (avcodec_open(ctx, codec) < 0) {
 fprintf(stderr, "mpegts_decoder: Could not open avcodec context\n");
--- lives-2.0.6~ds0.orig/lives-plugins/plugins/decoders/mkv_decoder.c
+++ lives-2.0.6~ds0/lives-plugins/plugins/decoders/mkv_decoder.c
@@ -1429,7 +1429,7 @@ static int lives_mkv_read_header(lives_c
   }
 }
 
-st = track->stream = av_new_stream(s, 0);
+st = track->stream = avformat_new_stream(s, NULL);
 if (st == NULL) {
   fprintf(stderr,
  "mkv_decoder: Out of memory\n");
@@ -1748,7 +1748,7 @@ static boolean attach_stream(lives_clip_
 return FALSE;
   }
 
-  priv->ctx = ctx = avcodec_alloc_context();
+  priv->ctx = ctx = avcodec_alloc_context3(NULL);
 
   if (avcodec_open(ctx, codec) < 0) {
 fprintf(stderr, "mkv_decoder: Could not open avcodec context for codec\n");



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

Bug#729341: yaml-cpp: Incompatible API, please re-upload 0.3.x series

[Dmitrijs Ledkovs]

Package: yaml-cpp
Severity: important
Version: 0.5.1-1

Dear Maintainer,

yaml-cpp 0.5.x series introduce overhauled API which almost completely
non-backwards compatible. While some projects migrated to 0.5.x api,
others have not. Their respective upstreams also stated that it is on
the roadmap, but hard to do at the moment.

To mitigate the problem, several distributions have re-introduced
yaml-cpp0.3 package.

Please consider re-uploading yaml-cpp0.3 source package that provides
yaml-cpp0.3 and yaml-cpp0.3-dev.

See following bug reports:
rivet FTBFS - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724223
opencolorio FTBFS -
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725533

Regards,

Dmitrijs.


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

Bug#729012: sbuild: unset more unneeded environment variables

[Dmitrijs Ledkovs]

Package: sbuild
Version: 0.64.0-1
Severity: normal
Tags: patch

Dear Maintainer,

during package builds I noticed my current desktop session variables
leaking into the build-logs. This has been fine, until unit-tests
started to interact with my current session's XDG_RUNTIME_DIR.

Please consider removing a few more variables at unset_env() time. Patch
is attached.

Regards,

Dmitrijs.

>From f9110d36d5d4ac425aa1354eda4feb96767eeb2a Mon Sep 17 00:00:00 2001
From: Dmitrijs Ledkovs 
Date: Thu, 7 Nov 2013 22:00:08 +
Subject: [PATCH] Unset more unneeded typical desktop variables.

They are mostly harmless, sometimes unit-tests of package under build
interracts badly with current session via those variables
(e.g. RUNTIME_DIR).
---
 lib/Buildd.pm | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/Buildd.pm b/lib/Buildd.pm
index 420e724..c2a04df 100644
--- a/lib/Buildd.pm
+++ b/lib/Buildd.pm
@@ -77,6 +77,10 @@ sub unset_env () {
 # other unneeded variables that might be set
 delete $ENV{'DISPLAY'};
 delete $ENV{'TERM'};
+delete $ENV{'XDG_RUNTIME_DIR'};
+delete $ENV{'XDG_SEAT'};
+delete $ENV{'XDG_SESSION_ID'};
+delete $ENV{'XDG_VTNR'};
 }
 
 sub lock_file ($;$) {
-- 
1.8.4.2

Bug#720188: kfreebsd: please implemente/expose waitid function & wait6 syscall

[Dmitrijs Ledkovs]

On 20 August 2013 07:26, Petr Salinger  wrote:
>>> It is planned, but (e)glibc 2.18 upload have to go first, due to changes
>>> of
>>> idtype_t values. See also 218_waitid* in
>>> http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/
>>>
>>> We also have to provide (reasonable) fallback implementation
>>> under wheezy kernels.
>>
>>
>> Cool! Excellent stuff! I've tried applying 218_waitid* things against
>> the eglibc-package as is in the debian trunk (2.17 based) and failed
>> to compile it properly.
>> Is there a way for me to compile debs
>
>
> The 218_waitid_common.diff is against main tree,
> the 218_waitid_kbsd.diff is against kfreebsd/ subdir
> and 218_waitid.c have to be placed as waitid.c in kfreebsd/ subdir.
>
> It worked a month ago ;-)


Right, and it still "works", well at raising system errors =) I've now
tried it from the eglibc-2.18 packaging branch.

I've tried adding wait6 syscall & implementing waitid using it, but it
didn't quite managed to make it compile (i got linker errors waying it
cannot find __GI___syscall_wait6).

Can we set minimal kfreebsd kernel version when configuring/compiling
eglibc such that if compatibility with older freebsd kernels is needed
the wrapper implementation is used,
otherwise if compiled for freebsd kernels >= 9.2, wait6 version is
used? And then distributions, e.g. kfreebsd/Debian can choose where to
cut the line.

Can you see what I have done wrong? (it's my first time trying to hack on glibc)

Regards,

Dmitrijs.
--- foo/eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/syscalls-inline.h	2013-11-01 12:33:10.0 +
+++ eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/syscalls-inline.h	2013-11-01 01:12:34.0 +
@@ -45,14 +45,16 @@
 
 int __syscall_fcntl(int fd, int cmd, ...);
 int __syscall_fork(void);
 int __syscall_wait4(int pid, int *status, int options, struct rusage *rusage);
+int __syscall_wait6(idtype_t itype, id_t id, int *status, int options, struct rusage *rusage, siginfo_t *infop);
 int __syscall_sigsuspend (const sigset_t *set);
 int __syscall_sigprocmask (int how, const sigset_t *set, sigset_t *oldset);
 int __syscall_nanosleep (const struct timespec *requested_time, struct timespec *remaining);
 libc_hidden_proto (__syscall_fcntl)
 libc_hidden_proto (__syscall_fork)
 libc_hidden_proto (__syscall_wait4)
+libc_hidden_proto (__syscall_wait6)
 libc_hidden_proto (__syscall_sigsuspend)
 libc_hidden_proto (__syscall_sigprocmask)
 libc_hidden_proto (__syscall_nanosleep)
 
--- foo/eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/syscalls.list	2013-11-01 12:33:10.0 +
+++ eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/syscalls.list	2013-11-01 01:07:26.0 +
@@ -206,7 +206,8 @@
 unlinkat		-	unlinkat		i:isi		unlinkat
 unmount			-	unmount			i:si		unmount
 utrace			-	utrace			i:bn		utrace
 wait4			-	wait4			i:iWiP		__syscall_wait4 __wait4	wait4
+wait6			-	wait6			i:iiWiPP		__syscall_wait6 __wait6	wait6
 sys_write		-	write			i:ibn		__syscall_write
 sys_writev		-	writev			i:ipi		__syscall_writev
 yield			-	yield			i:		__syscall_yield
--- foo/eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/waitid.c	2013-11-01 12:33:10.0 +
+++ eglibc-2.18/ports/sysdeps/unix/bsd/bsd4.4/kfreebsd/waitid.c	2013-11-01 01:26:07.0 +
@@ -21,15 +21,33 @@
 #include 
 #include 
 #include 
 
-/* for now only the wrapper implementation */
-/* later on we will try to use wait6 when available */
+extern int __syscall_wait6 (idtype_t itype, id_t id,
+			int *status, int options,
+			struct rusage *rusage, siginfo_t *infop);
+libc_hidden_proto (__syscall_wait6)
 
 #define waitid __unused_waitid_alias
+static inline int
+do_waitid (idtype_t idtype, id_t id, siginfo_t *infop, int options)
+{
+  int ret;
+  int status;
+  
+  ret = INLINE_SYSCALL (wait6, 6, idtype, id, &status, options, NULL, infop);
+
+  if (ret > 0)
+ret = 0;
+
+  return ret;
+}
+
+#define NO_DO_WAITID
 #include 
 #undef waitid
 
+
 versioned_symbol (libc, __waitid, waitid, GLIBC_2_18);
 
 #if SHLIB_COMPAT (libc, GLIBC_2_1, GLIBC_2_18)
 

Bug#719484: [pkg-boost-devel] Bug#719484: Bug#719484: boost1.54: FTBFS

[Dmitrijs Ledkovs]

On 30 October 2013 21:16, Mikael Pettersson  wrote:
> Thorsten Glaser writes:
>  > Steve M. Robbins dixit:
>  >
>  > >Interesting, but this is an entirely different bug.  Also, this new bug 
> is in
>  > >gcc, not boost.
>  >
>  > Sorry, right. I’m just amazed that the boost compilation is
>  > still continuing, and replied to the mail “thread” we already
>  > had so we have the information in one place.
>  >
>  > I’ll follow this up on debian-68k@l.d.o for now, so you’re
>  > not “spammed” with this particular thing.
>  >
>  > Mikael: I could reproduce this with a crosscompiler with
>  > -g -O3 -fPIC where -fPIC is the culprit. Lowering to -O1
>  > also let us get rid of the ICE whereas removing -g had
>  > no effect, so the minimum to trigger it is -O2 -fPIC.
>  >
>  > bye,
>  > //mirabilos
>
> The GCC ICE bug is now fixed on GCC trunk by r204224, see
> .
> That patch backports trivially to gcc-4.8.2 and fixes the ICE
> there too.
>
> I'll try to get it into the gcc-4.8.3 release, but that's about
> half a year or so away.
>

doko pulls updates from stable svn release branches. It only needs to
be committed to 4.8 release branch and then gcc package refresh
uploaded which is done often.

Regards,

Dmitrijs.


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

Bug#716855: libucomon-dev: Dependency on libgnutls28-dev makes sflphone unbuildable

[Dmitrijs Ledkovs]

Control: tag patch

I think the problem here is not about making sflphone unbuildable, but
unfortunate licensing of libgnutls28.

It has moved from LGPL2.1 to LGPL3, and thus became incompatible with
any other GPLv2 code. Since ucomomn has so many reverse-dependencies,
this essentially forces many packages out of the archive. I haven't
done full analysis of all reverse-dependencies in the archive, but
even if there are none it would be nice to keep libraries with a more
compatible licenses, instead of more restricting ones.

The patch to fix FTBFS against GnuTLS 2.6 is trivial, and is attached
with this email.

Please consider reverting and making libucommon build and link against
GnuTLS 2.6.

Regards,

Dmitrijs.
diff -Nru ucommon-6.0.7/debian/control ucommon-6.0.7/debian/control
--- ucommon-6.0.7/debian/control	2013-08-02 09:27:21.0 +
+++ ucommon-6.0.7/debian/control	2013-10-30 12:34:56.0 +
@@ -10,7 +11,7 @@
  debhelper (>= 9~),
  dh-buildinfo,
  pkg-config,
- libgnutls28-dev,
+ libgnutls-dev,
  d-shlibs (>= 0.45~),
  graphviz
 Build-Depends-Indep: doxygen-latex
diff -Nru ucommon-6.0.7/debian/patches/fix-gnutls2.6.patch ucommon-6.0.7/debian/patches/fix-gnutls2.6.patch
--- ucommon-6.0.7/debian/patches/fix-gnutls2.6.patch	1970-01-01 00:00:00.0 +
+++ ucommon-6.0.7/debian/patches/fix-gnutls2.6.patch	2013-10-30 12:35:21.0 +
@@ -0,0 +1,14 @@
+Description: Fix building ucommon against gnutls2.6.
+Author: Dmitrijs Ledkovs 
+
+--- ucommon-6.0.7.orig/gnutls/local.h
 ucommon-6.0.7/gnutls/local.h
+@@ -37,7 +37,7 @@ class __LOCAL context : public secure
+ public:
+ ~context();
+ 
+-unsigned int connect;
++gnutls_connection_end_t connect;
+ gnutls_credentials_type_t xtype;
+ gnutls_certificate_credentials_t xcred;
+ gnutls_dh_params_t dh;
diff -Nru ucommon-6.0.7/debian/patches/series ucommon-6.0.7/debian/patches/series
--- ucommon-6.0.7/debian/patches/series	1970-01-01 00:00:00.0 +
+++ ucommon-6.0.7/debian/patches/series	2013-10-30 12:35:10.0 +
@@ -0,0 +1 @@
+fix-gnutls2.6.patch

Bug#724089: source-highlight: FTBFS: Tests failed

[Dmitrijs Ledkovs]

I believe this is related to boost1.54. I found some vague references
to that whilst doing web-search for a patch.

Regards,

Dmitrijs.


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

Bug#726009: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

[Dmitrijs Ledkovs]

On 11 October 2013 22:34, Ben Hutchings  wrote:
> On Fri, Oct 11, 2013 at 09:55:34PM +0100, Dmitrijs Ledkovs wrote:
> [...]
>> I'm not sure, but launchpad is running 64-bit machines even when
>> compiling for the i386 architecture, and then launchpad supports PAE
>> only and thus can get >4GB of address space.
> [...]
>
> Which bit of 'Physical Address Extension' do you not understand?
>

ignore me, friday evening. the parts where virtual address space is
limitted to 4gb per process none the less.

Regards,

Dmitrijs.


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

Bug#726009: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

[Dmitrijs Ledkovs]

On 11 October 2013 20:32, Steve Langasek  wrote:
> severity 726009 serious
> thanks
>
> This remains a serious bug.  Your package, which previously built on
> multiple architectures, is now failing to build due to memory exhaustion.
> While in some circumstances it is permissible to remove the old binaries and
> drop support for an architecture, this remains a serious bug until this has
> been done.  (And anyway, your package won't reach testing in the current
> state, so is de facto unreleasable.)
>
> On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote:
>> severity 726009 wishlist
>> retitle 726009 Yade requires too much RAM for building
>> thanks
>
>> thanks for bug-report. The problem is, that all build-failures are due
>> to insufficient RAM on build-machines [1]. I do not really know how to
>> "fix" that except of backlisting of some machines, as was suggested by
>> Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
>> the package builds only on machines, where >4Gb RAM is available.
>
> This diagnosis is incorrect.  The error you are hitting here is not that you
> are exhausting the available memory on the machine, it's that you're
> exhausting the *address space* on the machine.  Adding more memory to the
> buildd would have zero effect, because you're on a 32-bit system which has a
> limit of 4GB of address space anyway.  (In practice, I believe this is 3GB
> for userspace and 1GB for kernel on i386.)
>
> The buildd almost certainly has swap already, giving it total available
> memory in excess of 4GB, but that doesn't help if you have a single process
> - in this case g++ - that needs more than 3GB all to itself.
>
> If this same package version built on Launchpad but is failing to build in
> Debian unstable, then you should look at differences in toolchain versions
> between the two.  It's possible that Ubuntu has a compiler fix that isn't
> yet available in unstable; it's equally possible that the successful builds
> in Launchpad were done with an earlier toolchain, and that there's a more
> recent regression in g++ memory usage.  Either way, it's not the buildd's
> fault.

I'm not sure, but launchpad is running 64-bit machines even when
compiling for the i386 architecture, and then launchpad supports PAE
only and thus can get >4GB of address space.
I think debian buildds are also all 64-bit apart from one (or
something like that) thus it shouldn't be a problem there.

Last time I spoke with Colin about yade FTBFS due to memory
exhaustion, the recommendation he gave was to reduce translation units
and thus to reduce the compiler memory usage. GCC memory usage can go
very large and has regressed since 3.3 when templates are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
It has been done before for some other packages, but i haven't yet had
time to look more into yade. I think that's the best way to go for
yade, to address it in the source-code / restructure it to use less
memory at compile time.

Regards,

Dmitrijs.


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

Bug#706798: transition: Libav 9

[Dmitrijs Ledkovs]

On 09/11/2013 06:02 PM, Moritz Mühlenhoff wrote:
> On Fri, Sep 06, 2013 at 05:06:03PM +0200, Moritz Mühlenhoff wrote:
>
> Hi,
> two more testing removals related to the libav9 transition:
>
> - libavg 1.7.1-3 fails to build for unrelated boost reasons. Popcon is 
> virtually non-existant.

Well the patch for boost problem is uploaded into debian (built in a
jessie chroot / against older libav that is). Such that to prevent
erroneous FTBFS attribution to earlier boost failure in the build
process. This was available since August 27th in Ubuntu, but not
uploaded into debian as I couldn't build the package in sid as it
FTBFS against libav 9.

Unfortunately I'm not familiar with libav API changes to port libavg,
I'll poke upstream about it, but at the moment I'm tagging "libavg
FTBFS against libav 9" bug with "help".

Is there a libav 9 porting guide available somewhere? Or can someone
help out with a patch to fix libav 9 FTBFS?

Also, why did libavg was removed from testing? Was it actually
blocking any removals from the archive and/or transitions? As far as I
can see all libraries that libavg binaries are linked against are
still present in sid. This haste removal seems inconsistent to me
w.r.t. how other transitions & library removals are handled by the
release team.

ps. Popcon is virtually non-existant because virtually libavg has only
been recently reintroduced in debian after having been away for a long
time.


Regards,

Dmitrijs.


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

Bug#696204: acct: Build fixes for acct: libtool, gnulib C11, cross-building, hardening

[Dmitrijs Ledkovs]

Here is a follow up patch to fix up the texinfo build failure.

Regards,

Dmitrijs.


fix-texi-warnings.patch
Description: Binary data

Bug#722720: Please add installer images for Raspberry Pi

[Dmitrijs Ledkovs]

On 13 September 2013 17:55, Bernhard  wrote:
> Package: debian-installer
> Severity: wishlist
>
> Hello,
>
> Please add installer images for Raspberry Pi in architecture armel.
>
> There are several images available in
> /dists/wheezy/main/installer-armel/current/images.
> For example: there are images for qnap nas storage in images/kirkwood.
> But there is no image for Raspberry Pi.
>

The best support Debian installation media for Raspberry Pi are
provided by the related project Rasbian.
Have you tried images from http://www.raspbian.org/ ?

Regards,

Dmitrijs.


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

Bug#720507: .dsc field for dgit [and 1 more messages]

[Dmitrijs Ledkovs]

On 8 September 2013 10:12, Charles Plessy  wrote:
> Le Sat, Aug 31, 2013 at 06:17:29PM +0900, Charles Plessy a écrit :
>>
>> In any case, we need one more Developer to support this patch before 
>> applying to
>> the Policy.  Once we have this extra assessment for consensus, I will apply 
>> it
>> unless there are clear objections.
>
> Ping ?
>

I support this proposal and this particular implementation of it.

Regards,

Dmitrijs.


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

Bug#722246: libc6: Please consider lowering minimal linux kernel version

[Dmitrijs Ledkovs]

Package: libc6
Version: 2.17-92
Severity: wishlist

Dear Maintainer,
kfreebsd-i386 & kfreebsd-amd64 have linux emulatrion layer that can
emulate 2.6.16 linux API level. Which is also the minimum kernel version
that glibc2.17 & 2.18 require. At configure time though, the minimal
kernel version is set at 2.6.32.

Would you mind lowering it back to 2.6.16?

The benefits it will bring, is executing i386/amd64 binaries without
need to recompile glibc, by simply enabling i386/amd64 repositories and
installing foreign arch packages.

I don't know what performance/size/etc penalties are with lowering
minimal kernel version.

Alternatively, would you consider having a separate binary glibc package on
i386/amd64 with minimal version set back to 2.6.16?

Regards,

Dmitrijs.


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

Bug#722187: libosl: update boost build-dep (1.54)

[Dmitrijs Ledkovs]

Source: libosl
Version: 0.6.0-1
Severity: important

Your package build-depends on libboost1.49-all-dev.  If there isn't a
strong reason to not use another version it should use the unversioned
packages.  Otherwise please consider updating to 1.54.

Regards,

Dmitrijs.


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

Bug#722189: libpwiz: update boost build-depends

[Dmitrijs Ledkovs]

Source: libpwiz
Version: 3.0.4624-1
Severity: important

Your package build-depends on boost1.49 dev packages.  If there isn't a
strong reason to not use another version it should use the unversioned
packages.  Otherwise please consider updating to 1.54.

Regards,

Dmitrijs.


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

Bug#721869: install appropriate linux-headers

[Dmitrijs Ledkovs]

On 5 September 2013 20:58, Bjørn Mork  wrote:
> Christian PERRIER  writes:
>
>> Quoting Bjørn Mork (bj...@mork.no):
>> So, it's probably less overkill than it may seem at first glance to
>> imagine that installing headers by default may help in some cases.
>
> I hope and expect most Linux users never needing kernel headers.  And if
> they do need them, then the headers should be pulled in by one of the
> -dkms packages.  I do not think it is a good idea to encourage users or
> driver authors to keep drivers out of Debian.
>

How does the dependency look like to get headers for the _currently_
running kernel and not the latest one available/installed?
Considering I can upgrade to the new kernel packages a few times
before rebooting.

Regards,

Dmitrijs.


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

Bug#721869: install appropriate linux-headers

[Dmitrijs Ledkovs]

On 5 September 2013 15:07, Bjørn Mork  wrote:
> Dmitrijs Ledkovs  writes:
>
>> My latest ultra notebook doesn't have ethernet port and needs
>> out-of-the-tree wifi drivers compiled.
>> I fetched the tarball off github on my phone & transferred it to that
>> notebook over USB and then compiled.
>
> And this is the preferred solution, which you would recommend to any new
> user?  How about having the wifi device support by Debian instead?
> Wouldn't that be better?
>

Sure, but there will always be hardware which is not supported out of
the box by stable debian release.
My wifi driver is on it's way and will land in either 3.12 or 3.13 kernels.
Of course it's not the preferred solution, but rather a fall-back
resort that Debian thought of, and not simply ignored.

Regards,

Dmitrijs.


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

Bug#721869: install appropriate linux-headers

[Dmitrijs Ledkovs]

On 4 September 2013 22:03, Joey Hess  wrote:
> Package: base-installer
> Severity: normal
>
> The CD images include linux-headers packages, but d-i does not install
> these by default. I think that it should, so that if the user needs
> to build out of tree kernel modules they don't need to jump through
> the additional hoops of learning that Debian has separated kernel
> headers and how to install them. If we begin installing it by default,
> users should come to just expect that they can build kernel modules from
> source without doing anything more than a make, which will be a good
> thing.

I agree with Joey here. Imho gcc & linux-headers should be installed
by default when a desktop-like installation/tasks are chosen.

My latest ultra notebook doesn't have ethernet port and needs
out-of-the-tree wifi drivers compiled.
I fetched the tarball off github on my phone & transferred it to that
notebook over USB and then compiled.
I managed to compiled because I joyfully discovered that default
Ubuntu installations do install gcc and linux-headers unconditionally.
This was my first time experience where drivers didn't work and I
really had no other connectivity options, which I discovered only
after completing the installation.

Regards,

Dmitrijs.


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

Bug#718138: ocaml-estrings

[Dmitrijs Ledkovs]

ocaml-estrings has been accepted just now. So a build-dependencies on
libestring-ocaml-dev should be all that's needed here.

Regards,

Dmitrijs.


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

Bug#721240: Fwd: [recipe build #530064] of ~xnox dgit-daily in precise: Failed to build

[Dmitrijs Ledkovs]

Control: reopen 721240
Control: retitle 721240 Please provide a stable branch as a normal git
branch in refs/heads namespace

On 29 August 2013 12:24, Dmitrijs Ledkovs  wrote:
> On 29 August 2013 12:17, Dmitrijs Ledkovs  wrote:
>> On 29 August 2013 11:51, Ian Jackson  wrote:
>>> Dmitrijs Ledkovs writes ("Bug#721240: Fwd: [recipe build #530064] of ~xnox 
>>> dgit-daily in precise: Failed to build"):
>>>> Package: dgit
>>>> Version: 0.14
>>>>
>>>> It looks like the current master has broken top changelog entry, thus
>>>> breaking automatic daily build of the package from git on a derivative
>>>> distribution.
>>>>
>>>> dgit (0.14) unstable; urgency=low
>>>>
>>>>   * Include package name in tag message.
>>> ...
>>>> Is that on purpose?
>>> ...
>>>> Please keep master always in a buildable state, for the dgit users =)
>>>
>>> In dgit-repos/reops/dgit.git, "master" is a working branch which may
>>> contain half-finished changes and syntax errors.
>>>
>>
>> From upstream perspective, I would have thought it would be
>> interesting to have continious integration and catch those rather
>> earlier than later.
>>
>>
>>> In general, a "master" branch is not guaranteed even to exist in a
>>> dgit-repos repo.  If you're doing some kind of automatic daily build
>>> you should do it from one of the suite branches.
>>>
>>
>> Well, I'm not actually building "master". Git clone points by default
>> at remote HEAD, and the HEAD currently points to master. Maybe it
>> makes more sense for dgit git repositories to have HEAD point at
>> dgit/sid instead?
>>
>> At the moment if I do:
>> $ git clone git://anonscm.debian.org/git/dgit-repos/repos/dgit.git
>>
>> Which results in:
>>
>> $ git branch -a
>> * master
>>   remotes/origin/HEAD -> origin/master
>>   remotes/origin/master
>>
>> It's typical for git projects to have HEAD in an always (at least)
>> buildable state, and stage experimental changes on a non-default
>> branch. (typicall "master" and "next" respectfully)
>> To follow that logic, it makes sense for dgit git repository for HEAD
>> to point at dgit/sid, while "next" branch is called master.
>> This also suits NMU workflow better, as I'd like to git clone & commit
>> NMU, not on top of any other staged but not ready for upload changes.
>>
>
> Actually ignore me, this is not a bug. And dgit/* are reserved for
> dgit push and nothing else.

No, I'm still stuck. As dgit/* are not normal branches, the default
git clone doesn't clone them and thus I have no stable reference to
build from.

Regards,

Dmitrijs.


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

Bug#721240: Fwd: [recipe build #530064] of ~xnox dgit-daily in precise: Failed to build

[Dmitrijs Ledkovs]

On 29 August 2013 12:17, Dmitrijs Ledkovs  wrote:
> On 29 August 2013 11:51, Ian Jackson  wrote:
>> Dmitrijs Ledkovs writes ("Bug#721240: Fwd: [recipe build #530064] of ~xnox 
>> dgit-daily in precise: Failed to build"):
>>> Package: dgit
>>> Version: 0.14
>>>
>>> It looks like the current master has broken top changelog entry, thus
>>> breaking automatic daily build of the package from git on a derivative
>>> distribution.
>>>
>>> dgit (0.14) unstable; urgency=low
>>>
>>>   * Include package name in tag message.
>> ...
>>> Is that on purpose?
>> ...
>>> Please keep master always in a buildable state, for the dgit users =)
>>
>> In dgit-repos/reops/dgit.git, "master" is a working branch which may
>> contain half-finished changes and syntax errors.
>>
>
> From upstream perspective, I would have thought it would be
> interesting to have continious integration and catch those rather
> earlier than later.
>
>
>> In general, a "master" branch is not guaranteed even to exist in a
>> dgit-repos repo.  If you're doing some kind of automatic daily build
>> you should do it from one of the suite branches.
>>
>
> Well, I'm not actually building "master". Git clone points by default
> at remote HEAD, and the HEAD currently points to master. Maybe it
> makes more sense for dgit git repositories to have HEAD point at
> dgit/sid instead?
>
> At the moment if I do:
> $ git clone git://anonscm.debian.org/git/dgit-repos/repos/dgit.git
>
> Which results in:
>
> $ git branch -a
> * master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/master
>
> It's typical for git projects to have HEAD in an always (at least)
> buildable state, and stage experimental changes on a non-default
> branch. (typicall "master" and "next" respectfully)
> To follow that logic, it makes sense for dgit git repository for HEAD
> to point at dgit/sid, while "next" branch is called master.
> This also suits NMU workflow better, as I'd like to git clone & commit
> NMU, not on top of any other staged but not ready for upload changes.
>

Actually ignore me, this is not a bug. And dgit/* are reserved for
dgit push and nothing else.

Regards,

Dmitrijs.


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

Bug#721240: Fwd: [recipe build #530064] of ~xnox dgit-daily in precise: Failed to build

[Dmitrijs Ledkovs]

On 29 August 2013 11:51, Ian Jackson  wrote:
> Dmitrijs Ledkovs writes ("Bug#721240: Fwd: [recipe build #530064] of ~xnox 
> dgit-daily in precise: Failed to build"):
>> Package: dgit
>> Version: 0.14
>>
>> It looks like the current master has broken top changelog entry, thus
>> breaking automatic daily build of the package from git on a derivative
>> distribution.
>>
>> dgit (0.14) unstable; urgency=low
>>
>>   * Include package name in tag message.
> ...
>> Is that on purpose?
> ...
>> Please keep master always in a buildable state, for the dgit users =)
>
> In dgit-repos/reops/dgit.git, "master" is a working branch which may
> contain half-finished changes and syntax errors.
>

>From upstream perspective, I would have thought it would be
interesting to have continious integration and catch those rather
earlier than later.


> In general, a "master" branch is not guaranteed even to exist in a
> dgit-repos repo.  If you're doing some kind of automatic daily build
> you should do it from one of the suite branches.
>

Well, I'm not actually building "master". Git clone points by default
at remote HEAD, and the HEAD currently points to master. Maybe it
makes more sense for dgit git repositories to have HEAD point at
dgit/sid instead?

At the moment if I do:
$ git clone git://anonscm.debian.org/git/dgit-repos/repos/dgit.git

Which results in:

$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master

It's typical for git projects to have HEAD in an always (at least)
buildable state, and stage experimental changes on a non-default
branch. (typicall "master" and "next" respectfully)
To follow that logic, it makes sense for dgit git repository for HEAD
to point at dgit/sid, while "next" branch is called master.
This also suits NMU workflow better, as I'd like to git clone & commit
NMU, not on top of any other staged but not ready for upload changes.

Regards,

Dmitrijs.


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

Bug#721240: Fwd: [recipe build #530064] of ~xnox dgit-daily in precise: Failed to build

[Dmitrijs Ledkovs]

Package: dgit
Version: 0.14

It looks like the current master has broken top changelog entry, thus
breaking automatic daily build of the package from git on a derivative
distribution.

dgit (0.14) unstable; urgency=low

  * Include package name in tag message.

 --

Is that on purpose?

>From parsechangelog:
WARN: debian/changelog(l5): badly formatted trailer line
LINE:  --
WARN: debian/changelog(l7): found start of entry where expected more
change data or trailer
LINE: dgit (0.13) unstable; urgency=low
Source: dgit
Version: 0.14
Distribution: unstable
Urgency: low
Changes:
 dgit (0.14) unstable; urgency=low
 .
   * Include package name in tag message.

Please keep master always in a buildable state, for the dgit users =)

Regards,

Dmitrijs.

-- Forwarded message --
From:  
Date: 29 August 2013 02:36
Subject: [recipe build #530064] of ~xnox dgit-daily in precise: Failed to build
To: Dmitrijs Ledkovs 


 * State: Failed to build
 * Recipe: xnox/dgit-daily
 * Archive: xnox/dgit
 * Distroseries: precise
 * Duration: 3 minutes
 * Build Log: https://launchpadlibrarian.net/148666941/buildlog.txt.gz
 * Upload Log:
 * Builder: https://launchpad.net/builders/actinium

--
https://launchpad.net/~xnox/+archive/dgit/+recipebuild/530064
You are the requester of the build.


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

Bug#721169: alembic please provide python3 module

[Dmitrijs Ledkovs]

Package: alembic
Version: 0.4.2+ds-3

Please provide python3 package.

Regards,

Dmitrijs.

Bug#703169: btrfs-tools: bedup

[Dmitrijs Ledkovs]

On 27 August 2013 07:39, Petter Reinholdtsen  wrote:
> [Dmitrijs Ledkovs]
>> Sure. Btrfs package needs a rebuild against lzo2-2-udeb & upstream
>> update, so i shall be doing another upload soon.
>
> Hi.  I noticed the new upload of version 0.19+20130705-1, but it did
> not close this bug.  Is there some snag blocking the inclusion of
> bedup in btrfs-tools?
>

I wanted to unbreak the installer and separate /usr systems, without
the delay of dedup binary package going through new.
I'm working on including dedup.

Regards,

Dmitrijs.


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

Bug#720958: Fwd: ocaml-estring_20130822-1_multi.changes rejected

[Dmitrijs Ledkovs]

On 26 August 2013 18:17, Ian Jackson  wrote:
> retitle 720958 dgit should always override dput's target host
> thanks
>
> Dmitrijs Ledkovs writes ("Bug#720958: Fwd: 
> ocaml-estring_20130822-1_multi.changes rejected"):
>> I've now finally managed to use `dgit push` on my Ubuntu Saucy
>> Salamander 13.10 system.
>> It all went ok, apart from dput uploading to "ubuntu", instead of 
>> "ftp-master".
>
> What you mean is that dgit's dput uploaded to ftp-master ?
>
> Oh wait you mean you are using ubuntu, and its dput uploads to ubuntu
> by default.  How annoying.  I will change dgit to always tell dput
> where to upload to.
>

that. On ubuntu /etc/dput.cf has
[DEFAULT]
default_host_main = ubuntu

But the ftp-master host is available, so yeah please change dgit to
always tell dput to upload to ftp-master.

Regards,

Dmitrijs.


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

Bug#720958: Fwd: ocaml-estring_20130822-1_multi.changes rejected

[Dmitrijs Ledkovs]

Package: dgit
Version: 0.11
Severity: normal

I've now finally managed to use `dgit push` on my Ubuntu Saucy
Salamander 13.10 system.
It all went ok, apart from dput uploading to "ubuntu", instead of "ftp-master".

One can trivially figure out target distributions (e.g. debian vs
ubuntu vs else, and aliases) with distro-info command(s), as there is
no overlap between ubuntu & debian names.
I guess I should be setting upload-host configuration variable to ftp-master.

Maybe ftp-master should be the default for now?

Regards,

Dmitrijs.


-- Forwarded message --
From: Ubuntu Installer 
Date: 26 August 2013 17:22
Subject: ocaml-estring_20130822-1_multi.changes rejected
To: Dmitrijs Ledkovs 


Rejected:
Unable to find distroseries: unstable
Further error processing not possible because of a critical previous error.





===

If you don't understand why your files were rejected, or if the
override file requires editing, please go to:
http://answers.launchpad.net/soyuz

--
You are receiving this email because you are the uploader, maintainer or
signer of the above package.


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

Bug#720744: dh-python: I don't speak Perl, but it stricly doesn't come dancing.

[Dmitrijs Ledkovs]

On 25 August 2013 11:59, Piotr Ożarowski  wrote:
> tags 720744 + pending
> severity 720744 important
> thanks
>
> I somehow missed this case in a617d883f519e924f487cc87f956f1bbaa1735da
> commit - thanks for the bug & patch, it's already in the git repo.
> I don't consider it RC so I downgraded severity to important (not a single
> package is using this feature in unstable right now) and will upload it
> in about a week, once the current one migrates to testing.

Fair enough. I have uploaded proposed patch in Ubuntu, as e.g. at
least update-manager was already using PYBUILD_INTERPRETERS.

Regards,

Dmitrijs.


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

Bug#720744: dh-python: I don't speak Perl, but it stricly doesn't come dancing.

[Dmitrijs Ledkovs]

Package: dh-python
Version: 1.20130819-1
Severity: critical
Tags: patch

Dear Maintainer,

In ubuntu the following bug report was filed:
https://bugs.launchpad.net/ubuntu/+source/dh-python/+bug/1214553

dpkg-source --before-build openteacher-3.1
 fakeroot debian/rules clean
dh clean --with python2 --buildsystem=pybuild
   dh_testdir -O--buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
Can't use string ("pybuild --clean ") as an ARRAY ref while "strict refs" in 
use at /usr/share/perl5/Debian/Debhelper/Buildsystem/pybuild.pm line 78.
make: *** [clean] Error 255
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
debuild: fatal error at line 1361:
dpkg-buildpackage -rfakeroot -d -us -uc -S -sa failed

I have no idea if this is right or not, but I applied the following
patch and it seems to be working now:

Description: Hopefully unbreak pybuild by properly pushing array arguments to @result array-ref.
Author: Dmitrijs Ledkovs 
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1214553

--- dh-python-1.20130819.orig/dh/pybuild.pm
+++ dh-python-1.20130819/dh/pybuild.pm
@@ -88,7 +88,7 @@ sub pybuild_commands {
 	my @result;
 
 	if ($ENV{'PYBUILD_INTERPRETERS'}) {
-		push @result, "pybuild --$step @options";
+		push @result, ['pybuild', "--$step", @options];
 	}
 	else {
 		# get interpreter packages from Build-Depends{,-Indep}:

Regards,

Dmitrijs.

Bug#720555: dgit: Cannot push --new

[Dmitrijs Ledkovs]

On 23 August 2013 14:44, Ian Jackson  wrote:
> reopen 720555
> retitle 720555 Want better error for .dsc implying tree containing .git
> thanks
>
> Dmitrijs Ledkovs writes ("Re: Bug#720555: dgit: Cannot push --new"):
>> On 23 August 2013 14:10, Ian Jackson  wrote:
>> > Dmitrijs Ledkovs writes ("Bug#720555: dgit: Cannot push --new"):
>> > If you run
>> >dpkg-source -x ocaml-estring-20130822-1.dsc
>> > does the output have a .git directory ?  If so then something went
>> > wrong at the build step.
>>
>> my fail, indeed pristine tarball has .git .
>
> Aha.  JOOI, how did you come to make this mistake, if you used dgit
> sbuild ?   dgit sbuild tries to tell dpkg-source to leave it out.
> Perhaps dgit needs to be cleverer somehow or the docs could be improved.
>
> Certainly the error message could be improved.
>

If one doesn't have an orig tarball, and uses dh_make, it kindly
offers a flag to create an orig tarball, which will include upstream
.git.
Cleverly sbuild will than pass fine, as helpfully "3.0 (quilt)"
ignores any changes to .git/* and the like, so it didn't catch when I
added additional commits on top.
But clearly dgit is smarter than dpkg to notice such fail.

Anywho... I'm now getting this:

$ dgit push --new
canonical suite name for unstable is sid
canonical suite name for unstable is sid
Format `3.0 (quilt)', urgh
checking that ocaml-estring_20130822-1.dsc corresponds to HEAD
dpkg-source: warning: extracting unsigned source package
(../../../../ocaml-estring_20130822-1.dsc)
dpkg-source: info: extracting ocaml-estring in ocaml-estring-20130822
dpkg-source: info: unpacking ocaml-estring_20130822.orig.tar.xz
dpkg-source: info: unpacking ocaml-estring_20130822-1.debian.tar.gz
mkdir: cannot create directory `ocaml-estring.git': Permission denied
ssh: failed command: ssh git.debian.org 'set -e; cd /git/dgit-repos;
mkdir -p ocaml-estring.git; cd ocaml-estring.git; if ! test -d
objects; then git init --bare; fi'
dgit: subprocess failed with error exit status 1

I am a DD do I need something extra on alioth?

Regards,

Dmitrijs.


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

Bug#720555: dgit: Cannot push --new

[Dmitrijs Ledkovs]

Package: dgit
Version: 0.7
Severity: normal

Dear Maintainer,

I did:
$ dgit clone --new ocaml-estring
$ 
$ git commit -a
$ dgit sbuild
$ dgit push --new
canonical suite name for unstable is sid
canonical suite name for unstable is sid
Format `3.0 (quilt)', urgh
checking that ocaml-estring_20130822-1.dsc corresponds to HEAD
dpkg-source: warning: extracting unsigned source package 
(../../../../ocaml-estring_20130822-1.dsc)
dpkg-source: info: extracting ocaml-estring in ocaml-estring-20130822
dpkg-source: info: unpacking ocaml-estring_20130822.orig.tar.xz
dpkg-source: info: unpacking ocaml-estring_20130822-1.debian.tar.gz
Died at /usr/bin/dgit line 484.

The function in question is:
477 sub mktree_in_ud_from_only_subdir () {
478 # changes into the subdir
479 my (@dirs) = <*/.>;
480 die unless @dirs==1;
481 $dirs[0] =~ m#^([^/]+)/\.$# or die;
482 my $dir = $1;
483 chdir $dir or die "$dir $!";
484 die if stat '.git';
485 die $! unless $!==&ENOENT;
486 runcmd qw(git init -q);
487 rmtree('.git/objects');
488 symlink '../../../../objects','.git/objects' or die $!;
489 runcmd @git, qw(add -Af);
490 my $tree = cmdoutput @git, qw(write-tree);
491 $tree =~ m/^\w+$/ or die "$tree ?";
492 return ($tree,$dir);
493 }

Not sure why it's trying to create a new git repository, since as far as
I can tell, one will never be able to get to $ dgit push, without having
a local repository already

Regards,

Dmitrijs.


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

Bug#720547: ITP: ocaml-estring -- Estring: OCaml development platform

[Dmitrijs Ledkovs]

Package: wnpp
Owner: Dmitrijs Ledkovs 
Severity: wishlist

* Package name: ocaml-estring
  Version : git snapshot
  Upstream Author : Jeremie Dimino
* URL or Web page : https://github.com/diml/estring
* License : BSD-3-Clause
  Description : Estring: OCaml development platform

 estring, which stands for `extended strings' is a syntax extension
 allowing to prefix string literals with a specifier to change their
 meaning.
 .
 This package used to be part of the batteries project.

Regards,

Dmitrijs


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

Bug#720507: .dsc field for dgit

[Dmitrijs Ledkovs]

On 22 August 2013 20:53, Ian Jackson  wrote:
> Dmitrijs Ledkovs writes ("Re: Bug#720507: .dsc field for dgit"):
>> Using this field, seems to miss-render on Debian PTS.
>>
>> See: http://packages.qa.debian.org/d/dgit.html
>>
>> Click on the link next to VCS: "" it goes nowhere =)
>
> Hmm.  Would it be better to pick a different name ?  It's not too late
> - I can have it understand both the old and new names and generate
> only the new one.
>

No idea. I guess Debian PTS blindly copies & displays any Vcs-*:
fields as the URL.
It would then work if that field would be a valid url e.g.:

http://anonscm.debian.org/gitweb/?p=dgit-repos/dgit.git;a=commit;h=1ce58351167dc6e9410f07bc4989f7c21940ba22

Regards,

Dmitrijs.


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

Bug#713306: marked as done (netgen: FTBFS: /usr/share/automake-1.13/am/ltlibrary.am: warning: 'libcsg.la': linking libtool libraries using a non-POSIX)

[Dmitrijs Ledkovs]

On 22 August 2013 20:43, Boris Pek  wrote:
> control: reopen 713306
>
>
> Hi Dmitrijs,
>
> Unfortunately your patch [1] did not fix build error [2][3].
>

Yeap, thanks for reopening. I did notice. Will reupload a fix for that
in a moment.

Regards,

Dmitrijs.

> [1] 
> http://anonscm.debian.org/gitweb/?p=debian-science/packages/netgen.git;a=commitdiff;h=ea5a05f
> [2] https://buildd.debian.org/status/logs.php?pkg=netgen&ver=4.9.13.dfsg-6
> [3] 
> https://buildd.debian.org/status/fetch.php?pkg=netgen&arch=i386&ver=4.9.13.dfsg-6&stamp=1377127517
>
> Best regards,
> Boris


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

Bug#720507: .dsc field for dgit

[Dmitrijs Ledkovs]

On 22 August 2013 18:48, Ian Jackson  wrote:
> Package: debian-policy
> Version: 3.9.4.0
>
> I have been working on a new tool for integration between the Debian
> archive and git.  The best available description is probably its
> manpage:
>   http://www.chiark.greenend.org.uk/~ijackson/2013/dgit.html
>
> dgit uses a new field in .dsc files, which I have called
> Vcs-Dgit-Master.  Here is my proposed policy amendment to describe it.
>
> There is no need for anything other than dgit to know about this
> field or its implications, although QA tools could profitably check
> some of the facts stated in the spec.
>

Using this field, seems to miss-render on Debian PTS.

See: http://packages.qa.debian.org/d/dgit.html

Click on the link next to VCS: "" it goes nowhere =)

Regards,

Dmitrijs.


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

Bug#699763: libicu-dev: Please complete the conversion to multiarch

[Dmitrijs Ledkovs]

Control: tag -1 patch

Heya,

Here is a proposed patch to multiarch libicu-dev.
I split the utilities into a separate package, called icu-tools and
mark it as Multi-Arch: foreign (can install only one copy, and foreign
arch packages can depend on it)
I move the headers into multi-arch location, as platform.h is
different between big and little indian platforms and mark it as
Multi-Arch: same & make it depend on icu-tools package (can install
multiple copies of libicu-dev)

I have tested and all packages that either use icu-config or
pkg-config files for icu, configure/compile/install/run correctly.

I have also committed to boost svn trees a small fix to correctly find
icu at configure step (boost's custom build system jam, didn't use
neither icu-config nor pkg-config, but hard-coded paths).

All boost, xerces, and libreoffice all build and work correctly.

Please consider and apply below patch.

Regards,

Dmitrijs.


0001-Multi-arch-libicu-dev.-Closes-699763.patch
Description: Binary data

Bug#720188: kfreebsd: please implemente/expose waitid function & wait6 syscall

[Dmitrijs Ledkovs]

On 19 August 2013 15:43, Petr Salinger  wrote:
>> Recently in FreeBSD waitid was implemented[1] this includes:
>> * waitid function, implemented via wait6 syscall
>> * option flags WEXITED WTRAPPED added
>>
>> More details & patch in the PR linked.
>>
>> This is now available in prerelease FreeBSD 9.2 (I'm using 9.2-rc2). I
>> have verified and tested that it works correctly for my needs.
>>
>> [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=170346&cat=
>>
>> Can it please be added to eglibc as used by Debian/kFreeBSD ports? the
>> 9.2 kernel is already available in Debian. (If possible in sid, or
>> e.g. at least in experimental)
>>
>> I can help writting a patch, but I have no prior knoweledge in hacking
>> eglibc.
>
>
> It is planned, but (e)glibc 2.18 upload have to go first, due to changes of
> idtype_t values. See also 218_waitid* in
> http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/
>
> We also have to provide (reasonable) fallback implementation
> under wheezy kernels.
>

Cool! Excellent stuff! I've tried applying 218_waitid* things against
the eglibc-package as is in the debian trunk (2.17 based) and failed
to compile it properly.
Is there a way for me to compile debs or apt-get libc 2.18 with above
patches applied?

Regards,

Dmitrijs.


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

Bug#720209: ITP: libinotify-kqueue -- inotify compatible implementation using kqueue

[Dmitrijs Ledkovs]

Package: wnpp
Owner: Dmitrijs Ledkovs 
Severity: wishlist

* Package name: libinotify-kqueue
  Version : upstream snapshot from 20120419
  Upstream Author : Dmitry Matveev 
* URL or Web page : https://github.com/dmatveev/libinotify-kqueue
* License : MIT/BSD
  Description : inotify compatible implementation using kqueue

This package provides an implementation of sys/inotify.h using
kqueue. This is kind of reverse of libkqueue package, as it allows to
compile software on kFreeBSD which otherwise is using Linux specific
inotify API.


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

Bug#720188: kfreebsd: please implemente/expose waitid function & wait6 syscall

[Dmitrijs Ledkovs]

Package: libc0.1-dev
Version: 2.17-92
Severity: normal
X-Debbugs-CC: petr.salin...@seznam.cz

Dear Maintainer,
Recently in FreeBSD waitid was implemented[1] this includes:
* waitid function, implemented via wait6 syscall
* option flags WEXITED WTRAPPED added

More details & patch in the PR linked.

This is now available in prerelease FreeBSD 9.2 (I'm using 9.2-rc2). I
have verified and tested that it works correctly for my needs.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=170346&cat=

Can it please be added to eglibc as used by Debian/kFreeBSD ports? the
9.2 kernel is already available in Debian. (If possible in sid, or
e.g. at least in experimental)

I can help writting a patch, but I have no prior knoweledge in hacking eglibc.

Regards,

Dmitrijs.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)

Kernel: kFreeBSD 10.0-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libc0.1-dev:kfreebsd-amd64 depends on:
ii  kfreebsd-kernel-headers  9.1-3
ii  libc-dev-bin 2.17-92
ii  libc0.1  2.17-92

Versions of packages libc0.1-dev:kfreebsd-amd64 recommends:
ii  gcc [c-compiler]  4:4.7.2-1
ii  gcc-4.7 [c-compiler]  4.7.3-6

Versions of packages libc0.1-dev:kfreebsd-amd64 suggests:
pn  glibc-doc 
pn  manpages-dev  

-- no debconf information


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

Bug#703169: btrfs-tools: bedup

[Dmitrijs Ledkovs]

Sure. Btrfs package needs a rebuild against lzo2-2-udeb & upstream update,
so i shall be doing another upload soon.

Txting from phone.
On 18 Aug 2013 09:51, "Petter Reinholdtsen"  wrote:

>
> Control: retitle -1 btrfs-tools: add the bedup tool for "offline"
> deduplication?
>
> [Luk Claes 2013-03-16]
> > Plus it needs python-cffi to build which is currently in the NEW
> > queue.
>
> It has now cleared the NEW queue and is present in both testing and
> unstable, see http://packages.qa.debian.org/p/python-cffi.html >.
>
> Any news on providing the bedup tool in Debian?
>
> --
> Happy hacking
> Petter Reinholdtsen
>
>

Bug#716978: initramfs not setting up crypto

[Dmitrijs Ledkovs]

On 17 August 2013 00:02, Matt Taggart  wrote:
> Ben Hutchings writes:
>
>> That's strange.  The LVM tools are added by
>> /usr/share/initramfs-tools/hooks/lvm2 which is part of the lvm2 package.
>> So this implies lvm2 wasn't installed either, though that seems
>> unlikely.
>
> I found the LVM problem (and possibly the crypt problem). My preseed setup
> was installing a sources.list that pointed to squeeze rather than wheezy
> and I think that prevented lvm2 from getting installed. It may have also
> caused the initramfs to not get the crypto modules, but I suspect it's more
> likely that using the minimal module setting caused that.
>

I also uploaded a fix, where apt-install lvm2 script was not actually
executable in the partman-lvm, so it was not actually run either. The
affected versions were 84 & 85, fix released in 86. Maybe that was
related as well.

http://ftp-master.metadata.debian.org/changelogs/main/p/partman-lvm/unstable_changelog

Regards,

Dmitrijs.


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

Bug#680686: jessie release goal: verbose build logs

[Dmitrijs Ledkovs]

On 17 June 2013 23:58, Dmitrijs Ledkovs  wrote:
> tags 680686 patch
> thanks
>
> On 14 June 2013 12:35, Matthias Klose  wrote:
>>
>>  - Fix debhelper not passing --disable-silent-rules by default.
>>#680686
>>I think cdbs already does this.
>
> Patch attached for autoconf dh build system. cmake dh build system
> seems to be already enabling verbose makefiles.
>

Is there any reason this hasn't been applied yet?
Can I NMU this, as debhelper is marked as LowNMU package.
The patch itself is a trivial one-liner and fixes a Jessie release goal.
The bug report itself was filed a little over one year ago.

Regards,

Dmitrijs.


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

Bug#719110: eject: unable to find or open device for: `cdrom' - but my cd is /dev/cdrom1

[Dmitrijs Ledkovs]

Package: eject
Version: 2.1.5+deb1+cvs20081104-13
Severity: normal
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dear Maintainer,

In ubuntu, the following bug report was filed:

"""
The eject command does not actually eject my cdrom, unless called as
'eject /dev/cdrom1'

The problem seems to be that the eject command's default device is set
to "/dev/cdrom" specifically. Yet, udev will increment the drive name
if new cdroms are added or even if you change the cable that the cdrom
is connected to. See
https://bugzilla.redhat.com/show_bug.cgi?id=570490. udev now assigns
permanent names to devices in case they're being hotplugged, which
obviously makes sense for servers but a bit sub-optimal for desktops
where you generally have no more than one cd...
"""

A patch has been proposed to address this issue. Please review and
consider applying it.

Regards,

Dmitrijs.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBCAAGBQJSA57DAAoJEIh7YGGLPBauV8gQAKxY26DeAKPOyuNJ5mnkP6Ra
tkmDAxTDia7iJGq9B13y3PSB/K0tBIXte7m9YrCQHRn+9PTbgUrJLsVhlE9Nt/wM
24RMi+0Vkf9yG6vl8nHfj7YTo9n/fTKhOx0s74b6Auhh/r/V8GdRSg7V+MoMTOFK
m54VwtOzDRUgZ0UPAhJDR9xQ+MRNq9Y0Po0I5HAxR+SXtxBqgIV7MyrjoC4UsBDX
Z4F0hfQJyVhDRJtbXZXVSTPVi4KSr2ls+APurjhoL/51j8wVsQmHya+ZZCZxDI4R
IizKr9A+6rSA5UbtfOJTTYvO6+7seHbqKK7KP5Negzr6HTztWaRhIVLEtkApUA6M
q015/VLukHPdboii5sFV5v+nff4CvVfI3IWX2zU6mNvNWYH7aaTab0IdKMdTQtE+
t8nafcGkvr+dMRZ/vkGM67dFceg9qA+ZqnDqIa8i89vpYFykW+IDDsRliWVnzROV
Mkj+tiSdLvcP9VM1c858aVcyQ/v8l3f8gOgobyH8/AdJcijdRUR8gu5gZVjTtOfn
67Mpo47eDPPYpaWqbmr7c8Oq6QwxIJuStb5FlR6iJjWu8zP+Y8D3pFBlqc/7pfaK
pLHIC62WZRTV1CmJw0HIgXVvDJCiTQRxoIwLM3o/by39a5W+5eSKR1QRynMwWRcs
GZGTSKT+P1ZTW1brXwsz
=/sMm
-END PGP SIGNATURE-
=== modified file 'debian/changelog'
--- debian/changelog	2012-12-23 23:30:02 +
+++ debian/changelog	2013-07-06 22:16:27 +
@@ -1,3 +1,10 @@
+eject (2.1.5+deb1+cvs20081104-13.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * eject now iterates through /dev/device_name[0-9] (LP: #795239)
+
+ -- Ankit Sinha   Sun, 07 Jul 2013 03:26:43 +0530
+
 eject (2.1.5+deb1+cvs20081104-13) unstable; urgency=low
 
   [ Christian Perrier ]

=== modified file 'eject.c'
--- eject.c	2012-02-20 01:07:09 +
+++ eject.c	2013-07-06 22:16:27 +
@@ -431,6 +431,8 @@
 	char *buf;
 	static int try = 0;
 	int found = 0;
+	int i=0;
+	char temp;
 
 	buf = (char *) malloc(strlen(name)+14); /* to allow for "/dev/cdroms/ + "0" + null */
 	if (buf==NULL) {
@@ -455,6 +457,17 @@
 	if (FileExists(buf, try, &found))
 		return buf;
 
+	/* Cycles through device-name[0-9] */
+	for(i=0;i<10;i++)
+	{
+		strcpy(buf, "/dev/");
+		strcat(buf, name);
+		temp='0'+i;
+		strcat(buf, &temp);
+		if (FileExists(buf, try, &found))
+			return buf;
+	}
+
 	strcpy(buf, "/media/");
 	strcat(buf, name);
 	if (FileExists(buf, try, &found))

Bug#716978: initramfs not setting up crypto

[Dmitrijs Ledkovs]

On 6 August 2013 19:35, Ben Hutchings  wrote:
> On Tue, 2013-08-06 at 10:17 -0700, Matt Taggart wrote:
>> Ben Hutchings writes:
>> > On Mon, 2013-08-05 at 16:31 -0700, Matt Taggart wrote:
>> > > I think I am seeing the same bug reported in #716978...
>> > >=20
>> > > I just did an install of wheezy using a d-i daily (updated today
>> > > 2013-08-05). The root is md raid->crypt->lvm. Upon boot the initramfs
>> > > started up the md raid devices properly, but failed to setup the crypto
>> > > and dropped to an initramfs shell. When I poke around I see that
>> > >=20
>> > > /lib/modules/3.2.0-4-amd64/kernel/crypto/
>> > >=20
>> > > is lacking most of the crypto modules (including the xts/serpant/etc
>> > > that my system needed). So I am unable to bring things up by hand
>> > > either.
>> > >=20
>> > > During the install, for the question about how much to include in the
>> > > initramfs, I picked the "just what's needed by this system" answer,
>> > > although I think that should have been OK.
>> >
>> > I doubt we'll ever be able to get it completely right.  That option
>> > should be warned against in general.  It is useful for machines with
>> > limited memory or space for the initramfs (e.g. ARM systems where the
>> > bootloader looks for it in a specific flash partition).  Otherwise it
>> > just saves a fraction of a second of boot time, or fails to boot.
>>
>> I used d-i rescue mode to mount the disks and switch from "dep" to "most"
>> mode for update-initramfs and that pulled the crypto modules in. But now
>> the problem is that the LVM tools aren't in the initramfs so it gets stuck
>> at that point.
>
> That's strange.  The LVM tools are added by
> /usr/share/initramfs-tools/hooks/lvm2 which is part of the lvm2 package.
> So this implies lvm2 wasn't installed either, though that seems
> unlikely.
>

Do we have full debug level logs for the broken install available?
cause I did some refactoring on partman-lvm and partman-crypto
together with new upstream releases of lvm2, crypto, kernel there
are plenty of things that could have gone wrong.

Also just recently in ubuntu this upload was made:
https://launchpad.net/ubuntu/+source/lvm2/2.02.98-1ubuntu4

To fix a very nasty:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1206235

Not sure if debian is also affected, and whether it's related at all.

Regards,

Dmitrijs.


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

Bug#699763: libicu-dev: Please complete the conversion to multiarch

[Dmitrijs Ledkovs]

On 6 August 2013 14:37, Jay Berkenbilt  wrote:
> Dmitrijs Ledkovs  wrote:
>
>> I need libicu-dev to be multiarched to multiarch boost locale and
>> regex libraries.
>> I really would like to cross-compile C++ projects out-of-the-box.
>> Please consider this as a priority bump request.
>
> I'm acknowledging this request.  I will get to it "as soon as I can" but
> realistically that is not going to be very soon.  These days I am using
> paid time off from work to do anything with my packages other than
> keeping them functional and reasonably up to date, and I don't have any
> to spare at the moment.  I am hoping to take a couple of days off next
> week to catch up on some stuff, but my list is already very long.
>

I understand. We all have things to do =) and it's best catch up on
fun & cool as you see fit, more rewarding that way.

> I would also like to transition ICU to a later version, maybe 52 when it
> is released, but the release team is seriously backed up on transitions,
> which is why I have not requested one yet.  (Besides, I have another
> transition waiting for service.)  Unfortunately every ICU release
> requires a library transition because of the fact that they put
> incubating APIs not subject to any kind of stability rules in their
> public interface.
>

Yeah, ditto boost. I had to plow through boost1.53 transition in
ubuntu, and we are now up to boost1.54 with no transition started in
Debian yet.
I'm still debating about doign -> boost1.54 first, or do -> boost1.54
together with multiarchification.
At the moment boost1.53 is multiarched in debian experimental & ubuntu saucy.

> I have offered ICU for adoption on two or three occasions but have never
> gotten any takers.  Are you interested?
>

I'd be happy to co-maintain and do uploads from time to time. I'm not
sure how much time I'd have for full transitions to new upstream
api/abi though.

> I would also consider a patch that takes care of this, particularly if
> it works with boost.
>

ack.

> Ideally, before any splitting of the dev package could be done, I would
> need to ensure that boost, xerces, and openoffice.org (or libreoffice or
> whatever is current) still builds without any arch-dependent parts. This
> would enable me to decide which of the options I outlined previously
> would be better.
>

Ack. I'll experiment and propose something.

Regards,

Dmitrijs.


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

Bug#699763: libicu-dev: Please complete the conversion to multiarch

[Dmitrijs Ledkovs]

I need libicu-dev to be multiarched to multiarch boost locale and
regex libraries.
I really would like to cross-compile C++ projects out-of-the-box.
Please consider this as a priority bump request.

Regards,

Dmitrijs.


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

Bug#718123: aufs-tools: FTBFS: aufs-util for aufs3.0 and later, but aufs is 3.x-rcN-20130520.

[Dmitrijs Ledkovs]

Control: tag -1 patch

Patch attached.

Regards,

Dmitrijs.


fix-ftbfs-with-rc-kernel.patch
Description: Binary data

Bug#707537: [Pkg-crosswire-devel] Bug#707537: sword: FTBFS: zlib.h:86:5: error: 'z_const' does not name a type

[Dmitrijs Ledkovs]

On 4 August 2013 16:20, Rene Engelhard  wrote:
> tag 707537 + patch
> thanks
>
> [ looking at this bug for the clucene transition which this FTBFS blocks,
> see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718375 ]
>
> Hi,
>
> On Thu, May 23, 2013 at 12:20:47AM +0100, Dmitrijs Ledkovs wrote:
>> I don't have time to further look into this atm, ie. this week.
>> Patches / nmu / team uploads are welcome, straight into archive with
>> no delays.
>
> The patch actually is trivial. Just remove the internal zconf.h. See attached
> debdiff.
>

Thanks a lot for the patch =)

> NMU still welcome?
>

I'll upload this in a sec, once I figure out the pending patch for
clucene as well.

Regards,

Dmitrijs.


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

Bug#698674: Tcl/Tk multiarching

[Dmitrijs Ledkovs]

To address many of FTBFS bugs, I did in the end introduce a compat
tclConfig.sh tkConfig.sh in non-multiarch locations for Ubuntu, that
simply call dpkg-architecture and source the multi-arched variant.

This solved most of the bugs, but there are still some software that
either hardcoded locations of the default versioned tk/tcl or, in case
of ruby, instead of source the configuration file, it tries to read in
& parse the file by itself.

Regards,

Dmitrijs.


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

Bug#709422: Depending on binary that is not available on boot (liblzo2.so.2)

[Dmitrijs Ledkovs]

Both btrfs and fsck.btrfs are now unconditionally included in the
initramfs, and thus should be available on your system to boot & mount
'/' and '/usr'. Together with the ongoing work to mount and fsck '/'
and '/usr' from initramfs, you should have less problems booting going
into the future. It is unfortunate that lzo2 is not installed into
/lib/, I will request the maintainer of that package to do so, by
reassigning the bug there.

Regards,

Dmitrijs.


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

Bug#717519: [debian-installer] daily-build cd image won't boot since 20130715

[Dmitrijs Ledkovs]

I am travelling at the moment. Can look into it tomorrow.

Regards,

Dmitrijs.

On 24 Jul 2013 10:21, "Cyril Brulebois"  wrote:
>
> Control: reassign -1 rootskel 1.104
> Control: retitle -1 rootksel: empty package since debhelper compat bump
>
> Eugene Paskevich  (2013-07-24):
> > On Tue, 23 Jul 2013 17:09:27 +0300, Eugene Paskevich
> >  wrote:
> >
> > >git clone git://anonscm.debian.org/d-i/debian-installer.git && cd
> > >debian-installer/build && make build_cdrom_isolinux && cd
> > >dest/cdrom
> > >
> > >amd64 machine:
> > >eugene@hopper
[pts/0]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> > >git describe
> > >20130430-27-ge443bdb
> > >eugene@hopper
[pts/0]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> > >lsinitramfs initrd.gz | egrep '(sbin/|)init$'
> > >init
> > >sbin/init
> > >eugene@hopper
[pts/0]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> > >
> > >i386 machine:
> > >eugene@kite
[pts/6]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> > >git describe
> > >20130430-27-ge443bdb
> > >eugene@kite
[pts/6]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> > >lsinitramfs initrd.gz | egrep '(sbin/|)init$'
> > >eugene@kite
[pts/6]:~/Archives/rcs/git/debian-installer/build/dest/cdrom>
> >
> > Which is actially because of the bug in rootskel package.
> > http://packages.debian.org/unstable/debian-installer/rootskel
> > Just take a look at the Installed size of i386 package.
>
> So, the debhelper compat bump from 7 to 9 really should have been
> triple checked. It is responsible for the empty package (lowering to
> 7 or 8 makes the package unempty again).
>
> It would really be nice to run debdiff against source+binary packages
> before/after thorough packaging change like this one. Be it because
> one is the committer, or the uploader. Thanks already. :-)
>
> Mraw,
> KiBi.

Bug#714787: python3-paste

[Dmitrijs Ledkovs]

Committed a few more patches in team svn trunk.

Regards,

Dmitrijs.


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

Bug#714784: python-repoze.lru: Please provide python3 package

[Dmitrijs Ledkovs]

Control: tags -1 pending

Committed to team svn trunk.
Uploaded into delayed/15 queue.

Regards,

Dmitrijs.


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

Bug#704045: Bug is still present

[Dmitrijs Ledkovs]

The latter BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION is also needs to
be included, as per qtbug report:

"""
The BOOST_TT_HAS_OPERATOR_HPP_INCLUDED workaround isn't always working
with boost 1.53 because some of the type_traits headers are being
included outside of has_operator.hpp, for example lexical_cast.hpp
includes has_left_shift.hpp, which includes has_binary_operator.hpp

http://www.boost.org/doc/libs/1_53_0/boost/lexical_cast.hpp
http://www.boost.org/doc/libs/1_53_0/boost/type_traits/has_left_shift.hpp

An alternative workaround is -DBOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
"""

I have tested 4:4.8.5+dfsg-2 with boost1.54:

OK, builds:
> qsapecng

Unknown (configure error, unrelated):
> fatrat
> kdepim

BAD, Still fails:
> avogadro
> gofigure2
> ovito
> pokerth

Still building this beast:
> yade

Please upload a fix for this bug, there are only a few issues left
blocking boost1.54 transition.

Regards,

Dmitrijs.


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

Bug#709578: Source-hightlight boost1.53, NMU

[Dmitrijs Ledkovs]

Control: tag -1 patch pending

Uploaded below patch into delayed/7.

Regards,

Dmitrijs.


source-highlight.nmu.diff
Description: Binary data

Bug#709499: Is this bug really valid?

[Dmitrijs Ledkovs]

Looking at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709499
seems to be a duplicate of
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=695793 which is now
fixed.

Or is there something missing?

Regards,

Dmitrijs.


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

Bug#710081: Fix ftbfs with boost1.53 openchange

[Dmitrijs Ledkovs]

Control: tag -1 patch

Patch attached.

Regards,

Dmitrijs.


openchange.deb.diff
Description: Binary data

Bug#707252: Unable to connect to certain IMAPS servers requiring SSL3

[Dmitrijs Ledkovs]

On 10 July 2013 02:10, Ryan Kavanagh  wrote:
> Hi,
>
> On Sun, Jul 07, 2013 at 05:29:27PM -0400, Ryan Kavanagh wrote:
>> The attached patch appears to fix the bug; I've forwarded[0] it
>> upstream.
>
> The patch I submitted contained a bug, upstream has applied a corrected
> version. See the attached patch.

upstream, as in me ;-)

I will make a new upstream rc release and push that into unstable.

Regards,

Dmitrijs.


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

Bug#709577: sofa-framework: Package fails to build with Boost 1.53

[Dmitrijs Ledkovs]

Control: tag -1 patch

Here is patch to fix this bug. Note, I did a test build with gcc-4.7
due to FTBFS with gcc-4.8 bug.

Regards,

Dmitrijs.


sofa-framework.deb.diff
Description: Binary data

Bug#710082: openvrml FTBFS with Boost 1.53

[Dmitrijs Ledkovs]

Control: tag -1 patch

Here is partial patch, the downside is that I had to disable
javascript node portion.

Regards,

Dmitrijs.


openvrml.deb.diff
Description: Binary data

Bug#714787: Patch to add python3 package

[Dmitrijs Ledkovs]

tag 714787 patch
thanks

Patch attached to add python 3 package.

Regards,

Dmitrijs.


python3-paste.diff
Description: Binary data

Bug#714403: Patch to add python3 package

[Dmitrijs Ledkovs]

tag 714403 patch
thanks

Patch to add python3 package is attached.

Regards,

Dmitrijs.


python3-cherrypy3.diff
Description: Binary data

Bug#714787: python-paste: Please provide python3 package

[Dmitrijs Ledkovs]

Package: python-paste
Version: 1.7.5.1-4.1
Severity: normal

Dear Maintainer,
please provide python3 package, as I think paste is python3 compatible.

Regards,

Dmitrijs.


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

Bug#714784: python-repoze.lru: Please provide python3 package

[Dmitrijs Ledkovs]

Package: python-repoze.lru
Version: 0.6-1
Severity: normal

Dear Maintainer,

I'd like to run a python3 application that needs
python3-repoze.lru. python3-prepoze.lru package is python3 compatible.

May I commit and do a team upload to build python3 package?
Diff attached.

Regards,

Dmitrijs.

Index: debian/changelog
===
--- debian/changelog	(revision 25066)
+++ debian/changelog	(working copy)
@@ -1,3 +1,12 @@
+python-repoze.lru (0.6-2) UNRELEASED; urgency=low
+
+  * Team upload
+  * Add python3 package
+  * Bump debhelper to 9, standards to 3.8.4
+  * Install upstream changelog under proper name
+
+ -- Dmitrijs Ledkovs   Tue, 02 Jul 2013 20:38:00 +0100
+
 python-repoze.lru (0.6-1) unstable; urgency=low
 
   [ Jakub Wilk ]
Index: debian/compat
===
--- debian/compat	(revision 25066)
+++ debian/compat	(working copy)
@@ -1 +1 @@
-7
+9
Index: debian/control
===
--- debian/control	(revision 25066)
+++ debian/control	(working copy)
@@ -3,8 +3,9 @@
 Priority: extra
 Maintainer: Debian Python Modules Team 
 Uploaders: TANIGUCHI Takaki 
-Build-Depends: debhelper (>= 7.0.50~), python-setuptools, python-all
-Standards-Version: 3.9.3
+Build-Depends: debhelper (>= 9), python-setuptools, python-all, python3-setuptools, python3-all
+Standards-Version: 3.9.4
+X-Python3-Versions: >= 3.2
 Homepage: http://www.repoze.org/
 Vcs-Svn: svn://anonscm.debian.org/python-modules/packages/python-repoze.lru/trunk/
 Vcs-Browser: http://anonscm.debian.org/viewvc/python-modules/packages/python-repoze.lru/trunk/
@@ -17,3 +18,15 @@
  repoze.lru is a LRU (least recently used) cache implementation. Keys and
  values that are not used frequently will be evicted from the cache faster
  than keys and values that are used frequently.
+ . 
+ This is the Python 2 version of the package.
+
+Package: python3-repoze.lru
+Architecture: all
+Depends: ${python3:Depends}, ${misc:Depends}
+Description: tiny LRU cache implementation and decorator for Python 3
+ repoze.lru is a LRU (least recently used) cache implementation. Keys and
+ values that are not used frequently will be evicted from the cache faster
+ than keys and values that are used frequently.
+ . 
+ This is the Python 3 version of the package.
Index: debian/docs
===
--- debian/docs	(revision 25066)
+++ debian/docs	(working copy)
@@ -1,4 +1,2 @@
-CHANGES.txt
 COPYRIGHT.txt
 README.txt
-README.txt
Index: debian/python-repoze.lru.install
===
--- debian/python-repoze.lru.install	(revision 0)
+++ debian/python-repoze.lru.install	(working copy)
@@ -0,0 +1 @@
+/usr/lib/python2*
Index: debian/python3-repoze.lru.install
===
--- debian/python3-repoze.lru.install	(revision 0)
+++ debian/python3-repoze.lru.install	(working copy)
@@ -0,0 +1 @@
+/usr/lib/python3*
Index: debian/rules
===
--- debian/rules	(revision 25066)
+++ debian/rules	(working copy)
@@ -1,4 +1,29 @@
 #!/usr/bin/make -f
 
+PYTHON2:=$(shell pyversions -r)
+PYTHON3:=$(shell py3versions -r)
+py3sdo=set -e; $(foreach py, $(PYTHON3), $(py) $(1);)
+pyalldo=set -e; $(foreach py, $(PYTHON2) $(PYTHON3), $(py) $(1);)
+
 %:
-	dh $@ --with python2
+	dh $@ --with python2,python3
+
+override_dh_auto_build:
+	dh_auto_build
+	$(call py3sdo, setup.py build)
+
+override_dh_auto_install:
+	dh_auto_install
+	$(call py3sdo, setup.py install --root=$(CURDIR)/debian/tmp --install-layout=deb)
+
+override_dh_auto_clean:
+	dh_auto_clean
+	rm -rf build *.egg-info
+
+ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS)))
+override_dh_auto_test:
+	$(call pyalldo, setup.py test)
+endif
+
+override_dh_installchangelogs:
+	dh_installchangelogs CHANGES.txt

Bug#713794: vtk: FTBFS: make[2]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2

[Dmitrijs Ledkovs]

On 26 June 2013 08:59, Julien Cristau  wrote:
> On Tue, Jun 25, 2013 at 22:34:11 +0100, Dmitrijs Ledkovs wrote:
>
>> tag 713794 patch pending
>> thanks
>>
>> Uploaded into delayed/5 queue.
>>
> Your patch is missing a versioned dependency on python2.7 (and dpkg-dev
> 1.16.1).  It's also terrible that the path isn't detected automatically.
>

I disagree that versioned build-dependency on dpkg-dev is required,
and it's wrong for uploads to be rejected on that basis.
Also, please explain why a versioned dependency on python2.7 is
needed, and whether you mean build-dep or dep.
FindPythonLibs.cmake module correctly detects proper python paths and
can be hinted which version should be preferred (in case when multiple
pythons are available).
It's terrible that maintainer/upstream did not choose to use standard
cmake interface.
I just provided a minimal patch to resolve the issue.

Regards,

Dmitrijs.


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

Bug#714614: debhelper: A better way to check for make targets

[Dmitrijs Ledkovs]

Package: debhelper
Version: 9.20130630
Severity: normal

Dear Maintainer,
in light of recent make target detection code bugs #706923, #707481,
#713257 I have yet another one.

Using hello source package with following rules file & debian/compat 9:
%:
dh $@

override_dh_auto_test:
mkdir -p test
dh_auto_test

Results in testsuite target "check" to not be executed. since `make -s
-n test` exits with 0 "nothing to be done with test".

But looking at bash-completion package it does manage to correctly
detect that test target doesn't exist, yet check target does.

Bash-completion executes this to find all make targets:
make -qp | awk -F':' '/^[a-zA-Z0-9][^$#\/\t=]*:([^=]|$)/ \
{split($1,A,/ /);for(i in A)print A[i]}'

Maybe something similar to above can be used to search for make targets
in debhelper? Seems like a slightly more reliable way to do so.

Regards,

Dmitrijs.


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

Bug#714403: cherrypy3: Please provide python3-cherrypy3 package

[Dmitrijs Ledkovs]

Package: cherrypy3
Severity: wishlist
Version: 3.2.2-2

Dear Maintainer,

Upstream support python3, please package python3-cherrypy3 package.

Regards,

Dmitrijs.


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

Bug#714402: python-routes: Please add python3 package

[Dmitrijs Ledkovs]

Package: python-routes
Version: 1.13-2
Severity: wishlist

Dear Maintainer,

Upstream has recently added python3 support. [1] Please package it.

[1] 
https://github.com/bbangert/routes/commit/77d77a7453ed09d1c0c75ee44f2996b62804685b

Regards,

Dmitrijs.


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

Bug#707512: emacs23: FTBFS: /bin/bash: line 3: cd: /«BUILDDIR»/emacs23-23.4+1/debian/emacs23-el: No such file or directory

[Dmitrijs Ledkovs]

tag 707512 patch pending
thanks

Uploaded to delayed/5.

Regards,

Dmitrijs.


emacs23.deb.diff
Description: Binary data

Bug#707488: emacs24: FTBFS: /bin/bash: line 3: cd: /«BUILDDIR»/emacs24-24.3+1/debian/emacs24-el: No such file or directory

[Dmitrijs Ledkovs]

tags 707488 pending
thanks

Uploaded to delayed/5.

Regards,

Dmitrijs.


emacs24.deb.diff
Description: Binary data

Bug#713794: vtk: FTBFS: make[2]: *** [Wrapping/CMakeFiles/vtkWrapPython.dir/all] Error 2

[Dmitrijs Ledkovs]

tag 713794 patch pending
thanks

Uploaded into delayed/5 queue.

Regards,

Dmitrijs.


vtk.deb.diff
Description: Binary data

Bug#714104: crypsetup: Do not unconditionally include cryptsetup in initramfs

[Dmitrijs Ledkovs]

Package: crypsetup
Severity: normal
Version: 2:1.4.3-4
Tags: patch

Dear Maintainer,

at the moment crypsetup initramfs hook unconditionally includes
cryptsetup in the in initramfs, whether its needed to mount root file
system or not.

I am proposing a two-fold fix to the above problem.

First patch, fixes the bug, where after having performed multiple checks
to see if the root filesystem is encrypted or not, it was deemed to
discard the checks results and claim that nonetheless root file system
is encrypted.

The above is sufficient to cause cryptsetup to be excluded on machines
that have modified /etc/initramfs-tools/initramfs.conf and set MODULES
to something other than most.

The second patch, goes further. It changes the behaviour such that if
and only if rootfs is encrypted cryptsetup utilities & modules are
included in the initramfs, and MODULES variable is consulted to include
only needed modules or to include standard ones as well.

I understand that there is a corner case, where one might want to
generate initramfs on one machine, on behalf of another one. For this
case, I include a check of setting CRYPTSETUP. If this hunk is also
accepted, the documentation & default setting CRYPTSETUP=n will be then
proposed to the initramfs-tools package.

I have tested this patch extensively using various combinations of
installation types including ecryptfs & lvm2. These changes have also
been uploaded in Ubuntu Saucy, with no regressions identified thus far.

Regards,

Dmitrijs.

diff -Nru cryptsetup-1.4.3/debian/initramfs/cryptroot-hook cryptsetup-1.4.3/debian/initramfs/cryptroot-hook
--- cryptsetup-1.4.3/debian/initramfs/cryptroot-hook	2012-04-11 22:34:23.0 +0100
+++ cryptsetup-1.4.3/debian/initramfs/cryptroot-hook	2013-06-10 17:04:25.0 +0100
@@ -518,7 +524,14 @@
 		echo "cryptsetup: FAILURE: could not determine configuration for $dev" >&2
 		continue
 	fi
-	setup="yes"
+
+	if [ -n "$modules" ]; then
+	setup="yes"
+	fi
+
+	if [ "$setup" = "no" ]; then
+	continue
+	fi
 
 	if [ "$MODULES" = "most" ]; then
 		archcrypto="$(find "$MODULESDIR/kernel/arch" -type d -name "crypto" 2>/dev/null)"
diff -Nru cryptsetup-1.4.3/debian/initramfs/cryptroot-hook cryptsetup-1.4.3/debian/initramfs/cryptroot-hook
--- cryptsetup-1.4.3/debian/initramfs/cryptroot-hook	2012-04-11 22:34:23.0 +0100
+++ cryptsetup-1.4.3/debian/initramfs/cryptroot-hook	2013-06-10 17:04:25.0 +0100
@@ -503,6 +503,12 @@
 rootdev=""
 resumedevs=""
 
+# Include cryptsetup modules, regardless of _this_ machine
+# configuration
+if [ -n "$CRYPTSETUP" ] && [ "$CRYPTSETUP" != "n" ]; then
+setup="yes"
+fi
+
 # Find the root and resume device(s)
 if [ -r /etc/crypttab ]; then
 	rootdev=$(get_root_device)
@@ -534,14 +547,14 @@
 done
 
 # With large initramfs, we always add a basic subset of modules
-if [ "$MODULES" != "dep" ]; then
+if [ "$MODULES" != "dep" ] && [ "$setup" = "yes" ]; then
 	for mod in aes cbc chainiv cryptomgr krng sha256 xts; do
 		add_crypto_modules $mod
 	done
 fi
 
 # See if we need to add the basic components
-if [ "$MODULES" != "dep" ] || [ "$setup" = "yes" ]; then
+if [ "$setup" = "yes" ]; then
 	for mod in dm_mod dm_crypt; do
 		manual_add_modules $mod
 	done

Bug#714102: libkolabxml: add more -dev dependencies

[Dmitrijs Ledkovs]

Package: libkolabxml
Severity: normal
Version: 0.8.4-3
Tags: patch

Dear Maintainer,
Please consider making the -dev package depending on the following -dev
packages:
libboost-system-dev, libboost-thread-dev, libxerces-c-dev

As far as I can tell, without above packages it's not possible to
link/compile against libkolabxml.

Regards,

Dmitrijs.

diff -Nru libkolabxml-0.8.4/debian/control libkolabxml-0.8.4/debian/control
--- libkolabxml-0.8.4/debian/control	2013-05-24 22:27:09.0 +0100
+++ libkolabxml-0.8.4/debian/control	2013-06-24 12:27:34.0 +0100
@@ -62,7 +63,8 @@
 Section: libdevel
 Architecture: any
 Depends: libkolabxml0 (= ${binary:Version}),
- ${misc:Depends}
+ ${misc:Depends},
+	 libboost-system-dev, libboost-thread-dev, libxerces-c-dev
 Description: Development files for libkolabxml
  Libkolabxml is the reference implementation of the Kolab XML format.
  For more information see the libkolabxml package.

Bug#712697: ruby-railties-3.2: conflict with rails < 3:3.2.0 while rails is at 2:3.2.13+1

[Dmitrijs Ledkovs]

tag 712697 pending patch
thanks

Uploaded to DELAYED/5, as this is blocking redmine migrating to testing.

Regards,

Dmitrijs.


712697.debdiff
Description: Binary data

Bug#713978: hostname: add upstart init support

[Dmitrijs Ledkovs]

Package: hostname
Version: 3.13
Severity: normal
Tags: patch
User: upst...@packages.deban.org
Usertags: upstart-job

Dear Maintainer,

please consider applying the following patch that adds upstart
integration to set hostname at boot time.

I know that under sysv init, initscripts package ships
/etc/init.d/hostname.sh. But it seems out of place for upstart package
to ship hostname job file, when hostname package ships the binary. To me
hostname package is a better place to ship upstart job file to set
hostname, thus giving you control as to which args should be used by
default.

I have tested proposed changes on debian sid, with both sysvinit and
upstart.

There are two jobs provided: hostname & hostname.sh. The first one is
the one that sets the hostname, the second one is there for sysv
compatibility.

Regards,

Dmitrijs.

diff -Nru hostname-3.13/debian/changelog hostname-3.13+nmu1/debian/changelog
--- hostname-3.13/debian/changelog	2013-06-18 10:52:28.0 +0100
+++ hostname-3.13+nmu1/debian/changelog	2013-06-24 13:10:16.0 +0100
@@ -1,3 +1,12 @@
+hostname (3.13+nmu1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Provide upstart job to set hostname, and a dummy job hostname.sh, to
+stay backwards compatible with sysv init scripts relying on the
+previous name.
+
+ -- Dmitrijs Ledkovs   Fri, 21 Jun 2013 16:23:15 +0100
+
 hostname (3.13) unstable; urgency=low
 
   * Finally completely remove verbose option.
diff -Nru hostname-3.13/debian/hostname.hostname.sh.upstart hostname-3.13+nmu1/debian/hostname.hostname.sh.upstart
--- hostname-3.13/debian/hostname.hostname.sh.upstart	1970-01-01 01:00:00.0 +0100
+++ hostname-3.13+nmu1/debian/hostname.hostname.sh.upstart	2013-06-21 16:13:37.0 +0100
@@ -0,0 +1,9 @@
+# hostname.sh - compatibility job for sysvinit dependencies
+#
+# This job runs once hostname job finished running, to signal startpar
+# that other rcS jobs relying on the historic hostname.sh interface
+# can continue.
+
+description "Signal sysvinit that hostname is set"
+
+start on stopped hostname
diff -Nru hostname-3.13/debian/hostname.hostname.upstart hostname-3.13+nmu1/debian/hostname.hostname.upstart
--- hostname-3.13/debian/hostname.hostname.upstart	1970-01-01 01:00:00.0 +0100
+++ hostname-3.13+nmu1/debian/hostname.hostname.upstart	2013-06-21 16:08:37.0 +0100
@@ -0,0 +1,12 @@
+#
+# This task is run on startup to set the system hostname from /etc/hostname,
+# falling back to "localhost" if that file is not readable or is empty and
+# no hostname has yet been set.
+
+description "set system hostname"
+
+start on startup
+
+task
+exec hostname -b -F /etc/hostname
+
diff -Nru hostname-3.13/debian/rules hostname-3.13+nmu1/debian/rules
--- hostname-3.13/debian/rules	2012-01-15 12:50:32.0 +
+++ hostname-3.13+nmu1/debian/rules	2013-06-24 15:03:50.0 +0100
@@ -59,6 +59,8 @@
 	dh_installchangelogs
 	dh_installdocs
 	dh_install
+	dh_installinit --no-start --name hostname
+	dh_installinit --no-start --name hostname.sh -- start 02 S .
 	dh_strip
 	dh_compress
 	dh_fixperms

Bug#712185: at: add upstart init support

[Dmitrijs Ledkovs]

tag 712185 -moreinfo
thanks

On 14 June 2013 07:49, Ansgar Burchardt  wrote:
> Dmitrijs Ledkovs  writes:
>> --- at-3.1.13.orig/rc
>> +++ at-3.1.13/rc
>> @@ -21,6 +21,17 @@
>>
>>  . /lib/lsb/init-functions
>>
>> +if init_is_upstart; then
>> +case "$1" in
>> + stop)
>> + exit 0
>> + ;;
>> + *)
>> + exit 1
>> + ;;
>> +esac
>> +fi
>> +
>>  case "$1" in
>>start)
>>   log_daemon_msg "Starting deferred execution scheduler" "atd"
>
> I don't want to have a Debian-specific diff. Why is this required? Can't
> upstart detect by itself that it doesn't have to use this init script?
>

Upstart/update-rc.d/service do not require above to determine whether
or not the init script should be used.

Above is only a safe-guard against directly executing the init.d
script by the system administrator or any third party tools. The
"service" command should be used instead, which correctly can detect
whether to invoke upstart or sysv init.d scripts.

Please also see a thread, I started on debian-devel [1], about this
issue. This safe guard can be alternatively implemented without
modifying init scripts. But that also has it's down-sides. That thread
also includes links to the debian policy bug where it was introduced
to include user-guards in the init.d scripts.

>From my point of view, including/installing upstart job with
dh_installinit is the only piece that is required to integrate your
package correctly with both upstart & sysv init at the same time.
Leaving out modifications to the init.d script.

[1] http://lists.debian.org/debian-devel/2013/06/msg00658.html


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

Bug#712985: cloud-init: Correctly implement Debian Policy 9.11.1 w.r.t integrating alternative init system

[Dmitrijs Ledkovs]

Package: cloud-init
Severity: serious
Tags: patch
User: upst...@packages.debian.org
Usertags: upstart-job

Dear Maintainer,

Your package correctly provides upstart job file and sysv init
script. To fully comply with Debian Policy 9.11.1 [1] w.r.t. integrating with
upstart, the init.d script must also include a safeguard, in case
upstart is currently PID 1.

I have prepared a patch with that check integrated, please consider to
apply it in your package.

I have not tested bringing up Debian cloud-init instances with usptart
as pid 1, as that's a non-trivial task.

diff -Nru cloud-init-0.7.2/debian/changelog cloud-init-0.7.2/debian/changelog
--- cloud-init-0.7.2/debian/changelog	2013-05-29 07:21:09.0 +0100
+++ cloud-init-0.7.2/debian/changelog	2013-06-21 14:39:06.0 +0100
@@ -1,3 +1,13 @@
+cloud-init (0.7.2-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Comply with debian policy 9.11.1 by checking if init is upstart and
+exiting in the init.d script.
+  * Depend on lsb-base 4.1+Debian3 or higher to use init_is_upstart
+function.
+
+ -- Dmitrijs Ledkovs   Fri, 21 Jun 2013 14:37:18 +0100
+
 cloud-init (0.7.2-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru cloud-init-0.7.2/debian/cloud-init.init cloud-init-0.7.2/debian/cloud-init.init
--- cloud-init-0.7.2/debian/cloud-init.init	2013-05-27 14:58:26.0 +0100
+++ cloud-init-0.7.2/debian/cloud-init.init	2013-06-21 14:37:13.0 +0100
@@ -33,6 +33,17 @@
 # and status_of_proc is working.
 . /lib/lsb/init-functions
 
+if init_is_upstart; then
+case "$1" in
+	stop)
+	exit 0
+	;;
+	*)
+	exit 1
+	;;
+esac
+fi
+
 case "$1" in
 start)
 	log_daemon_msg "Starting $DESC" "$NAME"
diff -Nru cloud-init-0.7.2/debian/control cloud-init-0.7.2/debian/control
--- cloud-init-0.7.2/debian/control	2013-05-29 07:20:59.0 +0100
+++ cloud-init-0.7.2/debian/control	2013-06-21 14:38:41.0 +0100
@@ -26,7 +26,7 @@
 
 Package: cloud-init
 Architecture: all
-Depends: lsb-base,
+Depends: lsb-base (>= 4.1+Debian3),
  ifupdown,
  procps,
  python,

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-upstart

Regards,

Dmitrijs.

Bug#712763: upstart: implementing Debian Policy §9.11.1

[Dmitrijs Ledkovs]

Package: upstart
Version: 1.6.1-1
Severity: normal

Reading Debian Policy §9.11.1 [1] and the recommendations on
implementing it [2] results in a few undesirable properties:

* one needs to modify sysv init.d scripts
* the code in the init.d scripts does nothing when upstart is not
installer or not running
* the init.d scripts becomes less portable

But considering the fact that If upstart is not installed, initctl
will not be present in the $PATH and thus init_is_upstart will always
return 1, as well as the init-functions providing hooks directory
/lib/lsb/init-functions.d the debian policy can be implemented in an
alternative way:

* upstart package ships /lib/lsb/init-functions.d/70-upstart with
contents similar to the attached file

If upstart package is installed, all init.d scripts will continue to
work correctly or will abort with the appropriate status if upstart is
managing that particular job.
If upstart is currently PID 1, yet upstart package was removed, the
system is in flux anyway as upstart's binaries are gone and it will be
hard to do a clean shutdown.
No changes are required to init.d scripts and packages correctly
integrate with upstart, once upstart is installed. Unless init.d
script does not source /lib/lsb/init-functions, in that case one
either migrates to do so, or executes the check as per policy.

[1] http://www.debian.org/doc/debian-policy/ch-opersys.html#s-alternateinit
[2] https://wiki.ubuntu.com/UpstartCompatibleInitScripts

Regards,

Dmitrijs.


upstart-lsb.sh
Description: Bourne shell script

Bug#712630: ITP: pyqt5 -- Python bindings for Qt5

[Dmitrijs Ledkovs]

On 18 June 2013 05:12, Scott Kitterman  wrote:
>
> This will have binaries for both python and python3 as both are
> supported.  DPMT will be the maintainer and I'll be an uploader.  Anyone
> who wants to work on putting this together, please let me know.
>

I'd be interested. I haven't looked into details, but are:
lp:~xnox/ubuntu/raring/python-qt4/qt5
lp:~mitya57/+junk/wip-pyqt5-packaging

of any use? Have you started packaging yet? I don't see anything
committed in DPMT svn.

Regards,

Dmitrijs.


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

Bug#680686: jessie release goal: verbose build logs

[Dmitrijs Ledkovs]

tags 680686 patch
thanks

On 14 June 2013 12:35, Matthias Klose  wrote:
>
>  - Fix debhelper not passing --disable-silent-rules by default.
>#680686
>I think cdbs already does this.

Patch attached for autoconf dh build system. cmake dh build system
seems to be already enabling verbose makefiles.

Regards,

Dmitrijs.


0001-Buildsystems-autoconf-pass-disable-silent-rules-to-c.patch
Description: Binary data

Bug#712167: dbus: add upstart init support

[Dmitrijs Ledkovs]

On 14 June 2013 12:49, Simon McVittie  wrote:
> On Fri, 14 Jun 2013 at 12:16:28 +0100, Simon McVittie wrote:
>> On Thu, 13 Jun 2013 at 19:23:46 +0100, Dmitrijs Ledkovs wrote:
>> > The upstart job attached will continue to honour existing
>> > settings for additional parameters from /etc/default/dbus, just like
>> > the current init.d script.
>>
>> Do/should we support that file at all? I can't see anything in dbus-daemon
>> --help that you could put there without breaking system integration
>
>
> Similarly, if you disable or alter the pidfile in the XML, sysvinit
> and Upstart are not going to work correctly. systemd never needs the
> pidfile (because it runs dbus-daemon with --nofork, so it's trivial
> to know the pid), so it uses --nopidfile for a small performance boost.
>

Upstart doesn't track pidfiles at all. At the moment it's set to fork,
but could as well use --nofork & --nopidfile, for what performance
boosts its worth.
And upstart would then properly collect stdout/stderr into a logfile
under /var/log/upstart/dbus.log.
That does invalidate my pidfile hack in the postinst though. I guess
it does makes sense to trigger it unconditionally as well.

Regards

Dmitrijs.


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

Bug#712167: dbus: add upstart init support

[Dmitrijs Ledkovs]

On 14 June 2013 12:16, Simon McVittie  wrote:
> On Thu, 13 Jun 2013 at 19:23:46 +0100, Dmitrijs Ledkovs wrote:
>> please consider applying the following patch that adds upstart
>> integration for the dbus package.
>
> pkg-utopia are probably aware, but: dbus/testing has a CVE, so please don't
> upload dbus/unstable until 1.6.12 has migrated.
>
>> The upstart job attached will continue to honour existing
>> settings for additional parameters from /etc/default/dbus, just like
>> the current init.d script.
>
> Do/should we support that file at all? I can't see anything in dbus-daemon

I'd drop sourcing /etc/default/dbus with pleasure. This simplifies the
job file, making it more upstart like.

>
>> Also conditional check whether dbus is
>> running under upstart is added in the dbus.postinst for the upgrade
>> notification.
>
> This is an increasing amount of code to detect whether the dbus-daemon
> is running, so that we know whether to prompt the user to reboot.
>

Taking in your suggestion about pgrep/unconditional trigger, how about
something like this?

read pid < /var/run/dbus/pid
[ -n "${pid:-}" ] && $(kill -0 "${pid:-}" 2> /dev/null) && \
[ -x /usr/share/update-notifier/notify-reboot-required ] && \
/usr/share/update-notifier/notify-reboot-required || true

This should work with sysvinit, upstart and systemd. This is roughly
inspired by status_of_proc from /lib/lsb/init-functions
It still has opportunity for false positives (stale pids), but is
probably good enough.

Updated patch attached.

Regards,

Dmitrijs


dbus-upstart-2.deb.diff
Description: Binary data