Bug#698493: vym: cannot undo accidental removal of the root node

[Sven Hoexter]

Hi,
I can not reproduce the issue with the latest vym release. Removing and 
restoring via
undo seems to work just fine in new documents.

Can you confirm that as well?

Sven

Bug#1070357: bookworm-pu: package tcl-unix-sockets/0.5-1

[Sven Hoexter]

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

Hi,
please reject that package from p-u NEW. I'm sorry for the
faulty upload, this one should've targeted unstable.

Sven

Bug#1068425: pflogsumm: Postfix logs days in month < 10 with leading zeroes, pflogsumm expects space padding

[Sven Hoexter]

On Fri, Apr 05, 2024 at 01:01:52AM +0200, Magnus Stenman wrote:

Hi,
sorry for the delay, I just started to briefly look into the issue.

> Pflogsumm reports zero mails on day 1-9 of every month
> 
> Stock debian postfix version
> 
> Patch:
> --- /usr/sbin/pflogsumm.orig2024-04-05 00:45:38.214914066 +0200
> +++ /usr/sbin/pflogsumm 2024-04-05 00:45:44.710952673 +0200
> @@ -1518,7 +1518,7 @@
>  }
>  my ($t_mday, $t_mon, $t_year) = (localtime($time))[3,4,5];
> 
> -return sprintf("%s %2d", $monthNames[$t_mon], $t_mday), 
> sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
> +return sprintf("%s %02d", $monthNames[$t_mon], $t_mday), 
> sprintf("%04d-%02d-%02d", $t_year+1900, $t_mon+1, $t_mday);
>  }

It's been a while I looked into pflogsumm and for me it still works,
but I do not rely for a long time on the traditional BSD syslog format.
Also Debian doesn't do that by default for some time, so I'm wondering
what exactly your logs look like. If possible please provide a sample.
Also how did you invoke pflogsumm, any flags in use?

According to RFC3164 section 4.1.2 there isn't zero padding but space
padding in the traditional timestamp. Likely there is a bug
somewhere, maybe even in one of the other patches I carry in the
package, but I believe the format returned here, without zero
padding on the day of the month is correct.

Sven

Bug#1055350: bookworm-pu: package exfatprogs/1.2.0-1+deb12u1

[Sven Hoexter]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: exfatpr...@packages.debian.org
Control: affects -1 + src:exfatprogs

[ Reason ]
https://security-tracker.debian.org/tracker/CVE-2023-45897
Low priority security issue, out-of-bounds memory access
in the exFAT fsck utility exfat2img helper.

[ Impact ]
Low priority security issue is fixed.

[ Tests ]
Manual tests performed that effected tools still work.

[ Risks ]
-

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
Adds a patch bundling the three upstream commits
which are referenced together with the CVE ID.

gbp.conf and Vcs-Git reference the bookworm branch


[ Other info ]
There wasn't a bug filled for this CVE in the BTS.
The regular upload of 1.2.2 to unstable fixed the
issue before the CVE ID was published, so there
is not yet a CVE ID mentioned in the unstable
changelog.
diff -Nru exfatprogs-1.2.0/debian/changelog exfatprogs-1.2.0/debian/changelog
--- exfatprogs-1.2.0/debian/changelog   2022-10-28 14:48:05.0 +0200
+++ exfatprogs-1.2.0/debian/changelog   2023-11-04 17:56:01.0 +0100
@@ -1,3 +1,11 @@
+exfatprogs (1.2.0-1+deb12u1) bookworm; urgency=medium
+
+  * CVE-2023-45897 Add 
debian/patches/CVE-2023-45897-out-of-bounds-memory-access
+to fix three out-of-bounds memory access issues.
+  * Add bookworm branch information to Vcs-Git and gbp.conf.
+
+ -- Sven Hoexter   Sat, 04 Nov 2023 17:56:01 +0100
+
 exfatprogs (1.2.0-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru exfatprogs-1.2.0/debian/control exfatprogs-1.2.0/debian/control
--- exfatprogs-1.2.0/debian/control 2022-10-28 14:47:18.0 +0200
+++ exfatprogs-1.2.0/debian/control 2023-11-04 17:38:34.0 +0100
@@ -6,7 +6,7 @@
 Standards-Version: 4.6.1
 Rules-Requires-Root: no
 Homepage: https://github.com/exfatprogs/exfatprogs
-Vcs-Git: https://git.sven.stormbind.net/exfatprogs.git
+Vcs-Git: https://git.sven.stormbind.net/exfatprogs.git -b bookworm
 Vcs-Browser: https://git.sven.stormbind.net/?p=sven/exfatprogs.git
 
 Package: exfatprogs
diff -Nru exfatprogs-1.2.0/debian/gbp.conf exfatprogs-1.2.0/debian/gbp.conf
--- exfatprogs-1.2.0/debian/gbp.conf2022-10-28 14:19:18.0 +0200
+++ exfatprogs-1.2.0/debian/gbp.conf2023-11-04 16:39:40.0 +0100
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = bookworm
diff -Nru 
exfatprogs-1.2.0/debian/patches/CVE-2023-45897-out-of-bounds-memory-access 
exfatprogs-1.2.0/debian/patches/CVE-2023-45897-out-of-bounds-memory-access
--- exfatprogs-1.2.0/debian/patches/CVE-2023-45897-out-of-bounds-memory-access  
1970-01-01 01:00:00.0 +0100
+++ exfatprogs-1.2.0/debian/patches/CVE-2023-45897-out-of-bounds-memory-access  
2023-11-04 16:39:40.0 +0100
@@ -0,0 +1,67 @@
+Description: CVE-2023-45897 out-of-bounds memory access
+Origin: 
https://github.com/exfatprogs/exfatprogs/commit/ec78688e5fb5a70e13df82b4c0da1e6228d3ccdf
+ 
https://github.com/exfatprogs/exfatprogs/commit/22d0e43e8d24119cbfc6efafabb0dec6517a86c4
+ 
https://github.com/exfatprogs/exfatprogs/commit/4abc55e976573991e6a1117bb2b3711e59da07ae
+Last-Update: 2023-10-31
+Index: exfatprogs/exfat2img/exfat2img.c
+===
+--- exfatprogs.orig/exfat2img/exfat2img.c
 exfatprogs/exfat2img/exfat2img.c
+@@ -319,7 +319,7 @@ static int read_file_dentry_set(struct e
+   if (!node)
+   return -ENOMEM;
+ 
+-  for (i = 2; i <= file_de->file_num_ext; i++) {
++  for (i = 2; i <= MIN(file_de->file_num_ext, 1 + MAX_NAME_DENTRIES); 
i++) {
+   ret = exfat_de_iter_get(iter, i, );
+   if (ret || dentry->type != EXFAT_NAME)
+   break;
+Index: exfatprogs/fsck/fsck.c
+===
+--- exfatprogs.orig/fsck/fsck.c
 exfatprogs/fsck/fsck.c
+@@ -769,7 +769,7 @@ ask_again:
+   char *rename = NULL;
+   __u16 hash;
+   struct exfat_dentry *stream_de;
+-  int name_len, ret;
++  int ret;
+ 
+   switch (num) {
+   case 1:
+@@ -798,11 +798,11 @@ ask_again:
+   if (ret < 0)
+   return ret;
+ 
++  ret >>=1;
+   memcpy(dentry->name_unicode, utf16_name, ENTRY_NAME_MAX * 2);
+-  name_len = exfat_utf16_len(utf16_name, ENTRY_NAME_MAX * 2);
+-  hash = exfat_calc_name_hash(iter->exfat, utf16_name, 
(int)name_len);
++  hash = exfat_calc_name_hash(iter->exfat, utf16_name, ret);
+   exfat_de_iter_get_dirty(iter, 1, _de);
+-  stream_de->stream_name_len = (__u8)name_len;
++

Bug#1040006: pflogsumm: fails to count sent emails

[Sven Hoexter]

On Fri, Jun 30, 2023 at 11:47:33PM +0200, Yvan Masson wrote:

Hi,

> I use pflogsumm on a Bullseye system, to analyze Postfix 3.5.17 logs. It is
> possible my setup has some oddities, but while pflogsumm is globally
> working, it fails to count sent emails:

Hi,
I can not reproduce that on my own system, though I'm already working
with bookworm which means postfix 3.7.x. As far as I remember pflogsumm
was in general working fine on bullseye.

Also oldstable aka bullseye already contains postfix 3.5.18, not sure why
you're running 3.5.17.

Since bullseye is now oldstable, there won't be any updates regarding this
issue for bullseye anyway.

What would be of interest is if the issue could be reproduced on current
Debian release. In that case a log sample would be also helpful.

Sven

Bug#1030082: Directory missing on ExFAT Drives

[Sven Hoexter]

On Mon, Jan 30, 2023 at 04:49:40PM -0600, Devin Lieberman wrote:

Hi,

> When mounting exfat XQD cards formatted by my Sony FS7, the Clips folder
> and MXF video files contained therein do not appear despite still existing.
> Upon cd into Clips, ls -la shows the BIM and XML sidecar files created at
> the time of recording but not the video files. Writing to the disk causes
> all files to similarly disappear. When mounted with mount.exfat-fuse, the
> Clips folder appears as do the video files. I'm using a Thinkpad X1 Nano
> Gen 2 Intel 1260P. Here's the transcript:

I already replied in private to Devin. Short summary in public here:
It's an issue with the Linux exFAT driver not with exfatprogs, which
only provide the filsystem utilities.

Sven

Bug#1028196: offlineimap3: Python 3.11 breaks SQLite Multithread Check

[Sven Hoexter]

Package: offlineimap3
Version: 0.0~git20211018.e64c254+dfsg-1
Severity: grave
Justification: renders package unusable

Hi,
with the introduction of Python 3.11 offlineimap does no longer work
due to a failing multithread safety check for SQLite.
The issue was handled upstream in
https://github.com/OfflineIMAP/offlineimap3/pull/139
The patch included upstream applies cleanly to the slightly older
release in unstable and works fine as far as I can tell after a day.

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

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

Versions of packages offlineimap3 depends on:
ii  ca-certificates   20211016
ii  python3   3.11.1-1
ii  python3-distro1.8.0-1
ii  python3-imaplib2  2.57-5.2

offlineimap3 recommends no packages.

Versions of packages offlineimap3 suggests:
pn  python3-gssapi  

-- no debconf information

Bug#997201: Fio ftbfs should be fixed in 3.28 or later

[Sven Hoexter]

Hi,
already had some private mail exchange with Martin, so just for public 
reference:
Looks like 
https://github.com/axboe/fio/commit/382975557e632efb506836bc1709789e615c9094
is the solution to this issue. This is part of the 3.28 release.
I guess we work on packaging a new upstream release soon.

Sven

Bug#992286: Patch to migrate to exfatprogs

[Sven Hoexter]

tags 992286 patch
thanks

Hi,
I've created a PR to migrate to exfatprogs now. I would really like to get rid
of at least exfat-utils soon.

https://salsa.debian.org/libvirt-team/libguestfs/-/merge_requests/1

Joseph, since I would like to remove exfat-fuse and exfat-utils from Debian
I see no point in making them an alternative. If someone needs it for a backport
he should add it only for the backport. But opinions might differ on that one.

Cheers,
Sven
diff --git a/debian/changelog b/debian/changelog
index ad8d629a2..571706100 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+libguestfs (1:1.44.1-6) UNRELEASED; urgency=medium
+
+  * Migrate from exfat-utils and exfat-fuse to exfatprogs.
+Since bullseye we have in kernel support for exFAT, no need to rely
+on the fuse implementation anymore.
+
+ -- Sven Höxter   Wed, 06 Oct 2021 14:47:03 +0200
+
 libguestfs (1:1.44.1-5) unstable; urgency=medium
 
   * Attempt to fix running tests
diff --git a/debian/check-appliance-build-deps.sh b/debian/check-appliance-build-deps.sh
index ee5a9d84d..44a0f058b 100755
--- a/debian/check-appliance-build-deps.sh
+++ b/debian/check-appliance-build-deps.sh
@@ -13,7 +13,7 @@ m4 -DDEBIAN=1 -DEXTRA_PACKAGES= appliance/packagelist.in \
 | tr ' ' '\n' \
 | sed -e '/^$/d' \
   -e '/^\(bash\|coreutils\|dash\|diffutils\|findutils\|grep\|gzip\|libc-bin\|sed\|tar\|util-linux\)$/d' \
-  -e '/\(btrfs-tools\|fuse-exfat\|gfs2*-tools\|iproute\|module-init-tools\|procps-ng\)$/d' \
+  -e '/\(btrfs-tools\|exfat-fuse\|exfat-utils\|fuse-exfat\|gfs2*-tools\|iproute\|module-init-tools\|procps-ng\)$/d' \
 | grep -v ^lib \
 | grep -v ufsutils \
 | sort -u \
diff --git a/debian/control b/debian/control
index 9c1c827d4..2e8f9dbfc 100644
--- a/debian/control
+++ b/debian/control
@@ -63,7 +63,7 @@ Build-Depends: debhelper (>= 12),
   curl,
   debootstrap,
   dosfstools,
-  exfat-fuse, exfat-utils,
+  exfatprogs,
   extlinux [i386 amd64],
   f2fs-tools,
   fdisk,

Bug#995772: please use alternatives instead of conflicting with exfat-utils

[Sven Hoexter]

On Tue, Oct 05, 2021 at 08:42:58AM -0400, Marvin Renich wrote:

Hey Marvin,

> Please coordinate with exfat-utils maintainer and use the alternative
> system to allow both packages to be installed at the same time

I already coordinated with myself that exfat-utils and exfat-fuse will be
removed. It's not worth doing any stunts to support both implementations
without any gain. Bugs or PRs were already created to ask maintainer of the
few reverse dependencies to switch to exfatprogs only. By now most
alternate with exfatprogs | exfat-utils.

Bugs are:
libgustfs0 #992286
progess-linux-desktop #992287
bfh-desktop #992285
forensics-extra merged a PR

Cheers,
Sven

Bug#994690: udisks2: Switch to exfatprogs mkfs.exfat incomplete

[Sven Hoexter]

Package: udisks2
Version: 2.9.3-1
Severity: normal
Tags: patch

Hi Michael,
due to a bugreport for exfatprogs[1] I took note of
#992152 which tried to move from exfat-utils to exfatprogs.
Thanks for moving on with that one, much appreciated. Sadly
the switch is not that easy since the commandline flags
differ. The exfat-utils mkfs tool used '-n' for labeling but
exfatprogs authors choose the more common '-L'.

The fix should be a rather trivial one-char change:

--- udiskslinuxfsinfo.c.orig2021-09-19 15:27:08.945433340 +0200
+++ udiskslinuxfsinfo.c 2021-09-19 15:29:11.750075406 +0200
@@ -123,7 +123,7 @@
   NULL,
   FALSE, /* supports_online_label_rename */
   FALSE, /* supports_owners */
-  "mkfs.exfat -n $LABEL $DEVICE",
+  "mkfs.exfat -L $LABEL $DEVICE",
   NULL,
   NULL, /* option_no_discard */
 },

Regards,
Sven

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994529

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

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

Versions of packages udisks2 depends on:
ii  dbus   1.12.20-2
ii  libacl12.3.1-1
pn  libatasmart4   
pn  libblockdev-fs2
pn  libblockdev-loop2  
pn  libblockdev-part2  
pn  libblockdev-swap2  
pn  libblockdev-utils2 
pn  libblockdev2   
ii  libc6  2.32-3
ii  libglib2.0-0   2.68.4-1
ii  libgudev-1.0-0 237-2
ii  libmount1  2.37.2-2
ii  libpolkit-agent-1-00.105-31
ii  libpolkit-gobject-1-0  0.105-31
ii  libsystemd0247.9-1
pn  libudisks2-0   
ii  libuuid1   2.37.2-2
pn  parted 
ii  udev   247.9-1

Versions of packages udisks2 recommends:
ii  dosfstools   4.2-1
ii  e2fsprogs1.46.4-1
pn  eject
ii  exfatprogs   1.1.2-2
pn  libblockdev-crypto2  
ii  libpam-systemd   247.9-1
pn  ntfs-3g  
ii  policykit-1  0.105-31

Versions of packages udisks2 suggests:
pn  btrfs-progs  
pn  f2fs-tools   
pn  libblockdev-mdraid2  
pn  mdadm
pn  nilfs-tools  
pn  reiserfsprogs
pn  udftools 
pn  udisks2-bcache   
pn  udisks2-btrfs
pn  udisks2-lvm2 
pn  udisks2-zram 
pn  xfsprogs 

Bug#994529: exfatprogs: Missing symlink from mkexfatfs -> mkfs.exfat

[Sven Hoexter]

Hi,
since the parameters are not compatible, changes in the disk utility are 
unavoidable. The -n you mentioned for setting the label is -L in the exfatprogs 
implementation.

Regards,
Sven

Bug#992338: O: tclcurl -- Tcl bindings to libcurl

[Sven Hoexter]

Package: wnpp
Severity: normal
Control: affects -1 src:tclcurl

I intend to orphan the tclcurl package.

The package description is:
 This module enables the use of libcurl in Tcl scripts. Please refer to
 the libcurl documentation available in the libcurl4-gnutls-dev package.
 .
 NOTE: the SSL support is provided by GnuTLS.

This package is without an active upstream. Lately there has been some
activity by flightware guys in https://github.com/flightaware/tclcurl-fa/
but the current package is _not_ based on this one. There is also
additional activity in 
https://www.androwish.org/index.html/timeline?chng=jni/TclCurl/*
with occasional fixes.

The git repo I used to maintain this package with gbp is still referenced and 
available.
If a new maintainer would like to continue on this code base it's possible to 
clone it
to host it on salsa or somewhere else.

Regards,
Sven

Bug#992337: O: mysqltcl -- interface to the MySQL database for the Tcl language

[Sven Hoexter]

Package: wnpp
Severity: normal
Control: affects -1 src:mysqltcl

I intend to orphan the mysqltcl package.

The package description is:
 The mysqltcl package provides a Tcl interface to the MySQL database system.
 Within Tcl you've a range of Tcl commands and a global Tcl array available
 to access the database server.
 Written in C mysqltcl uses the official MySQL C-API so that almost all
 Tcl commands correspond to MySQL C-API functions.

I tried to give the package a little bit of love but do not use it anymore.
The git repo I used to maintain it in with gbp is still available for a
potential adopter to clone from if he likes to.
The last upstream release happened in 2012, so it's been a while. In general
the upstream author replied to mails and applied patches in the past.

Regards,
Sven

Bug#992287: progess-linux-desktop: Please remove dependency alternative exfat-fuse and exfat-utils

[Sven Hoexter]

Package: progess-linux-desktop
Version: 20210101-2
Severity: normal

Hi Daniel,
I would like to drop exfat-fuse and exfat-utils within the next release cycle.
Would be nice if you could drop them completely from this meta package.
I do not consider this one a blocker for myself due to the fact that you
already list exfatprogs as the first choice.

Cheers,
Sven

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

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

Bug#992286: libguestfs0: Please move from exfat-fuse and exfat-utils to exfatprogs

[Sven Hoexter]

Package: libguestfs0
Version: 1:1.44.1-1
Severity: normal

Hi,
with the release of bullseye we've the in kernel exFAT driver available.
If possible please remove the dependency on exfat-fuse and change from
exfat-utils to exfatprogs for the filesystem utilities. That would enable
us to drop the fuse driver soon.

If you make extensive use of special parameters of the filesystem utilities
there might be changes required. exfatprogs is a codebase created by Samsung 
while
exfat-utils was a completely independend implementation by another developer.

Regards,
Sven

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

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

Versions of packages libguestfs0 depends on:
ii  acl  2.2.53-10
ii  attr 1:2.4.48-6
ii  binutils 2.37-4
ii  bsdextrautils2.36.1-8
pn  btrfs-progs  
ii  bzip21.0.8-4
ii  cpio 2.13+dfsg-6
ii  cryptsetup-bin   2:2.3.5-1
ii  curl 7.74.0-1.3+b1
ii  dash 0.5.11+git20210120+802ebd4-1
pn  db-util  
ii  debootstrap  1.0.123
ii  diffutils1:3.7-5
ii  dosfstools   4.2-1
ii  e2fsprogs1.46.2-2
ii  exfat-fuse   1.3.0-2
pn  exfat-utils  
pn  extlinux 
pn  f2fs-tools   
ii  fdisk2.36.1-8
ii  file 1:5.39-3
ii  gawk 1:5.1.0-1
pn  gdisk
ii  genisoimage  9:1.1.11-3.2
ii  grub2-common 2.04-20
pn  icoutils 
ii  iproute2 5.13.0-2
ii  isc-dhcp-client  4.4.1-2.3
ii  kmod 28-1
pn  kpartx   
pn  ldmtool  
ii  less 551-2
ii  libacl1  2.2.53-10
pn  libaugeas0   
ii  libc62.31-13
ii  libcap2  1:2.44-1
ii  libfuse2 2.9.9-5
pn  libhivex0
ii  libjansson4  2.13.1-1.1
ii  libpcre3 2:8.39-13
ii  libselinux1  3.1-3
ii  libsystemd0  247.9-1
ii  libtirpc31.3.1-1
ii  libtsk19 4.10.1+dfsg-1
pn  libvirt0 
ii  libxml2  2.9.10+dfsg-6.7
pn  libyara4 
pn  lsscsi   
ii  lvm2 2.03.11-2.1
ii  lzop 1.04-2
pn  mdadm
pn  mtools   
ii  netpbm   2:10.0-15.4
pn  ntfs-3g  
ii  openssh-client   1:8.4p1-5
pn  osinfo-db
pn  parted   
ii  pciutils 1:3.7.0-5
ii  procps   2:3.3.17-5
ii  psmisc   23.4-2
pn  qemu-system-x86  
ii  qemu-utils   1:5.2+dfsg-11
pn  scrub
ii  sleuthkit4.10.1+dfsg-1
ii  squashfs-tools   1:4.4-2
pn  supermin 
pn  syslinux 
ii  systemd-sysv 247.9-1
ii  udev 247.9-1
ii  util-linux   2.36.1-8
ii  uuid-runtime 2.36.1-8
ii  xz-utils 5.2.5-2
pn  zerofree 

Versions of packages libguestfs0 recommends:
pn  libguestfs-hfsplus   
pn  libguestfs-reiserfs  
pn  libguestfs-xfs   

Versions of packages libguestfs0 suggests:
pn  libguestfs-gfs2
pn  libguestfs-jfs 
pn  libguestfs-nilfs   
pn  libguestfs-rescue  
pn  libguestfs-rsync   
pn  libguestfs-zfs 

Bug#992285: bfh-desktop: Please remove dependency alternative exfat-fuse and exfat-utils

[Sven Hoexter]

Package: bfh-desktop
Version: 20210101-2
Severity: normal

Hi Daniel,
I would like to drop exfat-fuse and exfat-utils within the next release cycle.
Would be nice if you could drop them completely from this meta package.
I do not consider this one a blocker for myself due to the fact that you
already list exfatprogs as the first choice.

Cheers,
Sven

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

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

Versions of packages bfh-desktop depends on:
pn  apg 
pn  bfh-base-system 
ii  cups2.3.3op2-3+deb11u1
ii  dosfstools  4.2-1
ii  elinks [www-browser]0.13.2-1+b1
ii  exfat-fuse  1.3.0-2
ii  exfatprogs  1.1.2-1
ii  firefox [www-browser]   90.0-2
pn  fonts-powerline 
ii  gimp2.10.24-2
pn  gimp-plugin-registry
pn  gir1.2-gstreamer-1.0
ii  gir1.2-notify-0.7   0.7.9-3
pn  hardlink
pn  inkscape
pn  inkscape-open-symbols   
ii  liferea 1.13.5-3
pn  network-manager-config-connectivity-debian  
pn  network-manager-ssh 
pn  nfs-common  
pn  ntfs-3g 
pn  nwipe   
ii  pass1.7.4-1
pn  pass-extension-tail 
pn  samba-common
pn  sshfs   
pn  symlinks
pn  task-desktop
ii  task-laptop 3.68
pn  thunderbird | enigmail  
ii  tree1.8.0-1+b1
ii  unzip   6.0-26
pn  webext-browserpass  
pn  webext-foxyproxy
pn  webext-https-everywhere 
pn  webext-privacy-badger   
pn  webext-ublock-origin
ii  whois   5.5.10
ii  zip 3.0-12

bfh-desktop recommends no packages.

Versions of packages bfh-desktop suggests:
pn  deluge-gtk   
pn  deluged  
pn  virtualbox   
pn  virtualbox-dkms  
pn  virtualbox-ext-pack  
pn  virtualbox-qt
pn  webext-umatrix   

Bug#975957: pflogsumm: please backport newer version to buster

[Sven Hoexter]

On Fri, Nov 27, 2020 at 02:24:42PM +0200, Dimitris T. wrote:

Hello Dimitris,

> yes, that works as well..  just thought most sysadms wouldn't want to mix
> testing with stable/production. even without dependencies of any sort :)

Yeah I understand that is a bit of a hassle for some. But we also try
to keep backports slim to some extend. The FAQ still asks you to check for
a notable user base before uploading.

My personal point on this is that in corporate setups you always have
internal repos. pflogsumm is so slow moving that I would just add it to my
internal repo if required. For smaller setups, like my private mailserver,
I'm fine with either just hand downloading the .deb once, or adding testing
and proper apt pining.


> please feel free to close.

Let's keep it open till bullseye, maybe more people jump in and see a
benefit of heaving a backport available.

Sven

Bug#975957: pflogsumm: please backport newer version to buster

[Sven Hoexter]

On Fri, Nov 27, 2020 at 12:33:03PM +0200, Dimitris T. wrote:

Hi,

> please consider backporting(?) newer version from testing to buster.

just install the package from testing/unstable, it has no
versioned depdencies that should prevent you from doing that. No need
to have it in backports.

Sven

Bug#975335: systemd: Drop none functional DefaultTasksMax documentation patch

[Sven Hoexter]

Package: systemd
Version: 246.6-4
Severity: normal

Hi,
it seems when systemd introduced a DefaultTasksMax=512 limit it was patched
out in Debian in 
debian/Revert-core-enable-TasksMax-for-all-services-by-default-a.patch.
Later on this patch lost his complete logic and is already in Debian
stretch and buster a pure documentation patch, and the upstream 15% default
seem to kick in.

Since nobody complained so far, I'd say Debian is fine with the default and
we should just drop the misleading documentation patch.

Regards,
Sven

-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-8
ii  libapparmor1 2.13.5-1+b1
ii  libaudit11:2.8.5-3.1
ii  libblkid12.36.1-1
ii  libc62.31-4
ii  libcap2  1:2.44-1
ii  libcrypt11:4.4.17-1
ii  libcryptsetup12  2:2.3.4-1
ii  libgcrypt20  1.8.7-2
ii  libgnutls30  3.6.15-4
ii  libgpg-error01.38-2
ii  libidn2-02.3.0-4
ii  libip4tc21.8.6-1
ii  libkmod2 27+20200310-2
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.36.1-1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.5.0-3
ii  libselinux1  3.1-2+b1
ii  libsystemd0  246.6-4
ii  libzstd1 1.4.5+dfsg-4
ii  mount2.36.1-1
ii  systemd-timesyncd [time-daemon]  246.6-4
ii  util-linux   2.36.1-1

Versions of packages systemd recommends:
it  dbus  1.12.20-1

Versions of packages systemd suggests:
ii  policykit-10.105-29
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
it  initramfs-tools  0.139
iu  libnss-systemd   246.6-4
iu  libpam-systemd   246.6-4
iu  udev 246.6-4

-- no debconf information

Bug#971634: RFS: btrfsmaintenance/0.5-1 -- automate btrfs maintenance tasks on mountpoints or directories

[Sven Hoexter]

Hi Nicholas,
I will take a look at the package.

Sven

Bug#968037: buster-pu: package facter/3.11.0-2+deb10u1

[Sven Hoexter]

On Sat, Aug 15, 2020 at 05:45:51PM +0100, Adam D. Barratt wrote:
> On Fri, 2020-08-07 at 10:46 +0200, Sven Hoexter wrote:
> > if you run facter in the context of Googles GCE it will fetch
> > information from Googles metadata service, but form an old
> > beta API endpoint. This one is due to get shutdown by the
> > end of September 2020.
> > https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server
> 
> Do we have an idea of how widely used this particular combination is?

TBH no idea. We use it in combination with ansible on GCE VMs. Looking
through the facter_* facts we still use, they could by now probably
be replaced with some ansible build in facts. That would mean this combination
is mostly used in setups with some technical debt.
That said there might be people running puppet with the puppet packages
from Debian/main on GCE VMs which could be also impacted.


> The reason I ask is that, even if we pull the 10.6 point release back
> in line with where it would have been if 10.5 hadn't been delayed for
> the Grub issues, that would still be during the second half of
> September and quite close to the shutdown date.

Well our internal ticket about Google urging us to move away from the
old API endpoint was lingering for several weeks. I guess they also
pinged other customers and nobody cared enough to investigate it or
at least report a bug in the bts. So probably that issue is less
important/urgen than I initially thought. None the less I still
believe it's sensible to fix it in a forthcoming point release,
whenever that will be.

Cheers,
Sven

Bug#968037: buster-pu: package facter/3.11.0-2+deb10u1

[Sven Hoexter]

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

Hi,
if you run facter in the context of Googles GCE it will fetch
information from Googles metadata service, but form an old
beta API endpoint. This one is due to get shutdown by the
end of September 2020.
https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server

This was fixed upstream already some time ago for the 3.11.x branch in
https://github.com/puppetlabs/facter/commit/1a0bc4e984716dc5145e5bb8fbf14b1ac0fd8c04

For unstable I've uploaded a NMU to delayed-10 which got processed
a few minutes ago. That is https://bugs.debian.org/966374
I also tested a private build of the package inside the infrastructure at work
for the past ten days without issues.

Here is a proposed upload targeting buster to get this one also fixed
for our current stable release. Additionally I made that available to
the maintainer group at salsa at
https://salsa.debian.org/puppet-team/facter/-/merge_requests/1

Cheers,
Sven

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog	2019-07-17 22:04:05.0 +0200
+++ facter-3.11.0/debian/changelog	2020-07-27 17:27:11.0 +0200
@@ -1,3 +1,11 @@
+facter (3.11.0-2+deb10u2) buster; urgency=medium
+
+  * Change Google GCE Metadata endpoint from "v1beta1" to "v1".
+Adds patch debian/patches/FACT-2018-update-gce-metadata-endpoint.patch
+(Closes: #966374)
+
+ -- Sven Hoexter   Mon, 27 Jul 2020 17:27:11 +0200
+
 facter (3.11.0-2+deb10u1) buster; urgency=medium
 
   * Fix parsing of Linux route non-kv flags (e.g. onlink) (Closes: #918250)
diff -Nru facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch
--- facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch	1970-01-01 01:00:00.0 +0100
+++ facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch	2020-07-27 17:27:11.0 +0200
@@ -0,0 +1,30 @@
+From: Gabriel Nagy 
+Subject: (FACT-2018) Update GCE metadata endpoint
+
+Google Compute Engine's internal metadata service will be deprecating
+the 'v1beta1' endpoint sometime before end of calendar year 2019. This
+commit updates the GCE resolver to use the 'v1' endpoint instead.
+
+Using the 'v1' endpoint also requires setting a custom User-Agent
+header that was not necessary in the old 'v1beta1' endpoint.
+
+For more details about GCE metadata, please see
+https://cloud.google.com/compute/docs/storing-retrieving-metadata
+
+
+Origin: upstream, https://github.com/puppetlabs/facter/commit/1a0bc4e984716dc5145e5bb8fbf14b1ac0fd8c04
+Bug-Debian: http://bugs.debian.org/966374
+Index: facter/lib/src/facts/resolvers/gce_resolver.cc
+===
+--- facter.orig/lib/src/facts/resolvers/gce_resolver.cc
 facter/lib/src/facts/resolvers/gce_resolver.cc
+@@ -240,7 +240,8 @@ namespace facter { namespace facts { nam
+ 
+ try
+ {
+-lth_curl::request req("http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true=json;);
++lth_curl::request req("http://metadata.google.internal/computeMetadata/v1/?recursive=true=json;);
++req.add_header("Metadata-Flavor", "Google");
+ req.connection_timeout(GCE_CONNECTION_TIMEOUT);
+ req.timeout(GCE_SESSION_TIMEOUT);
+ if (!http_langs().empty())
diff -Nru facter-3.11.0/debian/patches/series facter-3.11.0/debian/patches/series
--- facter-3.11.0/debian/patches/series	2019-07-17 22:03:31.0 +0200
+++ facter-3.11.0/debian/patches/series	2020-07-27 17:27:11.0 +0200
@@ -1,3 +1,4 @@
+FACT-2018-update-gce-metadata-endpoint.patch
 use-shared-cpp-hocon.patch
 ruby-fix-library-name.patch
 disable-facter-smoke.patch

Bug#966374: facter: diff for NMU version 3.11.0-4.3

[Sven Hoexter]

Control: tags 966374 + patch
Control: tags 966374 + pending


Hi,

I've prepared an NMU for facter (versioned as 3.11.0-4.3) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it further.

Cheers,
Sven

diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog	2020-06-17 23:21:32.0 +0200
+++ facter-3.11.0/debian/changelog	2020-07-28 09:17:17.0 +0200
@@ -1,3 +1,12 @@
+facter (3.11.0-4.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: add 0008-FACT-2018-update-gce-metadata-endpoint.patch
+Switch Google GCE metadata endpoint from v1beta1 to final v1, the beta
+endpoint will be shutdown end of September 2020. (Closes: #966374)
+
+ -- Sven Hoexter   Tue, 28 Jul 2020 09:17:17 +0200
+
 facter (3.11.0-4.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru facter-3.11.0/debian/patches/0008-FACT-2018-update-gce-metadata-endpoint.patch facter-3.11.0/debian/patches/0008-FACT-2018-update-gce-metadata-endpoint.patch
--- facter-3.11.0/debian/patches/0008-FACT-2018-update-gce-metadata-endpoint.patch	1970-01-01 01:00:00.0 +0100
+++ facter-3.11.0/debian/patches/0008-FACT-2018-update-gce-metadata-endpoint.patch	2020-07-28 09:15:21.0 +0200
@@ -0,0 +1,30 @@
+From: Gabriel Nagy 
+Subject: (FACT-2018) Update GCE metadata endpoint
+
+Google Compute Engine's internal metadata service will be deprecating
+the 'v1beta1' endpoint sometime before end of calendar year 2019. This
+commit updates the GCE resolver to use the 'v1' endpoint instead.
+
+Using the 'v1' endpoint also requires setting a custom User-Agent
+header that was not necessary in the old 'v1beta1' endpoint.
+
+For more details about GCE metadata, please see
+https://cloud.google.com/compute/docs/storing-retrieving-metadata
+
+
+Origin: upstream, https://github.com/puppetlabs/facter/commit/1a0bc4e984716dc5145e5bb8fbf14b1ac0fd8c04
+Bug-Debian: http://bugs.debian.org/966374
+Index: facter/lib/src/facts/resolvers/gce_resolver.cc
+===
+--- facter.orig/lib/src/facts/resolvers/gce_resolver.cc
 facter/lib/src/facts/resolvers/gce_resolver.cc
+@@ -240,7 +240,8 @@ namespace facter { namespace facts { nam
+ 
+ try
+ {
+-lth_curl::request req("http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true=json;);
++lth_curl::request req("http://metadata.google.internal/computeMetadata/v1/?recursive=true=json;);
++	req.add_header("Metadata-Flavor", "Google");
+ req.connection_timeout(GCE_CONNECTION_TIMEOUT);
+ req.timeout(GCE_SESSION_TIMEOUT);
+ if (!http_langs().empty())
diff -Nru facter-3.11.0/debian/patches/series facter-3.11.0/debian/patches/series
--- facter-3.11.0/debian/patches/series	2020-06-17 22:44:37.0 +0200
+++ facter-3.11.0/debian/patches/series	2020-07-28 09:15:35.0 +0200
@@ -6,3 +6,4 @@
 0006-FACT-1916-fix-route-parsing-on-Linux.patch
 0007-Don-t-run-rspec-via-bundler.patch
 fix-double-tests.patch
+0008-FACT-2018-update-gce-metadata-endpoint.patch

Bug#966374: facter: diff for stable update version 3.11.0-2+deb10u2

[Sven Hoexter]

Hi,

attached is debdiff for a potential stable upload.
Also available at salsa as a MR for the stable branch
https://salsa.debian.org/puppet-team/facter/-/merge_requests/1?commit_id=98e5f769a84d029a6ac39aac27a05c0506547f36

Cheers,
Sven
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog	2019-07-17 22:04:05.0 +0200
+++ facter-3.11.0/debian/changelog	2020-07-27 17:27:11.0 +0200
@@ -1,3 +1,11 @@
+facter (3.11.0-2+deb10u2) buster; urgency=medium
+
+  * Change Google GCE Metadata endpoint from "v1beta1" to "v1".
+Adds patch debian/patches/FACT-2018-update-gce-metadata-endpoint.patch
+(Closes: #966374)
+
+ -- Sven Hoexter   Mon, 27 Jul 2020 17:27:11 +0200
+
 facter (3.11.0-2+deb10u1) buster; urgency=medium
 
   * Fix parsing of Linux route non-kv flags (e.g. onlink) (Closes: #918250)
diff -Nru facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch
--- facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch	1970-01-01 01:00:00.0 +0100
+++ facter-3.11.0/debian/patches/FACT-2018-update-gce-metadata-endpoint.patch	2020-07-27 17:27:11.0 +0200
@@ -0,0 +1,30 @@
+From: Gabriel Nagy 
+Subject: (FACT-2018) Update GCE metadata endpoint
+
+Google Compute Engine's internal metadata service will be deprecating
+the 'v1beta1' endpoint sometime before end of calendar year 2019. This
+commit updates the GCE resolver to use the 'v1' endpoint instead.
+
+Using the 'v1' endpoint also requires setting a custom User-Agent
+header that was not necessary in the old 'v1beta1' endpoint.
+
+For more details about GCE metadata, please see
+https://cloud.google.com/compute/docs/storing-retrieving-metadata
+
+
+Origin: upstream, https://github.com/puppetlabs/facter/commit/1a0bc4e984716dc5145e5bb8fbf14b1ac0fd8c04
+Bug-Debian: http://bugs.debian.org/966374
+Index: facter/lib/src/facts/resolvers/gce_resolver.cc
+===
+--- facter.orig/lib/src/facts/resolvers/gce_resolver.cc
 facter/lib/src/facts/resolvers/gce_resolver.cc
+@@ -240,7 +240,8 @@ namespace facter { namespace facts { nam
+ 
+ try
+ {
+-lth_curl::request req("http://metadata.google.internal/computeMetadata/v1beta1/?recursive=true=json;);
++lth_curl::request req("http://metadata.google.internal/computeMetadata/v1/?recursive=true=json;);
++req.add_header("Metadata-Flavor", "Google");
+ req.connection_timeout(GCE_CONNECTION_TIMEOUT);
+ req.timeout(GCE_SESSION_TIMEOUT);
+ if (!http_langs().empty())
diff -Nru facter-3.11.0/debian/patches/series facter-3.11.0/debian/patches/series
--- facter-3.11.0/debian/patches/series	2019-07-17 22:03:31.0 +0200
+++ facter-3.11.0/debian/patches/series	2020-07-27 17:27:11.0 +0200
@@ -1,3 +1,4 @@
+FACT-2018-update-gce-metadata-endpoint.patch
 use-shared-cpp-hocon.patch
 ruby-fix-library-name.patch
 disable-facter-smoke.patch

Bug#966374: facter: Google GCE metadata endpoint v1beta1 will shutdown on September 30 2020

[Sven Hoexter]

Source: facter
Version: 3.11.0-4.2
Severity: important

Hi,
as per https://cloud.google.com/compute/docs/migrating-to-v1-metadata-server
Google is going to shutdown the beta metadata endpoint end of September 2020.
Upstream this was accounted for in the 3.11.x branch some time ago with
https://github.com/puppetlabs/facter/commit/1a0bc4e984716dc5145e5bb8fbf14b1ac0fd8c04

I believe we should ship a fix via proposed-updates to a forthcoming Debian 
buster
point release. Will take a look at getting a NMU ready and test drive the 
patch, though
it's more or less a no brainer two line change.

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

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

Bug#847236: exfat-utils: Crashes with message "BUG: failed to convert name to UTF-8."

[Sven Hoexter]

On Fri, Jul 17, 2020 at 06:21:53PM -0700, Colin Williams wrote:

Hi,
just in case that is not crystal clear:  I can not give you competent
support, so _always_ have a backup before you try anything new.

> I received a new external drive and unsure what filesystem to place on
> it so I used the factory formatted exfat. After copying maybe some
> rather old files around across disks my filesystem was unmounted. I
> tried to remount:
> 
> /mnt/sdb5/home/discord/nt.exfat-fuse /dev/sdc1 /mnt/sdc1
> FUSE exfat 1.3.0
> WARN: volume was not unmounted cleanly.
> fuse: bad mount point `/mnt/sdc1': Transponot connected

I can not really find the source of the "Transponot connected"
message. In my experience the fuse driver was rather tolerant
with unclean volumes. Maybe it was a "Transport not connected"
which looks like a crash of fuse or the exfat fuse driver.
That could be visible maybe in /var/log/syslog or via journalctl.


> Then fsck:
> 
> sudo fsck.exfat /dev/sdc1
> exfatfsck 1.3.0
> Checking file system on /dev/sdc1.
> File system version   1.0
> Sector size 512 bytes
> Cluster size  1 MB
> Volume size4657 GB
> Used space 1273 GB
> Available space3385 GB
> ERROR: illegal UTF-16 sequence.
> BUG: failed to convert name to UTF-8.
> Aborted
> 
> If I now cannot fsck, am I safe to use this filesystem anymore or do I
> need to remove my data and use another filesystem?

If you can preserve a dump of the filesystem and have some time at hand
you might want to consider creating a bugreport upstream at github.
https://github.com/relan/exfat/issues
There are also a few UTF related commits between 1.3.0 and the git master
branch. So you could also compile the latest version and try that. I'm waiting
for a new release to get those updates into Debian.

Nobody honestly can tell you how safe the usage of the filesystem is.
I guess most people do not use it for any kind of data preservation/archiving, 
but
just as an compatibility filesystems for swapable media like USB mass storage
and SD cards.

Another possible option right now is to try the Linux 5.7 nativ exFAT 
implementation
or the fsck tool from exfatprogs. Both are right now available in 
Debian/unstable.

Hope that helps a bit deciding on a way forward.

Sven

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Sven Hoexter]

On Sun, Jul 05, 2020 at 09:35:14AM +0300, Andrei POPESCU wrote:
> On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote:
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> 
> Isn't this the typical use-case for alternatives?

IMO sensible if you have two packages which are likely to be coinstalled
often. For those kind of niche tools I've here I do not want user to be
bothered to figure out which alternative is selected and which he would
actually like to use. Additionally the native names of the tools shipped
in exfat-utils are
/sbin/dumpexfat
/sbin/exfatfsck
/sbin/exfatlabel
/sbin/mkexfatfs
So probably the midterm will be that the exfatprogs provide
the kind of "official" mkfs.exfat and fsck.exfat tools. But for now
I prefer to keep the already tested exfat-utils in place. If you want
to rely on the exfatprogs tools I assume that is a conscious decision
and you're ok with letting go of the exfat-utils implementation.

In case there is some overboarding interest in always having both installed,
and bothering user with managing alternatives in case he'd like to switch
between implementations, I might change that. But for now I do not believe
it would offer value for the average user.

The only case I can imagine right now that would break is desktop
environment 1 depends on exfatprogs and desktop environment 2 depends on
exfat-utils and a user has both DEs installed. But even here using alternatives
might call for bad surprises when parameter differ. So I believe even in
this case we are all better off for now if the packages conflict and thus
make clear that they are different tools, and should not be installed in
parallel, at least not with the same binary names. (I did not yet check
if they are flag by flag compatible or not)


Cheers,
Sven

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Sven Hoexter]

On Sat, Jul 04, 2020 at 02:49:15PM -0400, Nicholas D Steeves wrote:

Hi Nicholas,

> > Since people started to ping me about getting this one introduced
> > I now give in and pick it up. I plan to continue for now the
> > maintenance of the fuse-exfat and exfat-utils packages.
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> > Maybe I later on drop the mkfs.exfat and fsck.exfat links from
> > the exfat-utils package.
> 
> Might /etc/alternatives also be considered for mkfs.exfat and
> fsck.exfat?
> Also, what about /sbin/mount.exfat?  That one also seems
> like a candicate for /etc/alternatives.

Yes I thought about it, I also thought about dropping the symlinks
similar to the mount.exfat helper issue with fuse-exfat.

Right now I believe we should cater for the general use cases which
probably is someone wanting to mount an exfat filesystem with the
most convenient and fast driver, which is the kernel based one.
So if you have a reason to still want to use the fuse driver you
make an explicit choice. That's when I expect you to be able to
invoke the mount.exfat-fuse helper.

One thing to note is that there is no alternative for the mount.exfat
helper, either it's there or it's not. Michael proposed a thin
wrapper in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963752
but I do not believe that helps the average user. That's why I droped
the symlink from the package.

Now back to the utils situation:
Here we could use alternatives, but I believe for the average user that
will be even more confusing. Luckily upstream of the exfatprogs
made the concious decision to not create a naming colision with the
existing exfat-utils package, so user have a chance to recognise
the different upstream sources. I believe it's more straight forward
to let the user select the implementation he prefers and just make
sure we do not have the naming conflict of the binaries.
The other, longterm more likely option from my point of
view, is to drop the mkfs.exfat and fsck.exfat links, and let the user
invoke exfatfsck and mkexfatfs binary provided by the package.

I do not want to make that change right now, and would prefer to
wait a bit if we see some bugs with the exfatprogs implementation,


> Probably tangential: I wonder if this is a case where a virtual package
> (where both the Samsung and the exfat-utils Provide exfat-tools or
> similar) could be considered?  As you know, I'm primarily interested in
> backports, and I wonder if whatever the kernel team does with Wireguard
> would be a useful precedent to follow.  eg: if newer kernels Provide:
> feature that that was previously wireguard-dkms.  'not sure if that's
> over-engineering dependency and feature resolution though ;-)

I believe the use case here is so narrow that we should keep it as simple
as possible.

Cheers,
Sven

Bug#963752: exfat-fuse should not provide /sbin/mount.exfat

[Sven Hoexter]

On Fri, Jun 26, 2020 at 09:22:18AM -0400, Michael Stone wrote:

Hi,

> Alternatively, perhaps replacing the mount.exfat link with something like
> the following would be a better option, to transparently support kernels
> with and without the native module:
> 
> #!/bin/sh
> 
> if grep -qF exfat /proc/filesystems || modinfo exfat > /dev/null 2>&1 ; then
>   mount -i $*
> else
>   mount.exfat-fuse $*
> fi

Well as soon as a recent kernel enters testing I believe it
would just cause confusion. Main audience to profit would be
people using testing/unstable with an old or custom kernel
and none Linux ports from my point of view.
Would that help someone in the end?

Cheers,
Sven

Bug#963752: exfat-fuse should not provide /sbin/mount.exfat

[Sven Hoexter]

severity 963752 normal
thanks

On Fri, Jun 26, 2020 at 09:08:27AM -0400, Michael Stone wrote:

> Now that exfat is available as a kernel module, it would be nice if the
> /sbin/mount.exfat link were removed to make it easier for a user to choose
> either the exfat kernel module or the fuse module at runtime. Currently the
> link masks the kernel module so that exfat-fuse is always used, without the
> link the kernel module would be used by default but mounting with -t 
> exfat-fuse
> would use the fuse implementation.

Yes, I already started to think about what the future of the fuse exfat stack
could look like. From my personal point of view we could drop it.
OTOH for some people an independent implementation might still provide some
value. So maybe your proposal to just move it a bit out of the way is a good
first step.

I never tried it on our none Linux ports, it at least builds on kfreebsd but
not on hurd. I believe I just made sure at some point the utils package builds
on hurd as well.

Cheers,
Sven

Bug#955627: pflogsumm produces errors on postscreen lines with IPv6 address

[Sven Hoexter]

On Fri, Apr 03, 2020 at 05:47:31PM +0200, Juri Haberland wrote:

Hi,

> If pflogsumm encounters a postscreen reject line with an IPv6 address,
> it produces the following errors:
> 
> The attached patch fixes these errors.

Thanks a lot, I've updated the postscreen patch in the git repo already. Before
uploading it I've to give some more love to the Debian part of the package.

Sven

Bug#948088: buster-pu: reject package from NEW queue libsoldout/1.4-3

[Sven Hoexter]

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

Hi,
I made a mistake and uploaded libsoldout/1.4-3 to stable instead of
unstable. Please reject the package from the pu NEW queue.

I'm sorry. :(

Sven

Bug#945524: RFP: container-diff -- Diff Docker containers

[Sven Hoexter]

On Fri, Dec 27, 2019 at 03:58:38PM -0500, James Montgomery wrote:

Hi,

> I know that Sven has done some initial manual work to get bytefmt started,
> but he noted it may be a bit outdated. If you like, we can get
> dh-make-golang fixed and attempt to bring in bytfmt using dh-make-golang.

I believe I must have figured out some way to auto generate that package
with dh-make-go. Looking at the files in debian/ I don't think I copy
that manually. But really, feel free to start from scratch with current 
standards
et al.

All I remember is that I stopped at some point because a module was hosted in
a mercurial repo and that was somewhat painful to deal with.

Sven

Bug#945524: RFP: container-diff -- Diff Docker containers

[Sven Hoexter]

On Sat, Dec 28, 2019 at 01:46:27AM +0530, Utkarsh Gupta wrote:
Hi,

> Many, many thanks for this!

I also updated it by now to a new snapshot, so the repo now has
the latest code.

> I'll polish this further and upload it at the earliest!
> 
> D'you intend to maintain it, as well? :D
> Or shall I take it from here?

Feel free to take it, the git log is horrible, even without
a proper name and mail set. So I don't even mind if you just
copy the debian subdir or something like that. I usually license
my contributions under the license used by the upstream project.

That beeing said, I would really like to contribute more to
Debian again, but I failed to do so for the past two years. So
don't count on me. If you form a team or add container-diff to
an existing team I would join (hoexter@d.o) and try to free some
hours at work to help a bit. If required I can also help to
sponsor uploads, though my go packaging experience is very small.

I really appreciate you put some time into packaging container-diff. :)

Sven

Bug#945524: RFP: container-diff -- Diff Docker containers

[Sven Hoexter]

On Fri, Dec 27, 2019 at 11:19:32PM +0530, Utkarsh Gupta wrote:

> Well, I am having a bit of a difficulty to package bytefmt.
> I reported this issue with dh-make-golang here[1].
> 
> It'd be really helpful if you can help me get that packaged somehow?
> I'd be interested in maintaining bytefmt further for container-diff
> though :)

Apparently I started to look into containerdiff and bytefmt some longer
time ago. I have some old packaging based on an older snapshot around.
I just pushed it, but this is very very basic, but this snapshot still
builds here
git clone https://git.sven.stormbind.net/bytefmt.git

Not sure if that helps, will try to bring it up to a new snapshot.

Sven

Bug#942537: Please package newer version

[Sven Hoexter]

On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote:

Hi,

> > 2) You can also update it to fio 3.16 and upload that. I would be okay
> > with an NMU.
> 
> I currently look into this option. Since we set it up on Salsa in the
> Debian group, I can update the package. But let me see if it builds here.

I just uploaded 3.16 and pushed everything to salsa. Had to add a small
oneline fix from upstream to get the gfio stuff to build. The patch can
be removed with 3.17+.

Hope that helps for now, didn't do any polishing of typos.

Cheers,
Sven

Bug#942537: Please package newer version

[Sven Hoexter]

On Sun, Oct 20, 2019 at 02:38:28PM +0200, Sven Hoexter wrote:

Hi,

> I currently look into this option. Since we set it up on Salsa in the
> Debian group, I can update the package. But let me see if it builds here.

Could not get 3.16 to build right away. So I've uploaded 3.15 for now with
the changes proposed by Helmut. Hope that helps at least a bit until we
can take a look at 3.16 or later.

I intentionally did not close this bug, because we're not yet at the
latest greatest.

Sven

Bug#942537: Please package newer version

[Sven Hoexter]

On Fri, Oct 18, 2019 at 08:00:28AM +, Martin Steigerwald wrote:
> Am Donnerstag, den 17.10.2019, 21:14 +0200 schrieb Iustin Pop:

> > I reported earlier this year a bug against fio
> > (https://github.com/axboe/fio/issues/738) only to find that it was
> > long
> > fixed upstream, actually. Sid has 3.12, upstream is at 3.16. Could you
> > please package a newer version?
> 
> However… I upgraded the packaging repo for 3.15 quite some time ago
> already¹. I did not ask Sven Hoexter, my sponsor, to upload it
> immediately cause I was waiting for a merge request regarding:
> 
> fio FTCBFS: builds for the build architecture
> 
> https://bugs.debian.org/929579

Ok as I understand it the upstream part of that one was applied
upstream in May, right?
What is missing is the changes to debian/rules to export the
cross compile variable thingy, correct?

> 2) You can also update it to fio 3.16 and upload that. I would be okay
> with an NMU.

I currently look into this option. Since we set it up on Salsa in the
Debian group, I can update the package. But let me see if it builds here.

Sven

Bug#939577: ITP: jattach -- JVM Dynamic Attach utility all in one jmap jstack jcmd jinfo

[Sven Hoexter]

Package: wnpp
Severity: wishlist
Owner: Sven Hoexter 

* Package name: jattach
  Version : 1.5
  Upstream Author : Andrei Pangin
* URL : https://github.com/apangin/jattach/releases
* License : Apache 2.0
  Programming Lang: C
  Description : JVM Dynamic Attach utility all in one jmap jstack jcmd jinfo
 jattach is a utility implementing commands for the JVM Dynamic Attach
 mechanism. Instead of installing a complete JDK you can use this small
 utility to query information from your running JVM.

Bug#939328: linux-image-4.19.0-5-amd64: buster and stretch-backports kernel causes interfaces rename back to ethX on HPe DL360g10

[Sven Hoexter]

Package: src:linux
Version: 4.19.37-5+deb10u2
Severity: normal

Hi,
installing the latest update caused our NICs to be renamed from "enoX" back to 
"ethX". We first experienced
this issue on Debian/buster on HPe DL360g10 and now found the same issue with 
the latest upload of the same
kernel to stretch-backports.

We're now working around this issue by using
$ cat /etc/systemd/network/101-onboard-rd.link 
[Link]
NamePolicy=onboard kernel database slot path
MACAddressPolicy=none


That said on a system still running Debian/stretch with the old working kernel, 
without
the systemd workaround applied I've the following:

svenhoexter@docker-018:~$ uname -a
Linux docker-018 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-4~bpo9+1 
(2019-06-19) x86_64 GNU/Linux

svenhoexter@docker-018:~$ udevadm test-builtin net_id /sys/class/net/eno5 
2>/dev/null
ID_NET_NAME_ONBOARD=eno5
ID_NET_NAME_PATH=enp93s0f0

svenhoexter@docker-018:~$ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin 
net_setup_link /sys/class/net/eno5
calling: test-builtin
=== trie on-disk ===
tool version:  232
file size: 8441068 bytes
header size 80 bytes
strings1846908 bytes
nodes  6594080 bytes
Load module index
Found container virtualization none
timestamp of '/etc/systemd/network' changed
Skipping overridden file: /lib/systemd/network/99-default.link.
Parsed configuration file /etc/systemd/network/99-default.link
Created link configuration context.
ID_NET_DRIVER=i40e
No matching link configuration found.
Unload module index
Unloaded link configuration context.


On a system with the new kernel and the applied workaround we've:

svenhoexter@docker-019:~$ uname -a
Linux docker-018 4.19.0-5-amd64 #1 SMP Debian 4.19.37-5+deb10u2 (2019-08-08) 
x86_64 GNU/Linux

svenhoexter@docker-019:~$ udevadm test-builtin net_id /sys/class/net/eno5 
2>/dev/null
ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_ONBOARD=eno5
ID_NET_NAME_PATH=enp93s0f0

svenhoexter@docker-019:~$ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin 
net_setup_link /sys/class/net/eno5
=== trie on-disk ===
tool version:  241
file size: 9492053 bytes
header size 80 bytes
strings2069269 bytes
nodes  7422704 bytes
Load module index
Failed to read $container of PID 1, ignoring: Permission denied
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
Skipping overridden file '/usr/lib/systemd/network/99-default.link'.
Parsed configuration file /etc/systemd/network/99-default.link
Parsed configuration file /etc/systemd/network/101-onboard-rd.link
Created link configuration context.
ID_NET_DRIVER=i40e
Config file /etc/systemd/network/101-onboard-rd.link applies to device eno5
link_config: autonegotiation is unset or enabled, the speed and duplex are not 
writable.
link_config: could not set ethtool features for eno5
Could not set offload features of eno5: Operation not permitted
eno5: Device has name_assign_type=4
Using default interface naming scheme 'v240'.
eno5: Policy *onboard* yields "eno5".
ID_NET_LINK_FILE=/etc/systemd/network/101-onboard-rd.link
ID_NET_NAME=eno5
Unload module index
Unloaded link configuration context.


Any hint on how to provide additional input is appreciated.

Sven

Bug#935390: RFS: vnstat/2.4-1 [NMU] [ITA]

[Sven Hoexter]

On Sun, Sep 01, 2019 at 09:23:06AM -0700, Rob Savoury wrote:
> Package: sponsorship-requests

>   dget -x
> https://mentors.debian.net/debian/pool/main/v/vnstat/vnstat_2.4-0.1.dsc


Hey Rob and Christian,
the package looks good to me. I've uploaded it to delayed-3 in case
Christian objects the upload. From what I understood he's fine with the
NMU, but just in case.

So Christian in case you object to this upload give me a short notice
and I can cancel it within the next three days.

Rob the "ITA" tag in the bug is a bit misleading in the sense that if you
want to adopt someting (ITA - Intent To Adopt), you usually set yourself
as the package maintainer in debian/control.

I'm not sure what Christian is up to, but maybe it makes sense to move the
package to https://salsa.debian.org/debian and have it group maintained.
But that's up to Christian to decide.

Sven

Bug#935390: RFS: vnstat/2.4-1 [NMU] [ITA]

[Sven Hoexter]

On Thu, Aug 22, 2019 at 01:26:35AM -0700, Rob Savoury wrote:

Hey Rob,

> Changes since the last upload:
> 
>* New upstream version 2.4
>  .
>* debian/patches/
>+ drop patch applied upstream (timeout for restart)
>+ modify pidfile and systemd patches for new source files
>* d/control: bump to std version 4.4.0 and add libsqlite3-dev BD (vnstat 
> 2.x)

While I value the work, this is not properly packaged as an NMU.
I uploaded the last NMU by Teemu because it made perfectly sense to upload
those changes which were already implemented by Christian Göttsche. But 
Christian
is still the maintainer of the package as far as I can tell.

So would be nice to have an ACK from him if such kind of informal team uploads
are ok. And beside of that NMUs which implement major version changes are mostly
an exception. I would prefer either some team upload or some notice by Christian
how he intents to handle this package.

Sven

Bug#935167: prometheus-node-exporter: apt.sh text collector fails to deal with spaces in repository label

[Sven Hoexter]

Package: prometheus-node-exporter
Version: 0.17.0+ds-3
Severity: normal

Hi,
the apt.sh script currently shipped with the prometheus-node-exporter package 
is not
able to deal with spaces in the repository label.
Result is output like:

~$ /usr/share/prometheus-node-exporter/apt.sh |grep Postgre
apt_upgrades_pending{origin="PostgreSQLfor",arch="Debian/Ubuntu"} 6
apt_upgrades_pending{origin="PostgreSQLfor",arch="Debian/Ubuntu"} 9

This fails basically because of duplicate label in a prometheus metric.
Beside of that the label values are of course wrong.

Anyway this is fixed upstream in:
https://github.com/prometheus-community/node-exporter-textfile-collector-scripts/commit/505079407a638c6a3cce6a7ce434500463d9cb28

Sadly the scripts were moved to a different repo lately and thus
probably missed by the packaging.
https://github.com/prometheus/node_exporter/tree/master/text_collector_examples

I'm not yet sure how we could handle that in a good way with the current 
packaging.
Either using git submodules or having several upstream branches and merge them 
somehow,
or build from several source packages.

Opened a MR at
https://salsa.debian.org/go-team/packages/prometheus-node-exporter/merge_requests/3
though I'd consider that at most a temporary workaround. The packaging basically
requires some adjustment to handle this unfortunate source split upstream.

Regards,
Sven

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

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

Versions of packages prometheus-node-exporter depends on:
ii  libc6 2.28-10
ii  moreutils 0.62-1
ii  systemd-sysv  241-5

Versions of packages prometheus-node-exporter recommends:
ii  dbus   1.12.16-1
ii  python33.7.3-1
pn  smartmontools  

prometheus-node-exporter suggests no packages.

Bug#932843: RFS: vnstat/1.18-2.1 [NMU]

[Sven Hoexter]

On Wed, Jul 24, 2019 at 06:40:18PM +0300, Teemu Toivola wrote:

Hi,

> See the discussion in bug #907020 [1] for all details. The short version is
> that in August 2018 Christian introduced new autopkgtest tests in 1.18-2
> which didn't work due to lack of root access. #907020 was opened as a
> result and Christian made the fix during the same day in Salsa. However,
> for some reason, that fix was never uploaded. Last week the severity of
> #907020 was changed from normal to serious placing the package to the
> autoremoval queue. As I wasn't able to get in touch with Christian, I
> concluded that doing a NMU for the changes he had already made in Salsa
> would be the right thing to do. That's why the policy bump is to version
> 4.2.1 as I didn't want to mix in any of my own changes.

I see. Ok doesn't make much sense to discuss more about this one-liner or
the policy version. While the later does not make much sense it won't cause
any harm either.

Thanks for pushing that fix forward.

Sven

Bug#932843: RFS: vnstat/1.18-2.1 [NMU]

[Sven Hoexter]

On Tue, Jul 23, 2019 at 10:56:47PM +0300, Teemu Toivola wrote:

Hey guys,

>  vnstat (1.18-2.1) unstable; urgency=medium
> 
>   * Non-maintainer upload.
>   * Changes by Christian Göttsche
> - d/tests: run as root to fix debci (Closes: #907020)
> - d/control: bump to std version 4.2.1 (no further changes)
> 
>  -- Teemu Toivola   Tue, 23 Jul 2019 00:47:18 +0300

What's the situation of this package, are you now taking over
the Debian packaging as well? Is Christian just missing a sponsor?

>From a technical perspective the policy is already at 4.4, though
that should not matter so much in this specific case.

Sven

Bug#916987: fusermount: unknown option 'user=name'

[Sven Hoexter]

On Fri, Dec 21, 2018 at 04:41:13PM +0100, Adrian Siemieniak wrote:

Hi,

> Hmm but fusefat is working - this is also block device.
> 
> p  fusefat - File System in User Space - Module for FAT

I actually tried it, but it does not work for me on devices
or I'm doing it wrong. According to the documentation this one
seems to be more centered on mounting image files. So no fuse "blkdev"
option involved.


> And I may be wrong, but this was working some time ago - I just did not
> checked it, since I had some lines in /etc/fstab for mounting my devices on
> auto with user rights. So if it was ntfs/vfat system used standard mount
> (ntfs3g - not fuse) and with exfat.. I'm not sure now...
> Anyway lately I used root, but yesterday I thought it's time to fix it
> and... :)

I think ntfs-3g is the better comparison, and they highlight the same issue
in the FAQ:
https://www.tuxera.com/community/ntfs-3g-faq/#useroption

So one option is doing the same and setuid the mount.exfat-fuse binary.

The other one would be using pmount and patching it yourself. The required
change is actually less intimidating then expected. Seems I'm not the only
one who looked into the issue.
Bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755434
Relevant patch 
https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=755434;filename=patch;msg=19


> Ando also fusermount is suidrooted
> $ ls -ld /bin/fusermount
> -rwsr-xr-x 1 root root 34896 Aug  5 17:07 /bin/fusermount

Well I don't want to look into who drops which privs when.


Just for the sake of completeness I had a look at the exfat-fuse source.
https://github.com/relan/exfat/blob/master/fuse/main.c#L495
There's the place where the "user=" option is set.

The blkdev option is added here
https://github.com/relan/exfat/blob/master/fuse/main.c#L530

So if you like you could comment out the stuff around L495
but then I'm pretty sure you end up with blkdev issue as explained above
in fusermount. That's at least how far I went with my attempt to understand
the issue. You can always try to open a question upstream on github to maybe
get a more detailed answer.

Sven

Bug#916987: fusermount: unknown option 'user=name'

[Sven Hoexter]

On Fri, Dec 21, 2018 at 01:01:55PM +0100, Adrian Siemieniak wrote:

Hi,

> Well, the problem is I don't set this options "user=uid" - this is done
> somewhere in between by fuse or exfat-fuse - I don't know.

Now that I thought a bit more about it, I think it's not possible to
mount block devices through fuse without root permission.
I vaguely remember some discussions about it and there is a check for it
in fusermount
https://github.com/libfuse/libfuse/blob/master/util/fusermount.c#L784

Something like exfat support in pmount could be a nice enhacement. But that's
a bit outside of the scope of exfat-fuse itself.

Sven

Bug#916987: fusermount: unknown option 'user=name'

[Sven Hoexter]

On Fri, Dec 21, 2018 at 01:01:55PM +0100, Adrian Siemieniak wrote:
> W dniu 21.12.2018 o 12:51, Sven Hoexter pisze:
> > On Fri, Dec 21, 2018 at 12:41:11AM +0100, Adrian Siemieniak wrote:

Hi Adrian,

> > > Trying to mount exfat device by unprivileged user renders this error:
> > > :~$ /sbin/mount.exfat-fuse -d /dev/sdg1 mnt/
> > > FUSE exfat 1.3.0
> > > fusermount: unknown option 'user=sauron'
> > > 
> > > It the same with different users and I've also tested it on other machine 
> > > (also Debian/Sid).
> > 
> > I'm not entirely sure what you like to achieve. To the best of my knowledge 
> > the exfat fuse
> > implementation only supports the filesystem options listed in man 8 
> > mount.exfat.
> > I also had a short look into man 8 mount.fuse and can't find any mention of 
> > a "user" option,
> > so I'm not even sure if you expect it to be a filesystem option or a fuse 
> > option.
> 
> Well, the problem is I don't set this options "user=uid" - this is done
> somewhere in between by fuse or exfat-fuse - I don't know.

Ok I had a short look at this. I can see (via strace) that there is the 
following
invocation of fusermount:

24748 execve("/bin/fusermount", ["fusermount", "-o", 
"rw,nosuid,nodev,allow_other,default_permissions,blksize=4096,user=sven,blkdev,fsname=/dev/sdb",
 "--", "/home/sven/mnt"], 0x55d976d2ea90 /* 25 vars */) = 0

Looking into libfuse/lib/mount.c (the fuse source package), I can find a
FUSE_OPT_KEY("user=",   KEY_MTAB_OPT),

I would assume it should be able to handle that one, though it seems it does 
not.

Sven

Bug#916987: fusermount: unknown option 'user=name'

[Sven Hoexter]

On Fri, Dec 21, 2018 at 12:41:11AM +0100, Adrian Siemieniak wrote:

Hello Adrian,

> Trying to mount exfat device by unprivileged user renders this error:
> :~$ /sbin/mount.exfat-fuse -d /dev/sdg1 mnt/
> FUSE exfat 1.3.0
> fusermount: unknown option 'user=sauron'
> 
> It the same with different users and I've also tested it on other machine 
> (also Debian/Sid).

I'm not entirely sure what you like to achieve. To the best of my knowledge the 
exfat fuse
implementation only supports the filesystem options listed in man 8 mount.exfat.
I also had a short look into man 8 mount.fuse and can't find any mention of a 
"user" option,
so I'm not even sure if you expect it to be a filesystem option or a fuse 
option.

In general user management on fat filesystems is a bit wacky, usually the uid 
from the process
executing the mount is used as owner and group of all files.

Sven

Bug#916859: closed by Andrey Rahmatullin (Re: Bug#916859: RFS: PDF Studio Viewer/2018 [ITP] -- pdf viewer)

[Sven Hoexter]

On Wed, Dec 19, 2018 at 05:12:39PM -0500, Studio Support wrote:
> Hello Andrey,
> 
> Regarding the solution on Bug#916859 about our package "pdfstudioviewer"
> 
> It's free in the real sense of the term, meaning that users don't pay for it. 
> But it is not open source. Our end-user license is displayed to users upon 
> running our application the first time. 
> 
> We don't care if our application is listed under the Free or the Commercial 
> products. 
> 
> We have a Debian installer so I hope you can use that.

Hi,
I, and propably many more Debian developers, appreciate that you try to engange
with the Debian project, but really we're focused on open source software. You 
might
want to read https://www.debian.org/social_contract.html

So yes it's true that we have this sad part called "non-free" on our mirrors 
but formally
it's not really part of the distribution, and still everything shipped in 
non-free requires
to have a source package as well. 
https://wiki.debian.org/Packaging/SourcePackage

In the end I can only encourage you to open source your software, otherwise 
you've to move
on and distribute it via your own self hosted repository.

Sven

Bug#903767: Bug#903800: 4.9.110-1 Xen PV boot workaround

[Sven Hoexter]

The package is available via stretch-proposed-updates. Just add that one to 
your sources.list until the next point release or linux security update.

HTH,
Sven

Am 22. Juli 2018 22:48:35 MESZ schrieb Jered Floyd :
>
>It appears that this ticket has been closed, noting a fix in
>linux-4.9.110-2 (source pkg).  Will this replace the current
>linux-image-4.9.0-7-amd64 in stretch soon?  It's currently making
>stretch unusable with Xen.
>
>--Jered
>
>- On Jul 17, 2018, at 6:23 AM, Hans van Kranenburg h...@knorrie.org
>wrote:
>
>> On 07/17/2018 12:39 AM, Benoît Tonnerre wrote:
>>> Hi,
>>> 
>>> I tested this workaround : I confirm that it works on Xen host, but
>not
>>> on Xen guest.
>>> If you try to start a vm with latest kernel i.e. theses parameters
>in
>>> cfg file :
>>> 
>>> #
>>> #  Kernel + memory size
>>> #
>>> kernel  = '/boot/vmlinuz-4.9.0-7-amd64'
>>> extra   = 'elevator=noop'
>>> ramdisk = '/boot/initrd.img-4.9.0-7-amd64'
>>> 
>>> The VM crash in loop with kernel error :
>>> 
>>> [...]
>>> 
>>> Did I miss something ?
>> 
>> Yes, the pti=off needs to go in your extra line:
>> 
>>  extra = 'elevator=noop pti=off'
>> 
>> Hans
>
>--
>To unsubscribe, send mail to 903800-unsubscr...@bugs.debian.org.

Bug#893052: RFS: btrfsmaintenance/0.4.1-1 [I maintain the package]

[Sven Hoexter]

On Tue, Mar 20, 2018 at 10:38:37PM -0400, Nicholas D Steeves wrote:
> Hi Sven,
> 
> On Sat, Mar 17, 2018 at 08:06:13PM +0100, Sven Hoexter wrote:
> > Hi,
> > uploaded the package. I've to make up my mind about the kind of linux 
> > specific
> > arch all packaging stuff.
> > 
> > Sven
> 
> Thank you for sponsoring this upload :-)
> 
> Should I leave filing a wishlist bug against dpkg-dev, for the
> creation of an arch: linux-all to you, or go ahead and do it myself?

Hi Nicholas,
I would not fill a bug and I would not change anything else on the package.
Introducing something like "linux-all" would also require changes in
the archive software and other places. Just telling dpkg that it exists
is only a small part of the complete story.

After looking around and thinking a bit more about this issue, I think the
gain from solving it is very limited. If you try to install btrfsmaintenance
on kfreebsd or hurd you'll already be told that the dependencies are not
satisfiable because btrfsprogs is not available. In case someone would port
it and make it available, the situation gets more complicated. Now you
would be able to install the package and have the maintenance scripts
available, but you still might be lacking the btrfs support in the kernel.
At least at the moment that would not cause any harm because the cron job
is not enable by default and I guess the btrfsprogs tools would still fail
if executed. So at least there is no harm done to the system.

Since this is all very hypothetical I would just ignore this case for now.

If you would like to maybe get other viewpoints on this issue feel free to
ask on debian-mentors or debian-devel. My opinion is in the end just mine. :)

Cheers,
Sven

Bug#893052: RFS: btrfsmaintenance/0.4.1-1 [I maintain the package]

[Sven Hoexter]

On Tue, Mar 20, 2018 at 10:38:37PM -0400, Nicholas D Steeves wrote:
> Hi Sven,
> 
> On Sat, Mar 17, 2018 at 08:06:13PM +0100, Sven Hoexter wrote:
> > Hi,
> > uploaded the package. I've to make up my mind about the kind of linux 
> > specific
> > arch all packaging stuff.
> > 
> > Sven
> 
> Thank you for sponsoring this upload :-)
> 
> Should I leave filing a wishlist bug against dpkg-dev, for the
> creation of an arch: linux-all to you, or go ahead and do it myself?

I would be surprised if that's the first time we've this issue. So I
wanted to search for prior discussions first.

Sven

Bug#877163: RM: elyxer -- ROM; no upstream activity, giving up LyX and ecosystem maintenance

[Sven Hoexter]

tags 877163 - moreinfo
thanks

On Sat, Nov 18, 2017 at 07:27:54PM -0500, Scott Kitterman wrote:

> Checking reverse dependencies...
> # Broken Build-Depends:
> ngspice/non-free: elyxer
> 
> That'll have to be dealt with first.

Took some time, but now it's finally done for i386 and amd64 with
the upload of ngspice 27-1.

Sven

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Tue, Dec 26, 2017 at 09:01:47AM +0100, Gudjon I. Gudjonsson wrote:
> Hi Sven
> 
> > bi-directional sat link.) Though I'm not 100% sure if the {xhtml,png}
> > stuff is POSIX sh compatible.
> You are right, it fails when sbuilding.
> 
> The package is finally uploaded without any elyxer dependency. Thanks a lot 
> for your help.

Hi Gudjon, hi Andreas,
since I messed up the v26 NMU I just build your v27 package and uploaded it 
together
with a i386 and amd64 build.

Cheers,
Sven

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Mon, Dec 25, 2017 at 10:41:02PM +0100, Gudjon I. Gudjonsson wrote:
> > /build/ngspice-27/debian/tmp/usr/share/doc/ngspice-doc/html
> > cp: cannot stat '/build/ngspice-27/build/manual/manual.html.LyXconv/*': No 
> > such file or directory
> > debian/rules:125: recipe for target 'install-indep' failed
> > 
> > .LyXconv is something temporary, I've to take a closer look during the 
> > upcoming rainy days.
> > 
> Does it?
> It creates manual.xhtml on my computer and png pictures with terribly long 
> filenames but I can open the
> file manual.xhtml in firefox and it seems to display without any errors 
> (there are errors in the elyxer html output).
> 
> Just getting the output into a directory and I think the problem is solved.

You're right just realized that's something hardcoded in debian/rules. I 
thought it must
be something dynamically matched or from somewhere else in the build process. I 
should get
a bit more sleep maybe. ;)

My current diff looks like this:
diff -Nru ngspice-27/debian/control ngspice-27/debian/control
--- ngspice-27/debian/control   2016-03-28 20:54:04.0 +0200
+++ ngspice-27/debian/control   2016-03-28 20:54:04.0 +0200
@@ -21,7 +21,6 @@
blt-dev
 Build-Depends-Indep: lyx, 
  texlive,
- elyxer,
  texlive-science,
  texlive-latex-extra, 
  texlive-lang-greek,
diff -Nru ngspice-27/debian/rules ngspice-27/debian/rules
--- ngspice-27/debian/rules 2016-03-28 20:54:04.0 +0200
+++ ngspice-27/debian/rules 2016-03-28 20:54:04.0 +0200
@@ -83,8 +83,8 @@
# Build documentation
dh_testdir
#cd build/manual && lyx -userdir ./.lyx -batch --export ps manual.lyx 
-   -cd build/manual && lyx -userdir ./.lyx -batch --export pdf2 manual.lyx 
-   cd build/manual && lyx -userdir ./.lyx -batch --export html manual.lyx 
+   cd build/manual && lyx -userdir ./.lyx -batch --export pdf2 manual.lyx 
+   cd build/manual && lyx -userdir ./.lyx -batch --export xhtml manual.lyx 
touch $@
 
 clean:
@@ -124,7 +124,7 @@
 install-indep: build-indep
# Documentation for ngspice, the same as for tclspice
mkdir -p $(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/html
-   cp -a $(CURDIR)/build/manual/manual.html.LyXconv/* \
+   cp -a $(CURDIR)/build/manual/*.{xhtml,png} \
$(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/html
#install -o root -g root -m 644 build/manual/manual.ps \
#   $(CURDIR)/debian/tmp/usr/share/doc/ngspice-doc/ngspice.ps



I think that should work, build is still running somewhere were bandwith is
cheap but the disk is rather slow. (I'm currently working with mosh over a
bi-directional sat link.) Though I'm not 100% sure if the {xhtml,png}
stuff is POSIX sh compatible.


Cheers,
Sven

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Sun, Dec 24, 2017 at 12:52:47PM +0100, Gudjon I. Gudjonsson wrote:

Hi Gudjon,

> You are right. I did compile the file in a normal environment with elyxer 
> installed, sorry.
> But I cannot compile the package (version 27) after I uninstall elyxer. Lyx 
> fails without any 
> proper error message.
> The problem seems to be in the new documentation. If I copy the documentation 
> from ngspice-26 to
> ngspice-27, build-indep works.
> ngspice-26, manual.lyx is made with lyx 2.0 and lyx format 413
> ngspice-27, manual.lyx is made with lyx 2.1 and lyx format 474
> 
> Do you have any idea on how to remove this elyxer dependency from manual.lyx?

I doubt there is a dependency on elyxer. elyxer is just a lyx2html converter 
written
indepedently and stalled now for a few years.
I guess that you've to reconfigure LyX so it knows that elyxer is no longer 
available.
That's something you can only do in the GUI so far.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397464
and
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=816173
is also partially related.

So if you do not use LyX for interactive document writing just rm -r ~/.lyx in 
your
build environment and it should reconfigure on the next invocation.

Another possibility would be that lyx fails to import and convert the manual to 
the
current LyX 2.2.x document format.
Which repo are you building from right now? I'd like to try it out just to see 
what
happens.

Cheers,
Sven

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Fri, Dec 22, 2017 at 06:29:39PM +0100, Gudjon I. Gudjonsson wrote:
> Hi
> 
> Now I have updated the git repository and only final testing is needed before 
> upload.
> 
> But I get the following lintian warning.
> W: ngspice-doc: privacy-breach-generic 
> usr/share/doc/ngspice-doc/html/manual.html (http://elyxer.nongnu.org/lyx.css)
> 
> and I don't find any reference to elyxer when grepping the source.
> Sven: Do you have any idea where this stems from?

Hi Gudjon,
I can only guess at the moment. Did you build this maybe inside a dirty chroot
where elyxer is still installed and lyx is configured to use it?
Or did you include some pre build pages which were initially created with 
elyxer?

When I check my NMU, which just ended up in unstable two days ago, I can no 
longer
find any reference to elyxer or this css file. So I assume you somehow managed 
to build
the package in an environment where elyxer is available.

Cheers,
Sven

Bug#884920: courierpassd: fails to change the password

[Sven Hoexter]

On Thu, Dec 21, 2017 at 01:09:05PM +0100, Lucio Crusca wrote:

Hello Lucio,

> I'm running courier with virtual mailboxes and userdb authentication.

I've bad news for you. I'm no longer the maintainer of courierpassd
and I ensured that it got removed from Debian in 2015[1]. So it's no
longer part of the current Debian/stable release anymore.

If you think that the package in jessie is already unusable I can
fill a request with the stable release team to get it removed with
the next/last jessie point release.

Cheers,
Sven

[1] https://tracker.debian.org/pkg/courierpassd

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

On Mon, Dec 11, 2017 at 06:58:10AM +0100, Gudjon I. Gudjonsson wrote:

Hi guys,

> I'm terribly sorry for having missed the bug.
> There is a new version in SVN (27) that is not fully prepared but will
> be in the next few days. If somebody is willing to sponsor it I will be
> very happy.

glad that I finally reached you. Since my changes have no real deadline and
are not critical for anything beside of cleaning up behind me, I'm pretty
relaxed. If you manage to organise your migration to git and prepare another
upload before my NMU moves through the delayed queue all fine with me.
IIRC the upload will be auto-rejected if the archive already provides a higher
version. Otherwise if you need more time Andreas or myself can also cancel the 
NMU.
Oh and I'm also available to sponsor an upload if the changes to the package are
not too many in case Andreas is not available.

In case you did not already know it, you can see the state of the deferred queue
with all delayed package uploads here 
https://ftp-master.debian.org/deferred.html

Cheers,
Sven

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

Hi Gudjon, hi Andreas,
I've uploaded the attached NMU to delayed/10 since I received no note from
you since opening the bug. So in case you object there's still some time
to act.

Cheers,
Sven


ngspice_26-1.2.debian.tar.xz
Description: application/xz
diff -Nru ngspice-26/debian/changelog ngspice-26/debian/changelog
--- ngspice-26/debian/changelog	2016-04-25 20:51:09.0 +0200
+++ ngspice-26/debian/changelog	2017-12-10 14:53:20.0 +0100
@@ -1,3 +1,14 @@
+ngspice (26-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove elyxer from Build-Depends-Indep to allow for the removal of elyxer
+from Debian. The build in HTML export support in LyX improved during the
+last years and is equally usable or even better regarding new LyX file
+formats.
+  * Change package priority from extra to optional.
+
+ -- Sven Hoexter <hoex...@debian.org>  Sun, 10 Dec 2017 14:53:20 +0100
+
 ngspice (26-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ngspice-26/debian/control ngspice-26/debian/control
--- ngspice-26/debian/control	2014-07-05 23:49:29.0 +0200
+++ ngspice-26/debian/control	2017-12-10 14:52:17.0 +0100
@@ -1,13 +1,13 @@
 Source: ngspice
 Section: non-free/electronics
-Priority: extra
+Priority: optional
 Maintainer: Debian Science Team <debian-science-maintain...@lists.alioth.debian.org>
 Uploaders: Gudjon I. Gudjonsson <gud...@gudjon.org>,
  Andreas Tille <ti...@debian.org>
 Build-Depends: debhelper (>= 8), automake, libtool, libxaw7-dev, flex,
  bison, gfortran, libedit-dev, libncurses5-dev,
  texinfo, tcl8.6-dev, tcl8.6, tk8.6-dev, tk8.6, blt-dev
-Build-Depends-Indep: lyx, elyxer, texlive, texlive-latex-extra, texlive-lang-greek,
+Build-Depends-Indep: lyx, texlive, texlive-latex-extra, texlive-lang-greek,
  texlive-generic-recommended, imagemagick
 Standards-Version: 3.9.5
 Homepage: http://ngspice.sourceforge.net
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 3.0 (quilt)
Source: ngspice
Binary: ngspice, tclspice, ngspice-doc
Architecture: any all
Version: 26-1.2
Maintainer: Debian Science Team 
<debian-science-maintain...@lists.alioth.debian.org>
Uploaders: Gudjon I. Gudjonsson <gud...@gudjon.org>, Andreas Tille 
<ti...@debian.org>
Homepage: http://ngspice.sourceforge.net
Standards-Version: 3.9.5
Vcs-Browser: 
http://anonscm.debian.org/viewvc/debian-science/packages/ng-spice-rework/trunk/
Vcs-Svn: svn://anonscm.debian.org/debian-science/packages/ng-spice-rework/trunk/
Build-Depends: debhelper (>= 8), automake, libtool, libxaw7-dev, flex, bison, 
gfortran, libedit-dev, libncurses5-dev, texinfo, tcl8.6-dev, tcl8.6, tk8.6-dev, 
tk8.6, blt-dev
Build-Depends-Indep: lyx, texlive, texlive-latex-extra, texlive-lang-greek, 
texlive-generic-recommended, imagemagick
Package-List:
 ngspice deb non-free/electronics optional arch=any
 ngspice-doc deb non-free/doc optional arch=all
 tclspice deb non-free/electronics optional arch=any
Checksums-Sha1:
 be5c90e0552bbe4f0091543742d5863dd50319e0 847177 ngspice_26.orig-manual.tar.gz
 270da390743f7cfd7dae5f915a2c30dee65d4262 6732799 ngspice_26.orig.tar.gz
 3fdb9c2de03fbd3ca1634bf08336e439afb393dd 12868 ngspice_26-1.2.debian.tar.xz
Checksums-Sha256:
 952d8118289fdace380505b589e0b45172259bd8f4385aa2149bdb1cc41d2ad0 847177 
ngspice_26.orig-manual.tar.gz
 d6bb6cba146810c08a384a56016484ad47f7246a2dd1a932344b4161c8b86284 6732799 
ngspice_26.orig.tar.gz
 fdd6a697991579ca0da793f2eb98c92345ea858172de94ee7aaa34840cc6efd2 12868 
ngspice_26-1.2.debian.tar.xz
Files:
 59bdfaba4f550507909060ad3f308e2f 847177 ngspice_26.orig-manual.tar.gz
 4f1e945cb94a3f42176cf84ba8f2d4f4 6732799 ngspice_26.orig.tar.gz
 be1744c58fe304330fc02b26f3643f03 12868 ngspice_26-1.2.debian.tar.xz
Autobuild: yes

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfAcX+forK514ixQbptwk2dokk9EFAlotRUEACgkQptwk2dok
k9FlThAAliZNuE/LLScNPn1kCQsu+/tZbzjFdsB1mWmWbcYYd8pL8sCfgxD5nOhQ
D5oqEvBg/LkWuRyTTD98gJ3CeXtYE3V1FBXA4FYwGwQzbUKfphaokXrUmtbiFgNo
2336nODfxlBlI7+KhYOXdKPZPawt0U7D+aRjAOpD6zxpETuCP2A/Dy8imWvHyc06
b/c++C4/LRdH2Iq5LdXVcY50UGYbs5NcUfWiVJ+jlYqWawIu775BRJ+eQgN41huN
aOPNDKe466HoebYl/C8hhqCAWsA98RM6L5txYiHe93X6v4Umpa2zHx2x8jAhB/e4
eLjlXb15kR6cLRPhQsKMUW9ysO7Rncn0uZeVVWT3i5vDCXKhB7lZ7/KcAn1Y8IR8
YvWqi7jmAIhzAo7+0oHHMZ6EzTzuHYmUzURgbbqfI7XqLB+ele4Bs37nDWByC4b5
eSri4AGBY9x4SHmJyifsQk8iY/jpaWnmw6xZ8tibLjnlhc1YxRMgy9WnTAlFc68m
WRwh6LcSPcSVB2v9bEYcgVRtHEeoR2vxybTJJwxmAaXfi+6/o7LLyzqVDz4spTQE
d0lZzY79M0oSPT8IJhB20TnsZDmr8b+XYLsUKVTG/RQK7yqggL4QhNbO2SIGieLE
zhwreHRRb+4Mk4VNgcTNypqYc68Gs9WsnAbWEeuELdofYwIJyGo=
=+o0V
-END PGP SIGNATURE-

Bug#882699: ngspice: Remove build dependency on elyxer to allow for the elyxer removal from Debian

[Sven Hoexter]

Source: ngspice
Version: 26-1.1
Severity: important
Tags: patch

Hello Gudjon, hello Andreas,
I'd like to get elyxer removed from Debian but to allow for that to happen I 
need to get
rid of ngspice dependency on it. The HTML export support in LyX improved a lot 
since
I introduced elyxer to Debian and is nowadays, while not that pretty, on par or 
even better
(as in more complete) then what elyxer has to offer. Also elyxer didn't receive 
any update
for a long time. I see at least some issue when I generate the ngspice 
documentation HTML
export with elyxer.

I've attached the debdiff of a potential NMU I'm willing to upload since I'm 
not sure how
active you're at the moment taking care of ngspice. So if you do not plan to 
upload ngspice
on your own soon and do not object to the elyxer removal itself, I can just 
upload my NMU.

Cheers,
Sven
diff -Nru ngspice-26/debian/changelog ngspice-26/debian/changelog
--- ngspice-26/debian/changelog 2016-04-25 20:51:09.0 +0200
+++ ngspice-26/debian/changelog 2017-11-25 20:12:49.0 +0100
@@ -1,3 +1,13 @@
+ngspice (26-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove elyxer from Build-Depends-Indep to allow for the removal of elyxer
+from Debian. The build in HTML export support in LyX improved during the
+last years and is equally usable or even better regarding new LyX file
+formats.
+
+ -- Sven Hoexter <hoex...@debian.org>  Sat, 25 Nov 2017 20:12:49 +0100
+
 ngspice (26-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru ngspice-26/debian/control ngspice-26/debian/control
--- ngspice-26/debian/control   2014-07-05 23:49:29.0 +0200
+++ ngspice-26/debian/control   2017-11-25 20:12:23.0 +0100
@@ -7,7 +7,7 @@
 Build-Depends: debhelper (>= 8), automake, libtool, libxaw7-dev, flex,
  bison, gfortran, libedit-dev, libncurses5-dev,
  texinfo, tcl8.6-dev, tcl8.6, tk8.6-dev, tk8.6, blt-dev
-Build-Depends-Indep: lyx, elyxer, texlive, texlive-latex-extra, 
texlive-lang-greek,
+Build-Depends-Indep: lyx, texlive, texlive-latex-extra, texlive-lang-greek,
  texlive-generic-recommended, imagemagick
 Standards-Version: 3.9.5
 Homepage: http://ngspice.sourceforge.net

Bug#805427: ngspice: FTBFS due to lyx/elyxer problem

[Sven Hoexter]

Hi,
while looking into removing elyxer from Debian I stumpled upon your bugreport.
I just rebuild ngspice with pbuilder without elyxer and can not reproduce
the issue you describe. Either things changed with the current LyX release
(I don't think so, but I did not follow the development closely) or your
issue is not reproducible in my (chroot'ed) environment.

Do you mind providing some more information about the circumstances you
encountered the issue and maybe retest it.

Regards,
Sven

Bug#634757: Adoption of lyx

[Sven Hoexter]

On Sun, Oct 08, 2017 at 05:47:26PM +0200, Dr. Tobias Quathamer wrote:

Hey,

> In case of packaging problems and questions, may I contact you again?

Sure, I'm still alive and have an eye on pkg-lyx-devel@lists.a.d.o as
long as alioth is around. But you can also approach me directly.

Sven





signature.asc
Description: PGP signature

Bug#634757: Adoption of lyx

[Sven Hoexter]

On Sun, Oct 08, 2017 at 05:10:42PM +0200, Dr. Tobias Quathamer wrote:

Hey,

> I've seen that you, Sven, have removed yourself from the uploaders. I
> don't know if Nick is a DD and still interested in the package.

He's not (yet) a DD.


> If there's currently noone actively packaging lyx, I'll adopt the
> package completely. However, if Nick is still interested, that would be
> great!

Please go ahead! There quite a few barely tested changes I made to the packaging
lingering in git master because the lintian on ftp-master is a bit dated and 
still
rejected the lyx@packages.d.o email address as maintainer address. Not sure if 
that's
solved by now. Maybe you've to revert that change for a few more weeks in case 
you'd
like to push out the pending changes asap.


> I have just asked to join the alioth group for git access.

I just added you as an admin.


Cheers,
Sven





signature.asc
Description: PGP signature

Bug#874373: RFS: vnstat/1.17-1+nmu1 ITA

[Sven Hoexter]

On Fri, Oct 06, 2017 at 02:05:12PM +0200, Christian Göttsche wrote:
> I uploaded a new package version in which the not upstreamed patches
> are dropped, the maintainer is set to myself and the vcs fields are
> updated accordingly.
> With #874387 Felix is searching for a new maintainer for this package;
> what are the requirements for me to become such?

Basically just set yourself as the maintainer (the technical part) and
find a sponsor to review and upload the package (the more social part).


> Also, I like to ask a technical question:
> What is the common dealing with state file upon package purge?
> Vnstat saves the network statistics under /var/lib/vnstat and as this
> folder is listed in debian/vnstat.install, dpkg warns upon purge
> operation that this directory cannot be deleted, because it is not
> empty.
> Should the directory be emptied in the postrm script or is this
> warning acceptable?

Should be deleted on purge. I think mariadb packaging nowadays
has an additional debconf fronted question if you really want to purge
the database. I personally do not think that the value of vnstat history
is so huge to implement an additional dialog but YMMV.

Sven

Bug#865242: [Pkg-lyx-devel] Bug#865242: Please update dependencies from latex-xcolor to tl-latex-recommended

[Sven Hoexter]

On Tue, Jun 20, 2017 at 02:05:00PM +0900, norb...@preining.info wrote:

Hi,

> latex-xcolor has been a dummy transitional package now since 2 releases
> (since oldstable), and has been dropped in current unstable.
> 
> Please update your dependencies to texlive-latex-recommended.

Thanks Norbert, commited & pushed the change to git. Should hit the
archive with the next upload, though that might take a while.
Since we already recommend texlive-latex-recommended for while that
issue should not hurt users, might just confuse someone.

Sven

Bug#857847: java-package: proposal to add a --no-deps flag to make-jpkg

[Sven Hoexter]

On Wed, Mar 15, 2017 at 05:22:27PM +0100, Emmanuel Bourg wrote:

Hi Emmanuel,

> Thank you for the patch Sven. This looks like a reasonable compromise to
> support multiple releases. Regarding the implementation, I wonder if
> this could be achieved with an override_dh_shlibdeps in the rules file
> used to generate the package.

Seems to work equally well. Patch attached.

Sven
diff --git a/lib/javase.sh b/lib/javase.sh
index fd025ca..3b11095 100644
--- a/lib/javase.sh
+++ b/lib/javase.sh
@@ -88,12 +88,21 @@ EOF
 override_dh_compress:
 	dh_compress \$(shell find $j2se_name/man/ -type f ! -name '*.gz' -printf '${jvm_base##/}/%p\n')
 
-override_dh_shlibdeps:
-	dh_shlibdeps \$(EXCLUDE_LIBS) -l\$(shell find $j2se_name -type f -name '*.so*' -printf '${jvm_base##/}/%h\n' | sort -u | tr '\n' ':' | sed 's/:\$\$//')
-
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
 EOF
+if [ "${no_deps:-false}" == "true" ]; then
+	cat << EOF
+override_dh_shlibdeps:
+# Disabled, aides to generate one package for different Debian releases - BTS #857847
+EOF
+else
+	cat << EOF
+override_dh_shlibdeps:
+	dh_shlibdeps \$(EXCLUDE_LIBS) -l\$(shell find $j2se_name -type f -name '*.so*' -printf '${jvm_base##/}/%h\n' | sort -u | tr '\n' ':' | sed 's/:\$\$//')
+EOF
+fi
+
 }
 
 j2se_doc_rules() {
@@ -106,6 +115,12 @@ j2se_doc_rules() {
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
 EOF
+if [ "${no_deps:-false}" == "true" ]; then
+	cat << EOF
+override_dh_shlibdeps:
+# Disabled, aides to generate one package for different Debian releases - BTS #857847
+EOF
+fi
 }
 
 
diff --git a/make-jpkg b/make-jpkg
index 3db992c..6498b61 100755
--- a/make-jpkg
+++ b/make-jpkg
@@ -89,6 +89,7 @@ The following options are recognized:
   --source build a source package instead of a binary deb package
   --with-system-certs  integrate with the system's keystore
   --jce-policy FILEReplace cryptography files with versions from FILE
+  --no-depsAdds override for dh_shlibdeps based "Depends"
 
   --help   display this help and exit
   --versionoutput version information and exit
@@ -146,6 +147,8 @@ while [[ $# -gt 0 && "x$1" == x--* ]]; do
 revision="-${1}"
 elif [[ "x$1" == x--changes ]]; then
 genchanges="true"
+elif [[ "x$1" == x--no-deps ]]; then
+no_deps="true"
 elif [[ "x$1" == x--source ]]; then
 build_source="true"
 elif [[ "x$1" == x--with-system-certs ]]; then
diff --git a/make-jpkg.1 b/make-jpkg.1
index 34a5462..47eb2f9 100644
--- a/make-jpkg.1
+++ b/make-jpkg.1
@@ -70,6 +70,10 @@ ca-certificates and ca-certificates-java packages.
 Replace cryptography files with versions
 from the specified JCE_POLICY_FILE.
 .TP
+.B --no-deps
+Adds override for dh_shlibdeps based "Depends". Allows to build a package
+without Debian release specific depdencies.
+.TP
 .B --help
 display help text and exit
 .TP

Bug#857847: java-package: proposal to add a --no-deps flag to make-jpkg

[Sven Hoexter]

On Wed, Mar 15, 2017 at 05:22:27PM +0100, Emmanuel Bourg wrote:

Hi Emmanuel,

> Thank you for the patch Sven. This looks like a reasonable compromise to
> support multiple releases. Regarding the implementation, I wonder if
> this could be achieved with an override_dh_shlibdeps in the rules file
> used to generate the package.

I think in theory that should also work, but I did not try it.
I'll give it a try.

Sven

Bug#852342: patch proposal add --no-strip parameter

[Sven Hoexter]

On Wed, Mar 15, 2017 at 05:08:53PM +0100, Emmanuel Bourg wrote:
> Le 15/03/2017 à 17:01, Sven Hoexter a écrit :
> 
> > Would that be something you'd be willing to accept?
> 
> If the stripping breaks jmap, I guess it might be better to disable it
> completely. Is there a good reason to keep it?

Just hacked together a short override patch.

Sven
diff --git a/lib/javase.sh b/lib/javase.sh
index fd025ca..0457dc4 100644
--- a/lib/javase.sh
+++ b/lib/javase.sh
@@ -93,6 +93,9 @@ override_dh_shlibdeps:
 
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
+
+override_dh_strip:
+# Disable, breaks jmap and other tools - BTS #852342
 EOF
 }
 
@@ -105,6 +108,9 @@ j2se_doc_rules() {
 
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
+
+override_dh_strip:
+# Disable, breaks jmap and other tools - BTS #852342
 EOF
 }
 

Bug#852342: patch proposal add --no-strip parameter

[Sven Hoexter]

On Wed, Mar 15, 2017 at 05:08:53PM +0100, Emmanuel Bourg wrote:
> If the stripping breaks jmap, I guess it might be better to disable it
> completely. Is there a good reason to keep it?

Well the idea was to still accomodate people who value disk space over
the usability of debugging related tools. I personally would also just
go without stripping the binary files and value the usability of the tools
over space.

To add a bit of data, here is the size of the extracted packages stripped
and unstripped:
~/oracle-jdk-deb-package$ du -hs extract-*
357Mextract-no-strip
344Mextract-stripped

So from my point of view the difference in size is neglectable, so I'd be
also fine with a fixed "override_dh-strip:" in the generated rules file.

Sven

Bug#852342: patch proposal add --no-strip parameter

[Sven Hoexter]

Hi,
maybe something like the attached patch would help to solve this problem?
@Emmanuel et al:
Would that be something you'd be willing to accept?

Sven

diff --git a/lib/javase.sh b/lib/javase.sh
index fd025ca..6b3f217 100644
--- a/lib/javase.sh
+++ b/lib/javase.sh
@@ -94,6 +94,13 @@ override_dh_shlibdeps:
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
 EOF
+
+if [ "${no_strip}" == "true" ]; then
+	cat << EOF
+override_dh_strip:
+# Do not strip the files - BTS #852342
+EOF
+fi
 }
 
 j2se_doc_rules() {
@@ -106,6 +113,13 @@ j2se_doc_rules() {
 override_dh_strip_nondeterminism:
 	# Disable dh_strip_nondeterminism to speed up the build
 EOF
+
+if [ "${no_strip}" == "true" ]; then
+	cat << EOF
+override_dh_strip:
+# Do not strip the files - BTS #852342
+EOF
+fi
 }
 
 
diff --git a/make-jpkg b/make-jpkg
index 3db992c..4bf60c6 100755
--- a/make-jpkg
+++ b/make-jpkg
@@ -89,6 +89,7 @@ The following options are recognized:
   --source build a source package instead of a binary deb package
   --with-system-certs  integrate with the system's keystore
   --jce-policy FILEReplace cryptography files with versions from FILE
+  --no-strip   override dh_strip invocation in the genrated rules file
 
   --help   display this help and exit
   --versionoutput version information and exit
@@ -148,6 +149,8 @@ while [[ $# -gt 0 && "x$1" == x--* ]]; do
 genchanges="true"
 elif [[ "x$1" == x--source ]]; then
 build_source="true"
+elif [[ "x$1" == x--no-strip ]]; then
+no_strip="true"
 elif [[ "x$1" == x--with-system-certs ]]; then
 create_cert_softlinks="true"
 else

Bug#854039: package more or less up for adoption

[Sven Hoexter]

Just a reference is someone else is looking into the state
of amavisd-milter - the package is more or less up for adoption,
announced here:
https://lists.debian.org/debian-devel/2016/12/msg00133.html

Sven

Bug#851922: [PATCH] please switch exfat-utils to use autoreconf to allow jessie bpo

[Sven Hoexter]

On Thu, Jan 19, 2017 at 05:17:31PM -0700, Nicholas D Steeves wrote:

> I ran into trouble with missing aclocal-1.15 when backporting this
> release.  Switching to use autoreconf seems to do the trick.  Diff was
> made against debian/1.2.5-1.  I've attached a patch for this switch,
> and a patch for the backport, with the hope being that it will also be
> easy to adapt to the [ Other Contributor ] d/changelog format.  Please
> apply this change to master so that no-change bpos will continue to be
> possible :-)

Hi Nicholas,
fixed similar to what I explained for #851920. Your patch is imported but
the changelog looks a bit different, make up your mind regarding a backport
if you'd like to have it build now or later once 1.2.5-2 is in testing.

Cheers,
Sven

Bug#851920: [PATCH] please switch fuse-exfat to use autoreconf to allow jessie bpo

[Sven Hoexter]

On Thu, Jan 19, 2017 at 05:13:42PM -0700, Nicholas D Steeves wrote:

Hi Nicholas,

> I ran into trouble with missing aclocal-1.15 when backporting this
> release.  Switching to use autoreconf seems to do the trick.  Diff was
> made against debian/1.2.5-1.  I've attached a patch for this switch,
> and a patch for the backport, with the hope being that it will also be
> easy to adapt to the [ Other Contributor ] d/changelog format.  Please
> apply this change to master so that no-change bpos will continue to be
> possible :-)

In general I'm not that keen on implementing such changes for backports
only but it does not hurt in this case. So I've imported your patch, the 
changelog
looks a bit different because I've done a new upload to unstable and that
has nothing todo with a backport. So if you pull my source tree you'll see
your commit + a different one for the changelog.

Feel free to either wait 10 days for the migration of 1.2.5-2 and backport
based on that package or provide a source package with your changes based
on 1.2.5-1.

Cheers,
Sven

Bug#847161: [Pkg-lyx-devel] Bug#847161: Updating the lyx Uploaders list

[Sven Hoexter]

tags 847161 pending
thanks

On Tue, Dec 06, 2016 at 07:50:36AM +0100, Tobias Frost wrote:

Hi Tobias,

> Per Olofsson  has not been working on
> the lyx package for quite some time, also his email is bouncing.
> 
> We are tracking their status in the MIA team and would like to ask you
> to remove them from the Uploaders list of the package so we can close
> that part of the file.

Yeah I noticed this as well, commited the change to git now, but might
take some time till we manage to upload a new LyX package if nothing
severe happens before the freeze.

Sven

Bug#847236: exfat-utils: Crashes with message "BUG: failed to convert name to UTF-8."

[Sven Hoexter]

[intentional full quote for Andrew]

Hi,
I've just uploaded 1.2.5, though I don't think that will change
much. Andrew, correct me if I'm wrong but as far as I remember
the fsck implementation is still far from complete.

Jacob, I'm not sure, Andrew might correct me here as well, but
it could help if you add the dbg repository and install the
matching exfat-utils-dbgsym package.
https://wiki.debian.org/AutomaticDebugPackages
That should enable you to produce a more meaningful backtrace.

Beside of that, if there are no confidential data on your disk,
some people provided a disk image for Andrew to allow easier
debugging.


Sven


On Tue, Dec 06, 2016 at 12:38:06PM -0600, Jacob Quant wrote:
> Package: exfat-utils
> Version: 1.2.4-1
> Severity: normal
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> 
>  I was trying to repair an exfat volume (USB stick) that had not
>  been cleanly unmounted.
> 
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> 
>  I ran `fsck /dev/sdXn`
> 
>* What was the outcome of this action?
> 
>  It apparently didn't complete but rather output the following:
>  ERROR: illegal UTF-16 sequence.
>  BUG: failed to convert name to UTF-8.
> 
>  In case it's helpful, here's a full transcript of running this
>  through gdb:
> ```
> 
> root@fractal:~# gdb /sbin/exfatfsck 
> GNU gdb (Debian 7.11.1-2+b1) 7.11.1
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /sbin/exfatfsck...(no debugging symbols found)...done.
> (gdb) run /dev/sdb1
> Starting program: /sbin/exfatfsck /dev/sdb1
> exfatfsck 1.2.4
> Checking file system on /dev/sdb1.
> File system version   1.0
> Sector size 512 bytes
> Cluster size128 KB
> Volume size 120 GB
> Used space   73 GB
> Available space  47 GB
> ERROR: illegal UTF-16 sequence.
> BUG: failed to convert name to UTF-8.
> 
> Program received signal SIGABRT, Aborted.
> __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> 58../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) bt
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:58
> #1  0x77a7040a in __GI_abort () at abort.c:89
> #2  0x6d7a in ?? ()
> #3  0xb35f in ?? ()
> #4  0x56c9 in ?? ()
> #5  0x569b in ?? ()
> #6  0x569b in ?? ()
> #7  0x569b in ?? ()
> #8  0x52d1 in ?? ()
> #9  0x77a5c2b1 in __libc_start_main (main=0x51e0, argc=2, 
> argv=0x7fffec88, init=, fini=, 
> rtld_fini=, stack_end=0x7fffec78) at 
> ../csu/libc-start.c:291
> #10 0x5389 in ?? ()
> (gdb) quit
> A debugging session is active.
> 
>   Inferior 1 [process 17133] will be killed.
> 
> Quit anyway? (y or n) y
> root@fractal:~# exfatfsck -V
> exfatfsck 1.2.4
> Copyright (C) 2011-2016  Andrew Nayenko
> 
> ```
> 
> 
>* What outcome did you expect instead?
> 
>  Some sort of normal termination / no errors.
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages exfat-utils depends on:
> ii  libc6  2.24-7
> 
> Versions of packages exfat-utils recommends:
> ii  exfat-fuse  1.2.4-1
> 
> exfat-utils suggests no packages.
> 
> -- no debconf information

Bug#831843: severity downgrade and LyX 2.2.2 uploaded

[Sven Hoexter]

severity 831843 normal
thanks

Hi Martin,
I'm sorry for the long delay in any answer to this bugreport
but the Debian LyX package is barely maintained at the moment.

I understand your frustration and for your usecase LyX might
be broken which is a grave issue, but I think LyX in general
still works fine so I'm now downgrading the bug to make
it none release critical.

>From my point of view it would be easier to maybe give you
hints on how to move on with your setup if you contact the
LyX developers either via their own mailinglist or via
their bugtracking system. That could avoid a lot of back and
forth. For example I would like to see your layouts to understand
why and where it breaks.

http://www.lyx.org/MailingLists
https://www.lyx.org/trac/wiki/BugTrackerHome

I can still forward your issue if you absolutely would like to
avoid doing that on your own, but that's usually very time
consuming for all involved parties with me acting as the human
proxy.


Beside of that it's a common issue that LyX format changes are
not backwards compatible. Usually the lyx2lyx tool is able to
handle a conversion in both directions. For example from the
last 2.1.x release to 2.2.0 and back. But I guess the lyx2lyx
in Debian/stable as shipped with 2.1.2 is too old to do that.
So if you maybe build the 2.1.5 release it might be able to
read the 2.2.0 imported document.
ftp://ftp.lyx.org/pub/lyx/stable/2.1.x/lyx-2.1.5.tar.xz
ftp://ftp.lyx.org/pub/lyx/stable/2.1.x/lyx-2.1.5.tar.xz.sig

But to be honest I've moved out of the LyX community 6 years
ago, so my advise might be outdated.


Beside of that we've now uploaded LyX 2.2.2, maybe that fixed
one of your issues, though the chance might be slim if you
did not report the issue upstream.

Regards,
Sven

Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible

[Sven Hoexter]

On Thu, Aug 18, 2016 at 04:49:23PM +0200, Stefan Sobernig wrote:
> > is it in svn
> 
> it is at the tip of the svn trunk.

Uploaded, took me some time to remember (and read up) how to use
svn-buildpackage.

Cheers,
Sven

Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible

[Sven Hoexter]

On Thu, Aug 18, 2016 at 02:24:09PM +0200, Stefan Sobernig wrote:

Hi Stefan,

> I prepared a package revision to account for
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797543.
> 
> @Sven: Can I kind askly you to check and upload the revised xotcl package?

Sure, is it in svn or do you have a source package at hand I can review?

Sven

Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible

[Sven Hoexter]

On Sun, Aug 14, 2016 at 10:51:48AM +0100, Chris Lamb wrote:

Hi Chris,

> There hasn't seem to be any update on this bug in 348 days, in which
> time the Reproducible Builds effort has come on a long way. :)
> 
> Would you consider applying this patch and uploading?

Since I once upon a time sponsored the upload of xotcl I just
considered doing a NMU. But then I discovered that due to the
still unfixed #821962 xotcl is already on the list of to be removed
packages.

Since I use neither xotcl nor aolserver I would currently refrain
from trying to support unmaintained packages further. But I'm putting
Stefan on CC in case he missed the mailinglist mails.

Regards,
Sven

Bug#816173: [Pkg-lyx-devel] Bug#816173: Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist

[Sven Hoexter]

On Mon, Feb 29, 2016 at 10:22:45PM +0100, Georg Baum wrote:
> Am 28.02.2016 um 18:22 schrieb Sven Hoexter:
> >On Sun, Feb 28, 2016 at 11:42:52AM +0100, picca wrote:

Hello Georg,

> >>1) lyx try to create a $HOME/.lyx even if $HOME does not exist
> >>2) it would be great to avoir creating this .lyx directory by default.
> >While I agree that 1) is a bug 2) is a bit more complicated.
> It is documented that LyX needs a user configuration directory. If the
> default location does not fit, you can use the -userdir parameter. Where is
> the problem? Would you like to fail in a different way if $HOME does not
> exist? It would be easy to add a check for that, but I'd like to understand
> the problem before doing anything.

IMO there should be a check, maybe in the python script itself, to check if
it can write to $HOME/.lyx at all. If not abort with an error message pointing
to the -userdir option. I think using the -userdir option is also the
way to go if you use lyx during build time in minimal build environments
like sbuild chroots.


> >LyX is not really intended to be used this way, it's more or less
> >centered around the idea of an GUI use in a real user environment.
> Most people do indeed use LyX that way, but using it via command line
> without a GUI is an important use case as well (and works fine in general).

Sorry I wasn't precise here, I used LyX + makefiles + git all the time.
My point was more about the build chroots without a real
user environment that is far away from some kind of "end user setup". Scrap
the "GUI" from my sentence.

Cheers,
Sven

Bug#816173: [Pkg-lyx-devel] Bug#816173: lyx: Lyx failed to start if the $HOME/.lyx does not exist

[Sven Hoexter]

On Sun, Feb 28, 2016 at 11:42:52AM +0100, picca wrote:

Hi,

> while preparing my tango package, I need to build the documentation with lyx.

For future reference, here is the d-d thread:
https://lists.debian.org/debian-devel/2016/02/msg00454.html

> It seems that it is not allow to write outside the source directory except 
> /tmp during the build process.
> 
> I see at least two problems.
> 
> 1) lyx try to create a $HOME/.lyx even if $HOME does not exist
> 2) it would be great to avoir creating this .lyx directory by default.

While I agree that 1) is a bug 2) is a bit more complicated.
LyX is not really intended to be used this way, it's more or less
centered around the idea of an GUI use in a real user environment.
It's part of the whole configuration problem, kind of a dublicate of #397464.

Sven

Bug#811007: information about build-deps on xchat

[Sven Hoexter]

Just to add a few more information regarding packages that will
FTBFS once xchat got removed:

- xchat-guile -> maintainer requested removal in #811079
- xchat-xsys -> hexchat-plugins contains its own xsys plugin so this one
  got a proper replacement and can be removed as well

That leaves only cwirc around which requires porting or removal.

Bug#811007: RM: xchat -- RoQA; dead upstream; active fork available

[Sven Hoexter]

Package: ftp.debian.org
Severity: normal

Hi,
please remove xchat. It's unmaintained upstream for 5+ years. The last
uploads to the Debian archive were NMUs, the last one over a year ago
by myself.

hexchat, an active fork, is available and has been released with jessie.

Some discussion on debian-qa can be found in this thread:
https://lists.debian.org/debian-qa/2015/09/msg00017.html
There was no hard oposition to remove the package so I'd say now is the
point to remove it, so we get rid of it before the next stable release.

Thanks guys,
Sven

Bug#804209: wheezy-pu: package fuse-exfat/0.9.7-2+deb7u1

[Sven Hoexter]

On Fri, Jan 01, 2016 at 06:26:22PM +, Adam D. Barratt wrote:

Hi Adam,

> Please go ahead.

Uploaded.

Regards,
S.

Bug#804208: jessie-pu: package fuse-exfat/1.1.0-2+deb8u1

[Sven Hoexter]

On Sat, Dec 05, 2015 at 07:13:42PM +, Adam D. Barratt wrote:

Hi Adam,

> Please go ahead.

Uploaded a minute ago.

Cheers,
Sven

Bug#802404: missing deps

[Sven Hoexter]

Hi,
at least some build-deps are missing:
 python-six,
 python3-six,
 python-pytest,
 python3-pytest

That fixes the build for Python 2.7 but later on fails
for Python 3.5


=== FAILURES 
===
___ test_file_handler_unicode[activation_strategy0] 


logfile = 
'/tmp/pytest-pbuilder/pytest-1/test_file_handler_unicode_acti0/logfile.log'
activation_strategy = 
logger = 

def test_file_handler_unicode(logfile, activation_strategy, logger):
with capturing_stderr_context() as captured:
with activation_strategy(logbook.FileHandler(logfile)):
logger.info(u('\u0431'))
>   assert (not captured.getvalue())
E   assert not 'Traceback (most recent call last):\n  File 
"/tmp/buildd/logbook-0.10.0/.pybuild/pythonX.Y_3.5/build/logbook/handlerse(128)\nLogged
 from file 
/tmp/buildd/logbook-0.10.0/.pybuild/pythonX.Y_3.5/build/tests/test_file_handler.py,
 line 25\n'
E+  where 'Traceback (most recent call last):\n  File 
"/tmp/buildd/logbook-0.10.0/.pybuild/pythonX.Y_3.5/build/logbook/handlerse(128)\nLogged
 from file 
/tmp/buildd/logbook-0.10.0/.pybuild/pythonX.Y_3.5/build/tests/test_file_handler.py,
 line 25\n' = ()
E+where  = <_io.StringIO object at 0x7f5fed6b3318>.getvalue

tests/test_file_handler.py:26: AssertionError


I'm not sure how to tackle that one.

HTH
Sven

Bug#804209: wheezy-pu: package fuse-exfat/0.9.7-2+deb7u1

[Sven Hoexter]

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

Hi,
since exfat-utils and fuse-exfat share the same code base, but are released
as seperate source packages, I've now prepared updates for fuse-exfat as well
to fix the issues found by The Fuzzing Project.

Changes: 
 fuse-exfat (0.9.7-2+deb7u1) wheezy; urgency=medium
 .
   * Add d/patches/check-sector-and-cluster-size. Fix for
 https://github.com/relan/exfat/issues/5 found and reported by
 The Fuzzing Project.
   * Add d/patches/detect-infinite-loop. Fix for
 https://github.com/relan/exfat/issues/6 found and reported by
 The Fuzzing Project.

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

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)
diff -u fuse-exfat-0.9.7/debian/gbp.conf fuse-exfat-0.9.7/debian/gbp.conf
--- fuse-exfat-0.9.7/debian/gbp.conf
+++ fuse-exfat-0.9.7/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = wheezy-updates
diff -u fuse-exfat-0.9.7/debian/changelog fuse-exfat-0.9.7/debian/changelog
--- fuse-exfat-0.9.7/debian/changelog
+++ fuse-exfat-0.9.7/debian/changelog
@@ -1,3 +1,14 @@
+fuse-exfat (0.9.7-2+deb7u1) wheezy; urgency=medium
+
+  * Add d/patches/check-sector-and-cluster-size. Fix for
+https://github.com/relan/exfat/issues/5 found and reported by
+The Fuzzing Project.
+  * Add d/patches/detect-infinite-loop. Fix for
+https://github.com/relan/exfat/issues/6 found and reported by
+The Fuzzing Project.
+
+ -- Sven Hoexter <hoex...@debian.org>  Fri, 06 Nov 2015 08:20:29 +0100
+
 fuse-exfat (0.9.7-2) unstable; urgency=low
 
   * Switch from dh compat level 8 to 9.
diff -u fuse-exfat-0.9.7/debian/patches/series fuse-exfat-0.9.7/debian/patches/series
--- fuse-exfat-0.9.7/debian/patches/series
+++ fuse-exfat-0.9.7/debian/patches/series
@@ -2,0 +3,2 @@
+check-sector-and-cluster-size
+detect-infinite-loop
only in patch2:
unchanged:
--- fuse-exfat-0.9.7.orig/debian/patches/check-sector-and-cluster-size
+++ fuse-exfat-0.9.7/debian/patches/check-sector-and-cluster-size
@@ -0,0 +1,49 @@
+Patch for https://github.com/relan/exfat/issues/5
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -172,6 +172,24 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("exFAT file system is not found");
+ 		return -EIO;
+ 	}
++	/* sector cannot be smaller than 512 bytes */
++if (ef->sb->sector_bits < 9)
++{
++exfat_close(ef->dev);
++exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
++free(ef->sb);
++return -EIO;
++}
++/* officially exFAT supports cluster size up to 32 MB */
++if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
++{
++exfat_close(ef->dev);
++exfat_error("too big cluster size: 2^(%hhd+%hhd)",
++ef->sb->sector_bits, ef->sb->spc_bits);
++free(ef->sb);
++return -EIO;
++}
++
+ 	if (ef->sb->version.major != 1 || ef->sb->version.minor != 0)
+ 	{
+ 		exfat_close(ef->dev);
+@@ -187,16 +205,6 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("unsupported FAT count: %hhu", ef->sb->fat_count);
+ 		return -EIO;
+ 	}
+-	/* officially exFAT supports cluster size up to 32 MB */
+-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+-	{
+-		exfat_close(ef->dev);
+-		free(ef->sb);
+-		exfat_error("too big cluster size: 2^%d",
+-(int) ef->sb->sector_bits + (int) ef->sb->spc_bits);
+-		return -EIO;
+-	}
+-
+ 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
+ 	if (ef->zero_cluster == NULL)
+ 	{
only in patch2:
unchanged:
--- fuse-exfat-0.9.7.orig/debian/patches/detect-infinite-loop
+++ fuse-exfat-0.9.7/debian/patches/detect-infinite-loop
@@ -0,0 +1,48 @@
+Patch for https://github.com/relan/exfat/issues/6
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -27,17 +27,32 @@
+ 
+ static uint64_t rootdir_size(const struct exfat* ef)
+ {
+-	uint64_t clusters = 0;
++uint32_t clusters 

Bug#804208: jessie-pu: package fuse-exfat/1.1.0-2+deb8u1

[Sven Hoexter]

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

Hi,
since exfat-utils and fuse-exfat share the same code base, but are released
as seperate source packages, I've now prepared updates for fuse-exfat as well
to fix the issues found by The Fuzzing Project.

Changes:
 fuse-exfat (1.1.0-2+deb8u1) jessie; urgency=medium
 .
   * Add the fix for https://github.com/relan/exfat/issues/5 found
 and reported by The Fuzzing Project. Check sector and cluster size.
   * Add the fix for https://github.com/relan/exfat/issues/6 found
 and reported by The Fuzzing Project. Detect infinite loop.


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

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)
diff -u fuse-exfat-1.1.0/debian/changelog fuse-exfat-1.1.0/debian/changelog
--- fuse-exfat-1.1.0/debian/changelog
+++ fuse-exfat-1.1.0/debian/changelog
@@ -1,3 +1,12 @@
+fuse-exfat (1.1.0-2+deb8u1) jessie; urgency=medium
+
+  * Add the fix for https://github.com/relan/exfat/issues/5 found
+and reported by The Fuzzing Project. Check sector and cluster size.
+  * Add the fix for https://github.com/relan/exfat/issues/6 found
+and reported by The Fuzzing Project. Detect infinite loop. 
+
+ -- Sven Hoexter <hoex...@debian.org>  Fri, 06 Nov 2015 08:08:13 +0100
+
 fuse-exfat (1.1.0-2) unstable; urgency=low
 
   * Remove debian/watch - recent changes at Google code required
diff -u fuse-exfat-1.1.0/debian/gbp.conf fuse-exfat-1.1.0/debian/gbp.conf
--- fuse-exfat-1.1.0/debian/gbp.conf
+++ fuse-exfat-1.1.0/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = jessie-updates
only in patch2:
unchanged:
--- fuse-exfat-1.1.0.orig/libexfat/mount.c
+++ fuse-exfat-1.1.0/libexfat/mount.c
@@ -30,23 +30,32 @@
 
 static uint64_t rootdir_size(const struct exfat* ef)
 {
-	uint64_t clusters = 0;
+	uint32_t clusters = 0;
+	uint32_t clusters_max = le32_to_cpu(ef->sb->cluster_count);
 	cluster_t rootdir_cluster = le32_to_cpu(ef->sb->rootdir_cluster);
 
-	while (!CLUSTER_INVALID(rootdir_cluster))
+	/* Iterate all clusters of the root directory to calculate its size.
+	   It can't be contiguous because there is no flag to indicate this. */
+	do
 	{
-		clusters++;
-		/* root directory cannot be contiguous because there is no flag
-		   to indicate this */
+		if (clusters == clusters_max) /* infinite loop detected */
+		{
+			exfat_error("root directory cannot occupy all %d clusters",
+	clusters);
+			return 0;
+		}
+		if (CLUSTER_INVALID(rootdir_cluster))
+		{
+			exfat_error("bad cluster %#x while reading root directory",
+	rootdir_cluster);
+			return 0;
+		}
 		rootdir_cluster = exfat_next_cluster(ef, ef->root, rootdir_cluster);
+		clusters++;
 	}
-	if (rootdir_cluster != EXFAT_CLUSTER_END)
-	{
-		exfat_error("bad cluster %#x while reading root directory",
-rootdir_cluster);
-		return 0;
-	}
-	return clusters * CLUSTER_SIZE(*ef->sb);
+	while (rootdir_cluster != EXFAT_CLUSTER_END);
+
+	return (uint64_t) clusters * CLUSTER_SIZE(*ef->sb);
 }
 
 static const char* get_option(const char* options, const char* option_name)
@@ -208,6 +217,23 @@
 		exfat_error("exFAT file system is not found");
 		return -EIO;
 	}
+	/* sector cannot be smaller than 512 bytes */
+	if (ef->sb->sector_bits < 9)
+	{
+		exfat_close(ef->dev);
+		exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
+		free(ef->sb);
+		return -EIO;
+	}
+	/* officially exFAT supports cluster size up to 32 MB */
+	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+	{
+		exfat_close(ef->dev);
+		exfat_error("too big cluster size: 2^(%hhd+%hhd)",
+ef->sb->sector_bits, ef->sb->spc_bits);
+		free(ef->sb);
+		return -EIO;
+	}
 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
 	if (ef->zero_cluster == NULL)
 	{
@@ -242,16 +268,6 @@
 		free(ef->sb);
 		return -EIO;
 	}
-	/* officially exFAT supports cluster size up to 32 MB */
-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
-	{
-		free(ef->zero_cluster);
-		exfat_close(ef->dev);
-		exfat_error("too big cluster size: 2^%d",
-(int) ef->sb->sector_bits + (int) ef->sb->spc_bits);
-		free(ef->sb);
-		return -EIO;
-	}
 	if (le64_to_cpu(ef->sb->sector_count) * SECTOR_SIZE(*ef->sb) >
 			exfat_get_size(ef->dev))
 	{

Bug#803387: wheezy-pu: package exfat-utils/0.9.7-2+deb7u1

[Sven Hoexter]

On Fri, Oct 30, 2015 at 04:51:57PM +, Adam D. Barratt wrote:

Hello Adam,

> Please go ahead.

Uploaded.

Regards,
Sven

Bug#803362: jessie-pu: package exfat-utils/1.1.0-2+deb8u1

[Sven Hoexter]

On Thu, Oct 29, 2015 at 06:28:39PM +, Julien Cristau wrote:

Hi,

> The more obvious way is to not change the source format and not add quilt.

Ok I thought it would be a slightly better choice to avoid the old school
big diff.gz but since I've it as git commits at my end I'm fine.

So here's the changelog and the new debdiff:


 exfat-utils (1.1.0-2+deb8u1) jessie; urgency=medium
 .
   * Add the fix for https://github.com/relan/exfat/issues/5 found
 and reported by The Fuzzing Project. Check sector and cluster size.
   * Add the fix for https://github.com/relan/exfat/issues/6 found
 and reported by The Fuzzing Project. Detect infinite loop.



Sven
diff -u exfat-utils-1.1.0/debian/changelog exfat-utils-1.1.0/debian/changelog
--- exfat-utils-1.1.0/debian/changelog
+++ exfat-utils-1.1.0/debian/changelog
@@ -1,3 +1,12 @@
+exfat-utils (1.1.0-2+deb8u1) jessie; urgency=medium
+
+  * Add the fix for https://github.com/relan/exfat/issues/5 found
+and reported by The Fuzzing Project. Check sector and cluster size.
+  * Add the fix for https://github.com/relan/exfat/issues/6 found
+and reported by The Fuzzing Project. Detect infinite loop. 
+
+ -- Sven Hoexter <hoex...@debian.org>  Fri, 30 Oct 2015 10:28:28 +0100
+
 exfat-utils (1.1.0-2) unstable; urgency=low
 
   * Remove debian/watch - recent changes at Google code required
diff -u exfat-utils-1.1.0/debian/gbp.conf exfat-utils-1.1.0/debian/gbp.conf
--- exfat-utils-1.1.0/debian/gbp.conf
+++ exfat-utils-1.1.0/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = jessie-updates
only in patch2:
unchanged:
--- exfat-utils-1.1.0.orig/libexfat/mount.c
+++ exfat-utils-1.1.0/libexfat/mount.c
@@ -30,23 +30,32 @@
 
 static uint64_t rootdir_size(const struct exfat* ef)
 {
-	uint64_t clusters = 0;
+	uint32_t clusters = 0;
+	uint32_t clusters_max = le32_to_cpu(ef->sb->cluster_count);
 	cluster_t rootdir_cluster = le32_to_cpu(ef->sb->rootdir_cluster);
 
-	while (!CLUSTER_INVALID(rootdir_cluster))
+	/* Iterate all clusters of the root directory to calculate its size.
+	   It can't be contiguous because there is no flag to indicate this. */
+	do
 	{
-		clusters++;
-		/* root directory cannot be contiguous because there is no flag
-		   to indicate this */
+		if (clusters == clusters_max) /* infinite loop detected */
+		{
+			exfat_error("root directory cannot occupy all %d clusters",
+	clusters);
+			return 0;
+		}
+		if (CLUSTER_INVALID(rootdir_cluster))
+		{
+			exfat_error("bad cluster %#x while reading root directory",
+	rootdir_cluster);
+			return 0;
+		}
 		rootdir_cluster = exfat_next_cluster(ef, ef->root, rootdir_cluster);
+		clusters++;
 	}
-	if (rootdir_cluster != EXFAT_CLUSTER_END)
-	{
-		exfat_error("bad cluster %#x while reading root directory",
-rootdir_cluster);
-		return 0;
-	}
-	return clusters * CLUSTER_SIZE(*ef->sb);
+	while (rootdir_cluster != EXFAT_CLUSTER_END);
+
+	return (uint64_t) clusters * CLUSTER_SIZE(*ef->sb);
 }
 
 static const char* get_option(const char* options, const char* option_name)
@@ -208,6 +217,23 @@
 		exfat_error("exFAT file system is not found");
 		return -EIO;
 	}
+	/* sector cannot be smaller than 512 bytes */
+	if (ef->sb->sector_bits < 9)
+	{
+		exfat_close(ef->dev);
+		exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
+		free(ef->sb);
+		return -EIO;
+	}
+	/* officially exFAT supports cluster size up to 32 MB */
+	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+	{
+		exfat_close(ef->dev);
+		exfat_error("too big cluster size: 2^(%hhd+%hhd)",
+ef->sb->sector_bits, ef->sb->spc_bits);
+		free(ef->sb);
+		return -EIO;
+	}
 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
 	if (ef->zero_cluster == NULL)
 	{
@@ -242,16 +268,6 @@
 		free(ef->sb);
 		return -EIO;
 	}
-	/* officially exFAT supports cluster size up to 32 MB */
-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
-	{
-		free(ef->zero_cluster);
-		exfat_close(ef->dev);
-		exfat_error("too big cluster size: 2^%d",
-(int) ef->sb->sector_bits + (int) ef->sb->spc_bits);
-		free(ef->sb);
-		return -EIO;
-	}
 	if (le64_to_cpu(ef->sb->sector_count) * SECTOR_SIZE(*ef->sb) >
 			exfat_get_size(ef->dev))
 	{

Bug#803362: jessie-pu: package exfat-utils/1.1.0-2+deb8u1

[Sven Hoexter]

On Fri, Oct 30, 2015 at 02:22:45PM +, Adam D. Barratt wrote:

Hi,

> [I also note with a little amusement that the version of exfat-utils in
> wheezy appears to have been the only revision of the package ever to
> have had an explicit patch system (not counting the change to "3.0
> (quilt)".]

I added and droped it whenever patching was required or not. Turned out
to be a pain in the ass so that I now moved on to 3.0(quilt).


> Please go ahead; thanks.

Uploaded for jessie. This ack was only for jessie and we handle the wheezy
upload in the other bug, right?

Sven

Bug#803387: wheezy-pu: package exfat-utils/0.9.7-2+deb7u1

[Sven Hoexter]

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

Hi,
The Fuzzing Project found two issues in the exfat-utils package and the security
team asked me to fix them via a stable update.

exfat-utils (0.9.7-2+deb7u1) wheezy; urgency=medium

  * Add d/patches/check-sector-and-cluster-size. Fix for
https://github.com/relan/exfat/issues/5 found and reported by
The Fuzzing Project.
  * Add d/patches/detect-infinite-loop. Fix for
https://github.com/relan/exfat/issues/6 found and reported by
The Fuzzing Project.

 -- Sven Hoexter <hoex...@debian.org>  Thu, 29 Oct 2015 12:37:48 +0100

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

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)
diff -u exfat-utils-0.9.7/debian/gbp.conf exfat-utils-0.9.7/debian/gbp.conf
--- exfat-utils-0.9.7/debian/gbp.conf
+++ exfat-utils-0.9.7/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = wheezy-updates
diff -u exfat-utils-0.9.7/debian/changelog exfat-utils-0.9.7/debian/changelog
--- exfat-utils-0.9.7/debian/changelog
+++ exfat-utils-0.9.7/debian/changelog
@@ -1,3 +1,14 @@
+exfat-utils (0.9.7-2+deb7u1) wheezy; urgency=medium
+
+  * Add d/patches/check-sector-and-cluster-size. Fix for
+https://github.com/relan/exfat/issues/5 found and reported by
+The Fuzzing Project.
+  * Add d/patches/detect-infinite-loop. Fix for
+https://github.com/relan/exfat/issues/6 found and reported by
+The Fuzzing Project.
+
+ -- Sven Hoexter <hoex...@debian.org>  Thu, 29 Oct 2015 12:37:48 +0100
+
 exfat-utils (0.9.7-2) unstable; urgency=low
 
   * Move manual link creation from debian/rules to debian/links
diff -u exfat-utils-0.9.7/debian/patches/series exfat-utils-0.9.7/debian/patches/series
--- exfat-utils-0.9.7/debian/patches/series
+++ exfat-utils-0.9.7/debian/patches/series
@@ -2,0 +3,2 @@
+check-sector-and-cluster-size
+detect-infinite-loop
only in patch2:
unchanged:
--- exfat-utils-0.9.7.orig/debian/patches/check-sector-and-cluster-size
+++ exfat-utils-0.9.7/debian/patches/check-sector-and-cluster-size
@@ -0,0 +1,49 @@
+Patch for https://github.com/relan/exfat/issues/5
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -172,6 +172,24 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("exFAT file system is not found");
+ 		return -EIO;
+ 	}
++	/* sector cannot be smaller than 512 bytes */
++if (ef->sb->sector_bits < 9)
++{
++exfat_close(ef->dev);
++exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
++free(ef->sb);
++return -EIO;
++}
++/* officially exFAT supports cluster size up to 32 MB */
++if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
++{
++exfat_close(ef->dev);
++exfat_error("too big cluster size: 2^(%hhd+%hhd)",
++ef->sb->sector_bits, ef->sb->spc_bits);
++free(ef->sb);
++return -EIO;
++}
++
+ 	if (ef->sb->version.major != 1 || ef->sb->version.minor != 0)
+ 	{
+ 		exfat_close(ef->dev);
+@@ -187,16 +205,6 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("unsupported FAT count: %hhu", ef->sb->fat_count);
+ 		return -EIO;
+ 	}
+-	/* officially exFAT supports cluster size up to 32 MB */
+-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+-	{
+-		exfat_close(ef->dev);
+-		free(ef->sb);
+-		exfat_error("too big cluster size: 2^%d",
+-(int) ef->sb->sector_bits + (int) ef->sb->spc_bits);
+-		return -EIO;
+-	}
+-
+ 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
+ 	if (ef->zero_cluster == NULL)
+ 	{
only in patch2:
unchanged:
--- exfat-utils-0.9.7.orig/debian/patches/detect-infinite-loop
+++ exfat-utils-0.9.7/debian/patches/detect-infinite-loop
@@ -0,0 +1,48 @@
+Patch for https://github.com/relan/exfat/issues/6
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -27,17 +27,32 @@
+ 
+ static uint64_t rootdir_size(const struct exfat* ef)
+ {
+-	uint64_t clusters = 0;
++  

Bug#803362: jessie-pu: package exfat-utils/1.1.0-2+deb8u1

[Sven Hoexter]

On Thu, Oct 29, 2015 at 03:01:09PM +, Adam D. Barratt wrote:
> On 2015-10-29 8:57, Sven Hoexter wrote:

Hi Adam,

> >  * Add quilt to build-deps.
> >  * Add --with quilt to dh invocation in d/rules.
> 
> Why is that being suggested for the jessie update but not the equivalent
> wheezy update? (For completeness we're generally not in favour of adding
> patch systems in stable updates.)

Because the jessie package is source format 1.0 without a patch system ATM.
I thought adding quilt again is less invasive then changing the source format.
For the package in unstable I already opted to use source format 3.0(quilt).


> >  * Add d/patches/check-sector-and-cluster-size. Fix for
> >https://github.com/relan/exfat/issues/5 found and reported by
> >The Fuzzing Project.
> >  * Add d/patches/detect-infinite-loop. Fix for
> >https://github.com/relan/exfat/issues/6 found and reported by
> >The Fuzzing Project.
> 
> Are both of these issues resolved in (or not relevant to) unstable?

They're already fixed in 1.2.1 which is part of unstable and testing.

Sven

Bug#803362: jessie-pu: package exfat-utils/1.1.0-2+deb8u1

[Sven Hoexter]

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

Hi,
The Fuzzing Project found two issues in the exfat-utils package and the security
team asked me to fix them via a stable update.

Changelog:
exfat-utils (1.1.0-2+deb8u1) jessie; urgency=medium

  * Add quilt to build-deps.
  * Add --with quilt to dh invocation in d/rules.
  * Add d/patches/check-sector-and-cluster-size. Fix for
https://github.com/relan/exfat/issues/5 found and reported by
The Fuzzing Project.
  * Add d/patches/detect-infinite-loop. Fix for
https://github.com/relan/exfat/issues/6 found and reported by
The Fuzzing Project.

 -- Sven Hoexter <hoex...@debian.org>  Thu, 29 Oct 2015 09:40:20 +0100

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

Kernel: Linux 3.16.0-4-amd64 (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
Init: systemd (via /run/systemd/system)
diff -u exfat-utils-1.1.0/debian/changelog exfat-utils-1.1.0/debian/changelog
--- exfat-utils-1.1.0/debian/changelog
+++ exfat-utils-1.1.0/debian/changelog
@@ -1,3 +1,16 @@
+exfat-utils (1.1.0-2+deb8u1) jessie; urgency=medium
+
+  * Add quilt to build-deps.
+  * Add --with quilt to dh invocation in d/rules.
+  * Add d/patches/check-sector-and-cluster-size. Fix for
+https://github.com/relan/exfat/issues/5 found and reported by
+The Fuzzing Project.
+  * Add d/patches/detect-infinite-loop. Fix for
+https://github.com/relan/exfat/issues/6 found and reported by
+The Fuzzing Project.
+
+ -- Sven Hoexter <hoex...@debian.org>  Thu, 29 Oct 2015 09:40:20 +0100
+
 exfat-utils (1.1.0-2) unstable; urgency=low
 
   * Remove debian/watch - recent changes at Google code required
diff -u exfat-utils-1.1.0/debian/control exfat-utils-1.1.0/debian/control
--- exfat-utils-1.1.0/debian/control
+++ exfat-utils-1.1.0/debian/control
@@ -2,7 +2,7 @@
 Section: otherosfs
 Priority: optional
 Maintainer: Sven Hoexter <hoex...@debian.org>
-Build-Depends: debhelper (>= 9), scons
+Build-Depends: debhelper (>= 9), scons, quilt
 Standards-Version: 3.9.5
 Homepage: http://code.google.com/p/exfat/
 Vcs-Git: git://git.sven.stormbind.net/git/sven/exfat-utils.git
diff -u exfat-utils-1.1.0/debian/gbp.conf exfat-utils-1.1.0/debian/gbp.conf
--- exfat-utils-1.1.0/debian/gbp.conf
+++ exfat-utils-1.1.0/debian/gbp.conf
@@ -2,0 +3 @@
+debian-branch = jessie-updates
diff -u exfat-utils-1.1.0/debian/rules exfat-utils-1.1.0/debian/rules
--- exfat-utils-1.1.0/debian/rules
+++ exfat-utils-1.1.0/debian/rules
@@ -6,7 +6,7 @@
 export CCFLAGS = $(CFLAGS) -Wall -std=c99 -D_GNU_SOURCE
 
 %:
-	dh $@
+	dh $@ --with quilt
 
 override_dh_auto_build:
 	scons
only in patch2:
unchanged:
--- exfat-utils-1.1.0.orig/debian/README.source
+++ exfat-utils-1.1.0/debian/README.source
@@ -0,0 +1,5 @@
+This package uses quilt to manage the patches in debian/patches.
+For further information please install the quilt package and read
+/usr/share/doc/quilt/README.source.
+
+ -- sven <sven@shoexter.internal>, Thu, 29 Oct 2015 09:05:34 +0100
only in patch2:
unchanged:
--- exfat-utils-1.1.0.orig/debian/patches/check-sector-and-cluster-size
+++ exfat-utils-1.1.0/debian/patches/check-sector-and-cluster-size
@@ -0,0 +1,48 @@
+Patch for https://github.com/relan/exfat/issues/5
+See also:
+https://blog.fuzzing-project.org/25-Heap-overflow-and-endless-loop-in-exfatfsck-exfat-utils.html
+Index: exfat-utils/libexfat/mount.c
+===
+--- exfat-utils.orig/libexfat/mount.c
 exfat-utils/libexfat/mount.c
+@@ -208,6 +208,23 @@ int exfat_mount(struct exfat* ef, const
+ 		exfat_error("exFAT file system is not found");
+ 		return -EIO;
+ 	}
++	/* sector cannot be smaller than 512 bytes */
++	if (ef->sb->sector_bits < 9)
++	{
++		exfat_close(ef->dev);
++		exfat_error("too small sector size: 2^%hhd", ef->sb->sector_bits);
++		free(ef->sb);
++		return -EIO;
++	}
++	/* officially exFAT supports cluster size up to 32 MB */
++	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
++	{
++		exfat_close(ef->dev);
++		exfat_error("too big cluster size: 2^(%hhd+%hhd)",
++ef->sb->sector_bits, ef->sb->spc_bits);
++		free(ef->sb);
++		return -EIO;
++	}
+ 	ef->zero_cluster = malloc(CLUSTER_SIZE(*ef->sb));
+ 	if (ef->zero_cluster == NULL)
+ 	{
+@@ -242,16 +259,6 @@ int exfat_mount(struct exfat* ef, const
+ 		free(ef->sb);
+ 		return -EIO;
+ 	}
+-	/* officially exFAT supports cluster size up to 32 MB */
+-	if ((int) ef->sb->sector_bits + (int) ef->sb->spc_bits > 25)
+-	{
+-		free(ef->zero_cluster);
+-		exfat_close(ef->dev);
+-		exfat_error("too big cluster size: 2^%d",

Bug#801734: tclcurl: file output lost if -file option is used

[Sven Hoexter]

Thanks Christian. Full quote for Steve - maybe something for you
to look into?

Sven


On Sat, Oct 17, 2015 at 03:04:17PM +0200, Christian Werner wrote:
> The following patch from www.androwish.org should fix this issue
> 
>
> https://www.androwish.org/index.html/vpatch?from=9afc8918cdeec6d7=e4864fde820aac71
> 
> Hopefully tclcurl will remain in Debian.
> 
> Regards,
> Christian Werner

Bug#719441: tclcurl: Segmentation Fault when writeheader and headervar are used

[Sven Hoexter]

On Sat, Oct 17, 2015 at 10:27:49PM +0200, Christian Werner wrote:
> The following patch from www.androwish.org should fix this issue
> 
>
> https://www.androwish.org/index.html/vpatch?from=e4864fde820aac71=ce9a5b5886ac7381

Christian, thanks a lot! I'm currently preparing an upload based on Steves
hg repo + your patches.

Sven

Bug#801734: tclcurl: file output lost if -file option is used

[Sven Hoexter]

On Wed, Oct 14, 2015 at 01:58:13AM +0200, Nomen Nescio wrote:

Hi,

> This is similar to (unfixed) bug 680662 (from 3 yrs ago), but much
> more severe.  When the "-file" option is used for a GET, the file will
> be zero in size with all data lost if the -bodyvar option is used in a
> later transaction.

I haven't used the module for more then 5 years and could always get along
with the Tcl http module for my own needs. So I now consider to remove it
from Debian. While someone started to adopt it upstream there is no real
activity and I'm not inclined at the moment to start to work on it myself.

So I guess removal from Debian is the better option for now.

Sven