Bug#900089: [zfs-dkms]
On 05/29/2018 04:14 PM, Antonio Russo wrote:
> Control: severity -1 wishlist
>
> I think everyone can agree this is at most a wishlist bug.
>
> I also agree that making Debian packaging easier for others in the greater
> Debian ecosystem would be nice.
>
> However, your point of contact for a build issue on another distribution
> should be that distribution's bugtracker. Not filing grave bugs without
> first confirming they affect that distribution.
>
My apologies for making this grave bug. I've been building the zfs packages
for upwards of two years now for the sysvinit bug and never had Debian
specific check before.
When I saw the https://github.com/zfsonlinux/zfs/issues/7540 bug where
Serphentas said it had the error on Stretch, I thought it was affecting Debian
and Debian based systems.
I saw the fix in git master, but I still don't see the reason why lsb_release
is used as the test to determine where the kernel source is. There must be a
better way to test this when using lsb_release.
I've attached a better looking patch that removes the lsb_release check. I'm
not sure why the other one looked so ugly when I used quilt before.
--- a/debian/zfs-dkms/usr/src/zfs-0.7.9/dkms.conf
+++ b/debian/zfs-dkms/usr/src/zfs-0.7.9/dkms.conf
@@ -6,8 +6,6 @@
--prefix=/usr
--with-config=kernel
--with-linux=$(
-case `lsb_release -is` in
- (Debian)
if [[ -e ${kernel_source_dir/%build/source} ]]
then
echo ${kernel_source_dir/%build/source}
@@ -15,11 +13,6 @@
# A kpkg exception for Proxmox 2.0
echo ${kernel_source_dir}
fi
- ;;
- (*)
-echo ${kernel_source_dir}
- ;;
-esac
)
--with-linux-obj=${kernel_source_dir}
--with-spl=${source_tree}/spl-${PACKAGE_VERSION}
--- a/debian/zfs-dkms.dkms.debhelper
+++ b/debian/zfs-dkms.dkms.debhelper
@@ -6,8 +6,6 @@
--prefix=/usr
--with-config=kernel
--with-linux=$(
-case `lsb_release -is` in
- (Debian)
if [[ -e ${kernel_source_dir/%build/source} ]]
then
echo ${kernel_source_dir/%build/source}
@@ -15,11 +13,6 @@
# A kpkg exception for Proxmox 2.0
echo ${kernel_source_dir}
fi
- ;;
- (*)
-echo ${kernel_source_dir}
- ;;
-esac
)
--with-linux-obj=${kernel_source_dir}
--with-spl=${source_tree}/spl-${PACKAGE_VERSION}
--- a/debian/zfs-dkms.dkms
+++ b/debian/zfs-dkms.dkms
@@ -6,8 +6,6 @@
--prefix=/usr
--with-config=kernel
--with-linux=$(
-case `lsb_release -is` in
- (Debian)
if [[ -e ${kernel_source_dir/%build/source} ]]
then
echo ${kernel_source_dir/%build/source}
@@ -15,11 +13,6 @@
# A kpkg exception for Proxmox 2.0
echo ${kernel_source_dir}
fi
- ;;
- (*)
-echo ${kernel_source_dir}
- ;;
-esac
)
--with-linux-obj=${kernel_source_dir}
--with-spl=${source_tree}/spl-${PACKAGE_VERSION}
Bug#900389: RFS: deepin-screen-recorder/2.7.4-1
On Fri 06/01 23:37, Adam Borowski wrote: > I'm afraid that depending on libprocps6 is a pretty bad idea. It's produced > by src:procps, and the version in unstable already builds libprocps7 rather > than libprocps6. It will migrate soon, thus breaking your package. > > As #900239 is an ex-bug, you can revert this particular change. Fixed it, please check again. -- Yanhao Mo signature.asc Description: PGP signature
Bug#900237: libuv1: FTBFS on hppa: not ok 46 - fs_copyfile
On 02.06.2018 17:01, John David Anglin wrote:
> On 2018-06-02 4:35 AM, Dominique Dumont wrote:
>> On Sun, 27 May 2018 17:35:40 -0400 John David Anglin
>> wrote:
>>> The value of r in the failing assertion is -233. If the value is a standard
>>> errno, it is ENOBUFS.
No.
The value of r in the failing assertion is -223, which is -EOPNOTSUPP.
# r is -223UV_ENOTSUP=-252 and EOPNOTSUPP=-223
> The test used to pass with 1.18.0, so the problem appears to be a regression
> in libuv1. I would
> guess that the failure was introduced by the following change:
> https://github.com/libuv/libuv/commit/3ae88200d6f52ea7b3d8ff9b8164adde65f6c43a
>
> The failure line corresponds to this addition.
>
> The change mentions that an error will be returned if the platform doesn't
> support copy-on-write.
> I tend to think there's an issue with the error codes either in the kernel or
> libuv1. I doubt we are
> actually running out of memory.
The problem is, that on parisc ENOTSUP and EOPNOTSUPP have different values,
which breaks the checks.
Other arches, e.g. x86-64 seem to have the same value for both, so there the
check doesn't break.
test-fs-copyfile.c checks for UV_ENOTSUP (which is ENOTSUP), while in
src/unix/fs.c is checked against "errno != EOPNOTSUPP".
This needs to be fixed in libuv1.
The attached patch is just a workaround.
Helge
diff -up ./test/test-fs-copyfile.c.bak ./test/test-fs-copyfile.c
--- ./test/test-fs-copyfile.c.bak 2018-06-03 15:35:58.670414404 +0200
+++ ./test/test-fs-copyfile.c 2018-06-03 16:07:44.681343894 +0200
@@ -180,7 +180,7 @@ TEST_IMPL(fs_copyfile) {
r = uv_fs_copyfile(NULL, , fixture, dst, UV_FS_COPYFILE_FICLONE_FORCE,
NULL);
fprintf(stderr, "r is now %d\n",r );
- ASSERT(r == 0 || r == UV_ENOSYS || r == UV_ENOTSUP || r == UV_ENOTTY);
+ ASSERT(r == 0 || r == UV_ENOSYS || r == UV_ENOTSUP || r == -EOPNOTSUPP || r
== UV_ENOTTY);
if (r == 0)
handle_result();
Bug#900689: ITP: octave-vibes -- VIBes API to easily display results in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-vibes Version : 0.2.0 Upstream Author : Oliver Heimlich * URL : https://octave.sourceforge.io/vibes/ * License : GPL-3+ Programming Lang: C++, Octave Description : VIBes API to easily display results in Octave The VIBes API allows one to easily display results (boxes, pavings) from interval methods. VIBes consists in two parts: (1) the VIBes application that features viewing, annotating and exporting figures, and (2) the VIBes API that enables your program to communicate with the viewer in order to draw figures. This package integrates the VIBes API into Octave. The VIBes application is required for operation and must be installed separately. Data types from third-party interval arithmetic libraries for Octave are also supported. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-vibes.git
Bug#900688: live-tools: Needs to be adjusted to live-boot's new mountpoints
Package: live-tools Version: 1:20171207 Severity: normal X-Debbugs-Cc: benjamin.dr...@profitbricks.com User: tails-...@boum.org Usertags: for-buster Hi! since 1:20180328 live-boot uses /run/live instead of /lib/live/mount (#886328). But at least 5 scripts shipped in live-tools still use the old paths. I did not test what's the exact impact yet but I suspect it breaks some of live-tools functionality. Cheers, -- intrigeri
Bug#831548: [Pkg-javascript-devel] Bug#831548: RM: mtasc -- ROM; obsoleted by newer standard web technologies
Hi, On Sat, Jun 2, 2018 at 9:10 AM, Bastien ROUCARIES wrote: > > > Le sam. 2 juin 2018 à 08:59, Niels Thykier a écrit : >> >> On Sat, 23 Dec 2017 06:58:52 +0800 Paul Wise wrote: >> > Control: severity -1 serious >> > Control: severity 831553 normal >> > >> > Hi everyone, >> > >> > The buster cycle is the right time to remove mtasc from the Debian >> > archive. It has been unmaintained in Debian and upstream for years. The >> > web ecosystem is moving away from Flash towards standard web tech, >> > which can now replace most use of Flash. Debian should encourage our >> > upstreams to move towards standard web tech like HTML5 and JavaScript. >> > >> > Please talk to your upstreams about transitioning away from >> > ActionScript 2 towards HTML5 JavaScript. If they need to still >> > support Flash for some users, then they should switch to something >> > like Haxe but they should not build Flash files by default. >> > >> > On Fri, 22 Dec 2017 17:29:50 -0500 Scott Kitterman wrote: >> > >> > > 15 months later all but one of those bugs is still open. Can you >> > > either work >> > > with the maintainers to get them done or close this request until it's >> > > ripe >> > > for processing. >> > >> > -- >> > bye, >> > pabs >> > >> > https://wiki.debian.org/PaulWise >> >> Hi, >> >> This package (dojo) is officially maintained by the Javascript team but >> appears to be de facto unmaintained. It has several RC bugs and is >> stalling the removal of obsolete packages (admittedly only from unstable). >> >> If you are still interested in maintaining the package, then please >> resolve the RC bugs (at the very least this bug, which is blocking >> others). If there is no visible progress on resolving this bug in a >> month from now, I will assume you are no longer interested in it and >> that you will support a removal of dojo from unstable. >> >> I have explicitly included all listed maintainers and uploaders (except >> for Frank, which appears to have disclaimed interest in this package per >> #863693) >> >> Thanks, >> ~Niels I needed to merge shrinksafe back in dojo (upstream merge). I have modified the control file and will upload ASAP. Could you check if my merge is right (particularly d/control breaks/replaces). Repo is here https://salsa.debian.org/js-team/dojo Bastien > > Will get a glimpse. > > BTw it means that a few lintian warning are now fatal because ftbfs... > > Bastien >> >> >> -- >> Pkg-javascript-devel mailing list >> pkg-javascript-de...@alioth-lists.debian.net >> >> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel > > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#900687: guake: Localization files does not exist in .deb package
Package: guake Version: 3.2.2-1 Severity: important Hi, .po files exists in source package, but there is no localization files in the .deb package.
Bug#884448: [Pkg-javascript-devel] where is the repo for node-insert-module-globals ?
On Sat, Jun 2, 2018 at 12:50 PM, Paolo Greppi wrote: > Hi, > > there is an upload for this package sitting in the NEW queue for some time: > https://ftp-master.debian.org/new/node-insert-module-globals_7.0.1-1.html > > It lists the Debian Javascript Maintainers team as the maintainer, but there > is no repo on salsa (and the repos listed in the Vcs-Browser and Vcs-Git > fields > are gone since the demise of alioth). > > Please either: > > 1) ask ftp-master to REJECT the package if you have list the repo and/or the >interest > > 2) or create a repo on salsa, and update the package by uploading a newer >version to NEW with the correct Vcs-Browser and Vcs-Git fields. I usually create "public" repo after review of tpmaster. (avoid some license problem) Now that salsa allow private repo (shared will team) will reup > > Thanks, > > Paolo > > -- > Pkg-javascript-devel mailing list > pkg-javascript-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Bug#826994: Patch updated for 0.7.9-3
I've updated the patch for 0.7.9-3 thought there where no changes that prevented the last patch from working. Please commit the patch to enable sysvinit for ZFS. diff -Nru zfs-linux-0.7.9/debian/changelog zfs-linux-0.7.9/debian/changelog --- zfs-linux-0.7.9/debian/changelog 2018-05-28 04:22:02.0 -0600 +++ zfs-linux-0.7.9/debian/changelog 2018-06-03 07:12:43.0 -0600 @@ -1,3 +1,10 @@ +zfs-linux (0.7.9-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Add sysvinit scripts. + + -- Chris Dos Sun, 03 Jun 2018 07:12:43 -0600 + zfs-linux (0.7.9-3) unstable; urgency=medium [ Antonio Russo ] diff -Nru zfs-linux-0.7.9/debian/patches/1004-zed-service-bindir.patch zfs-linux-0.7.9/debian/patches/1004-zed-service-bindir.patch --- zfs-linux-0.7.9/debian/patches/1004-zed-service-bindir.patch 2018-05-16 07:38:12.0 -0600 +++ zfs-linux-0.7.9/debian/patches/1004-zed-service-bindir.patch 2018-06-03 07:08:42.0 -0600 @@ -1,11 +1,14 @@ -Description: Fix the path to the zed binary on the systemd unit. +Description: Fix the path to the zed binary on the systemd unit and + the sysvinit script. We install zed into /usr/sbin manually meanwhile the upstream default is installing it into /sbin. Ubuntu packages also install zed to /usr/sbin, but they ship their own zfs-zed unit. Author: Carlos Alberto Lopez Author: Fabian Grünbichler +Author: Chris Dos Bug-Debian: https://bugs.debian.org/849813 +Bug-Debian: https://bugs.debian.org/826994 Forwarded: no --- a/etc/systemd/system/zfs-zed.service.in +++ b/etc/systemd/system/zfs-zed.service.in @@ -18,3 +21,13 @@ Restart=on-abort [Install] +--- a/etc/init.d/zfs-functions.in b/etc/init.d/zfs-functions.in +@@ -89,7 +89,7 @@ + + # Paths to what we need + ZFS="@sbindir@/zfs" +-ZED="@sbindir@/zed" ++ZED="/usr/sbin/zed" + ZPOOL="@sbindir@/zpool" + ZPOOL_CACHE="@sysconfdir@/zfs/zpool.cache" diff -Nru zfs-linux-0.7.9/debian/rules zfs-linux-0.7.9/debian/rules --- zfs-linux-0.7.9/debian/rules 2018-05-17 10:11:36.0 -0600 +++ zfs-linux-0.7.9/debian/rules 2018-06-03 07:10:41.0 -0600 @@ -114,6 +114,26 @@ chmod a-x $(CURDIR)/debian/tmp/etc/zfs/zfs-functions chmod a-x $(CURDIR)/debian/tmp/etc/default/zfs +override_dh_installinit: + @# Install the /etc/init.d/zfs-import script. + dh_installinit -pzfsutils-linux --name=zfs-import \ + --no-restart-on-upgrade --no-start + + @# Install the /etc/init.d/zfs-mount script. + dh_installinit -pzfsutils-linux --name=zfs-mount \ + --no-restart-on-upgrade --no-start + + @# Install the /etc/init.d/zfs-share script. + dh_installinit -pzfsutils-linux --name=zfs-share \ + --no-restart-on-upgrade --no-start + + @# Add a dummy (link to /dev/null) for zfs-import.service + ln -s /dev/null $(CURDIR)/debian/zfsutils-linux/lib/systemd/system/zfs-import.service + + @# Install the ZED init file. + dh_installinit -pzfs-zed --name=zfs-zed \ + --no-restart-on-upgrade --no-start + override_dh_dkms: dh_dkms -V $(DEB_VERSION_UPSTREAM) diff -Nru zfs-linux-0.7.9/debian/zfsutils-linux.install zfs-linux-0.7.9/debian/zfsutils-linux.install --- zfs-linux-0.7.9/debian/zfsutils-linux.install 2018-05-28 04:07:08.0 -0600 +++ zfs-linux-0.7.9/debian/zfsutils-linux.install 2018-06-03 07:10:41.0 -0600 @@ -1,6 +1,8 @@ ../tree/zfsutils-linux/* / etc/default/zfs etc/zfs/zfs-functions +etc/init.d/zfs-import +etc/init.d/zfs-mount etc/zfs/zpool.d/ lib/systemd/system-preset/ lib/systemd/system/zfs-import-cache.service diff -Nru zfs-linux-0.7.9/debian/zfs-zed.install zfs-linux-0.7.9/debian/zfs-zed.install --- zfs-linux-0.7.9/debian/zfs-zed.install 2018-05-16 07:38:12.0 -0600 +++ zfs-linux-0.7.9/debian/zfs-zed.install 2018-06-03 07:10:41.0 -0600 @@ -1,4 +1,6 @@ etc/zfs/zed.d/* +etc/init.d/zfs-zed +etc/init.d/zfs-share lib/systemd/system/zfs-zed.service usr/lib/*/zfs/zed.d/* usr/sbin/zed
Bug#900686: mirror submission for mirror.linux.pizza
Package: mirrors Severity: wishlist User: mirr...@packages.debian.org Usertags: mirror-submission Submission-Type: new Site: mirror.linux.pizza Type: leaf Archive-architecture: amd64 hurd-i386 Archive-http: /debian/ Archive-rsync: debian/ Maintainer: Jonathan Selea Country: SE Sweden Trace Url: http://mirror.linux.pizza/debian/project/trace/ Trace Url: http://mirror.linux.pizza/debian/project/trace/ftp-master.debian.org Trace Url: http://mirror.linux.pizza/debian/project/trace/mirror.linux.pizza
Bug#900685: ITP: octave-secs3d -- Drift-Diffusion simulator for 3d semiconductor devices in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-secs3d Version : 0.0.1 Upstream Author : Carlo de Falco * URL : https://octave.sourceforge.io/secs3d/ * License : GPL-2+ Programming Lang: Octave Description : Drift-Diffusion simulator for 3d semiconductor devices in Octave This package provides functions for Drift-Diffusion simulation of 3d semiconductor devices in Octave, a scientific computation software. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-secs3d.git
Bug#900684: ITP: octave-queueing -- Queueing Networks and Markov chains analysis for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-queueing Version : 1.2.5 Upstream Author : Moreno Marzolla * URL : https://octave.sourceforge.io/queueing/ * License : GPL-3+ Programming Lang: Octave Description : Queueing Networks and Markov chains analysis for Octave The queueing package provides functions for queueing networks and Markov chains analysis. This package can be used to compute steady-state performance measures for open, closed and mixed networks with single or multiple job classes. Mean Value Analysis (MVA), convolution, and various bounding techniques are implemented. Furthermore, several transient and steady-state performance measures for Markov chains can be computed, such as state occupancy probabilities, mean time to absorption, time-averaged sojourn times and so forth. Discrete- and continuous-time Markov chains are supported. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-queueing.git
Bug#736898: Bug is back
OK no more errors seen with Version: 1.4.625+0.20180518-2 APT prefers experimental Versions of packages w3m-el-snapshot depends on: ii dpkg 1.19.0.5+b1 ii emacs 1:25.2+1-7 ii emacs-gtk [emacs] 1:25.2+1-7 ii emacsen-common 3.0.0 ii install-info 6.5.0.dfsg.1-3 ii w3m0.5.3-36+b1
Bug#900683: ITP: octave-optics -- optics functions for Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-optics Version : 0.1.3 Upstream Author : Andreas Weber * URL : https://octave.sourceforge.io/optics/ * License : GPL-3+ Programming Lang: Octave Description : optics functions for Octave This package covers various aspects of optics in Octave, a scientific computation software. It contains functions for manipulating Jones, Mueller, and Stokes matrices and for computing Zernike polynomials. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-optics.git
Bug#877855: debootstrap does not carry --components across --foreign/--second-stage
Hi,
On Wed, 21 Mar 2018 18:58:27 +0900 Hideki Yamane wrote:
> Since in debootstrap, $TARGET/etc/apt/sources.list is deleted at
> starting for second stage.
And also it was removed in debootstrap script.
> . "$SCRIPT"
>
> if [ "$SECOND_STAGE_ONLY" = "true" ]; then
> MIRRORS=null:
> else
> MIRRORS="$DEF_MIRROR"
> if [ "$USER_MIRROR" != "" ]; then
> MIRRORS="$USER_MIRROR"
> MIRRORS="${MIRRORS%/}"
> fi
> fi
>
> export MIRRORS
--
Regards,
Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#900469: firefox: Spell checker stopped working after upgrading from version 60 to 61.0~b8
On May 31, Paride Legovini wrote: > After upgrading from firefox 60 to 61.0~b8-1 (experimental), the spell > checker no longer works (all the words are marked as wrong, no > suggestions are given in the context menu). I reproduced this issue on > two different computers. Starting firefox in safe mode doesn't help. Me too. When starting firefox it outputs: error: file:///home/md/.mozilla/firefox/yuvlmd1c.default/extensions/it...@dictionaries.addons.mozilla.org/dictionaries/it_IT.aff: cannot open error: file:///home/md/.mozilla/firefox/yuvlmd1c.default/extensions/it...@dictionaries.addons.mozilla.org/dictionaries/it_IT.dic: cannot open error: file:///home/md/.mozilla/firefox/yuvlmd1c.default/extensions/it...@dictionaries.addons.mozilla.org/dictionaries/it_IT.aff: cannot open The files exist. -- ciao, Marco signature.asc Description: PGP signature
Bug#900586: rsyslog: systemd Service File Update Breaks logrotate
Diff is attached.
Interesting; it looks like I should be using
"/usr/lib/rsyslog/rsyslog-rotate" instead of "invoke-rc.d rsyslog rotate >
/dev/null". I'll try that.
On Sat, Jun 2, 2018 at 12:53 AM, Michael Biebl wrote:
>
> Am 01.06.2018 um 19:47 schrieb Dave Sp:
> > -- Configuration Files:
> > /etc/init.d/rsyslog changed [not included]
> > /etc/logrotate.d/rsyslog changed [not included]
>
> Please send me your modified /etc/logrotate.d/rsyslog
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
>
>
*** rsyslog.8.34.0-1.orig 2018-04-06 14:40:49.0 -0500
--- rsyslog 2018-04-04 06:11:56.823040263 -0500
***
*** 1,13
/var/log/syslog
{
! rotate 7
! daily
missingok
notifempty
delaycompress
compress
postrotate
! /usr/lib/rsyslog/rsyslog-rotate
endscript
}
--- 1,16
/var/log/syslog
{
! # rotate 7
! rotate 4
! # daily
! weekly
! # size 1M
missingok
notifempty
delaycompress
compress
postrotate
! invoke-rc.d rsyslog rotate > /dev/null
endscript
}
***
*** 32,37
delaycompress
sharedscripts
postrotate
! /usr/lib/rsyslog/rsyslog-rotate
endscript
}
--- 35,40
delaycompress
sharedscripts
postrotate
! invoke-rc.d rsyslog rotate > /dev/null
endscript
}
Bug#248496: raise priority
Am 03.06.2018 um 13:57 schrieb Salvo Tomaselli: > Well it had been open for over 10 years with 0 activity nor request > for more details, you only woke up because I raised priority, but are > not willing to take the package, a package that for me should be > removed. It has been working for the majority of users for the past ten years, that's why nobody raised the severity in the past. As long as you don't provide proper information to debug this issue nobody will be able to help you. Just removing a package is an extremely poor solution. signature.asc Description: OpenPGP digital signature
Bug#248496: raise priority
Well it had been open for over 10 years with 0 activity nor request for more details, you only woke up because I raised priority, but are not willing to take the package, a package that for me should be removed. Il giorno dom 3 giu 2018 alle ore 13:34 Markus Koschany ha scritto: > > Am 03.06.2018 um 13:33 schrieb Salvo Tomaselli: > > Debian sid, x86_64 up to date. Intel video card, not that it matters. > > It does matter. But with such poor bug reports this issue will never be > fixed for you. > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#248496: raise priority
Am 03.06.2018 um 13:33 schrieb Salvo Tomaselli: > Debian sid, x86_64 up to date. Intel video card, not that it matters. It does matter. But with such poor bug reports this issue will never be fixed for you. signature.asc Description: OpenPGP digital signature
Bug#248496: raise priority
Debian sid, x86_64 up to date. Intel video card, not that it matters. Il 03 Giu 2018 12:14, "Markus Koschany" ha scritto: > Am 03.06.2018 um 09:15 schrieb Salvo Tomaselli: > > It does not work for me, same thing as what the bugreport has, since > > over 10 years… > > We need more information if we want to tackle the problem. > > What Debian are you running? What architecture, desktop environment, X > server and graphics driver do you use? Add everything that might be > interesting to this bug report. Without those information it is very > hard to debug the problem. > > Markus > >
Bug#488091: Runit not started by upstart post-install, patch in ubuntu
control: close -1 [2009-10-07 12:25] Gerrit Pape > On Thu, Jun 26, 2008 at 11:12:16AM +0200, Gabriel de Perthuis wrote: > > Ubuntu bug (closed): > > https://bugs.launchpad.net/ubuntu/+source/runit/+bug/74135 > > http://launchpadlibrarian.net/14764478/start-supervisor.patch > > > > Ubuntu delta: > > http://packages.qa.debian.org/r/runit.html > > Hi, upstream suggest a different upstart integration > http://smarden.org/runit/useinit.html#upstart Seems this bug is no longer relevant, since upstart is no longer in sid. Feel free to reopen if I am wrong.
Bug#638605: runit: chpst fails to change uid not listed in /etc/passwd
control: close -1 [2012-06-25 12:00] Andras Korn > Package: runit > Version: 2.1.1-6.2 > Severity: normal > > > When system run with libnss-ldapd, chpst fails to change user > not listed in /etc/passwd (aka user in LDAP database). > > Rebuilding package on the target system, this problem disappear. > chpst binary is linked statically, so I guess linked version of > getpwnam() might lack ability to look /etc/nssswitch.conf. > > I suppose this problem caused by package build environment. > > FWIW, I use the following workaround to this problem: > > #!/bin/sh > [...] > RUNASUID=$(getent passwd $RUNASUSER | cut -d: -f3) > RUNASGROUPS=$(id -G $RUNASUSER | tr ' ' ':') > [...] > exec chpst -u :$RUNASUID:$RUNASGROUPS [...] chpst is no longer compiled statically, so issue should be resolved now. Feel free to reopen bug if I am wrong.
Bug#526201: runit: Environment variables in run script
control: tag -1 +wontfix control: close -1 [2017-01-06 11:38] Dmitry Bogatov > What is wrong with > > $ cd /etc/service/foo > $ echo 'OPTIONS=-bar > conf > $ cat run > #!/bin/sh > . conf > [...] > > I dislike idea to complicate runit itself, but it is not in my > competence. Such change is better to be proposed to upstream. Seems there is no much activity about this issue lately, so closing bug. Should any strong arguments why this feature request shoudl be fulfilled appear, feel free to reopen bug.
Bug#900682: ITP: octave-ncarray -- access NetCDF files as a multi-dimensional array in Octave
Package: wnpp Severity: wishlist Owner: Rafael Laboissière * Package name: octave-ncarray Version : 1.0.4 Upstream Author : Alexander Barth * URL : https://octave.sourceforge.io/ncarray/ * License : GPL-2+ Programming Lang: Octave Description : access NetCDF files as a multi-dimensional array in Octave This package contains functions for accessing a single or a collection of NetCDF files as a multi-dimensional array in Octave, a scientific computation software. This Octave add-on package is part of the Octave-Forge project. This package will be maintained in the realm of the Debian Octave Group. A preliminary version of the package can be built using git-buildpackage from the repository https://salsa.debian.org/pkg-octave-team/octave-ncarray.git
Bug#900018: FTBFS with latest cmdliner
Hi Andy, On 2018-05-25 08:40, Andy Li wrote: I've a patch: https://github.com/ocaml/opam/compare/1.2.2...andyli:1.2.2-fix.patch It's based on the discussion with upstream at https://discuss.ocaml.org/t/the-forever-beta-issue/1779/6 In fact, the patch introduces a bug and makes the build fail later in the process (can't generate manpages and test-suite doesn't succeed). Do you confirm this on your side as well? -- Mehdi
Bug#900681: please remove "Build-Conflicts: dia-shapes" and use proper fix
Package: dia Version: 0.97.3+git20160930-8 Severity: wishlist Tags: upstream patch debian/control contains this: Build-Conflicts: autoconf2.13, dia-shapes The "dia-shapes" build conflict is almost certainly there because when running: dpkg-buildpackage # or whatever -> dh -> [...] -> dh_auto_test -> make check-local this will finally do cd tests make test which will fail, because the following test: $ cat tests/Makefile.am test: $(TEST_PROGS) [...] ./objects ../objects// will *not* access dia ressources from within the source directory, but instead will use the system's ressources: more precisely, it will use shapes from /usr/share/dia/shapes which will include shapes from dia-shapes in case that package is installed. And - unfortunately - the shapes from dia-shapes will make the tests fail. That's why almost certainly one of the previous Dia maintainers added a build-conflict against dia-shapes to debian/control. Now the proper fix (IMHO) is to make sure that: cd tests make test will *not* access dia's resources in the system, but only dia's resources within the source directory. This is what these two patches here achieve: https://gitlab.gnome.org/GNOME/dia/issues/6 I think it is *not* urgent for Debian to include that fix, since simply deinstalling dia-shapes works around the problem. However for anybody that is using Dia, is working with dia-shapes and also wants to help fixing/developping Dia, this is quite painful. Thanks a lot, *t -- System Information: Debian Release: 9.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-6-amd64 (SMP w/8 CPU cores) Locale: LANG=de_CH.utf8, LC_CTYPE=de_CH.utf8 (charmap=UTF-8), LANGUAGE=de_CH:de (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages dia depends on: ii dia-common 0.97.3+git20160930-8 ii libart-2.0-2 2.3.21-2 ii libatk1.0-0 2.22.0-1 ii libc62.24-11+deb9u3 ii libcairo21.14.8-1 ii libfontconfig1 2.11.0-6.7+b1 ii libfreetype6 2.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgtk2.0-0 2.24.31-2 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpng16-16 1.6.28-1 ii libpython2.7 2.7.13-2+deb9u2 ii libxml2 2.9.4+dfsg1-2.2+deb9u2 ii libxslt1.1 1.1.29-2.1 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages dia recommends: ii dia-shapes 0.6.0-3 ii gsfonts-x11 0.24 dia suggests no packages. -- no debconf information
Bug#900605: mirrors: Debian mirror debian.parspack.com: unavailable
Hello Thank you, we have fixed the issue, would you please check this out again? Best Regards On Sat, Jun 2, 2018 at 1:59 AM, Julien Cristau wrote: > Package: mirrors > User: mirr...@packages.debian.org > Usertags: mirror-problem may-auto-close > Control: submitter -1 mirr...@debian.org > > Hi, > > I was checking some things in the Debian mirror universe and noticed a > problem with your mirror: > > It seems your mirror is no longer available. (I cannot reach it.) Is > this intentional? > > Status: https://mirror-master.debian.org/status/mirror-info/debian. > parspack.com.html > > Thanks, > Julien Cristau >
Bug#900471: Odp: Bug#900471: RFS: groonga/8.0.3-1
Dnia 3 czerwca 2018 10:18 Kentaro Hayashi haya...@clear-code.com napisał(a): On Thu, 31 May 2018 13:57:13 +0200 ox16 o...@o2.pl wrote: * Package name : groonga it working with Polish language? Technically, yes. It seems that Polish full text search example also works. Do You know tatoeba.org website? Is possible integrate this database?
Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates
On Sun, Jun 03, 2018 at 12:01:44PM +0200, Aurélien COUDERC wrote: > The repository is already up on Salsa at [0]. > I’ve left the master branch untouched as was on Alioth and created an > nmu-3.4.19 branch with the changes above. > The complete diff is at [1]. > > > [0] https://salsa.debian.org/dev-ref-team/developers-reference/ > [1] https://salsa.debian.org/dev-ref-team/developers- > reference/compare/debian%2F3.4.19...nmu-3.4.19 tbh, I'd put the repo on the debian group. devref has been quite poorly maintained in the last years, and most of the changes effectively happened because a random DD with an interest in updating a specific section just committed stuff and added themselves to the uploaders list. > Feel free to say if you think this is not a good idea or would better be done > differently. I even dare to say there is no "devref maintainers" team at all, and that if you actually wish to work on it you should go ahead, add yourself to uploaders and do stuff. Incidentally, what's your interest for working on devref? Surely you have some other goal other than those very very minor changes… -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#900677: ruby-google-protobuf: does not install pure ruby files
On Sun, 3 Jun 2018 15:06:44 +0530 Pirate Praveen wrote:> Adding > X-DhRuby-Root: ruby > > to ruby-google-protobuf binary section in debian/control fixes this. > with the above change, I still get another error LoadError: cannot load such file -- google/protobuf/timestamp_pb You'll need to generate the .pb files like this, https://salsa.debian.org/ruby-team/ruby-google-protobuf/blob/master/debian/rules#L9 signature.asc Description: OpenPGP digital signature
Bug#900680: marisa: Please switch upstream and package new upstream version
Source: marisa Version: 0.2.4-8 Severity: important X-Debbugs-CC: mty.shib...@gmail.com debian-input-met...@lists.debian.org Hi marisa maintainers and debian-input-method team, I noticed that package marisa is RC-buggy now and is still pointing at the legacy code.google.com upstream, which is now defunct. A new upstream has emerged on GitHub [2] with new version released just days ago. Please consider packaging the new version. Marisa is an important library in the IME world and affects fcitx and ibus through librime thus we might need some sort of coordination. If a transition is needed, let's do it too. -- Regards, Boyuan Yang [1] https://bugs.debian.org/899868 [2] https://github.com/s-yata/marisa-trie
Bug#900679: nmu: Migrating developers-reference to Salsa and minor updates
Package: developers-reference Version: 3.4.19 Severity: normal Dear Maintainer, I would like to NMU developers-reference for migrating the repository to Salsa and a couple of minor changes. The complete changelog would be : developers-reference (3.4.19+nmu1) UNRELEASED; urgency=medium [ Aurélien COUDERC ] * Non-maintainer upload. * Move repository to Salsa, update Vcs-* fields. * d/control: Bump Standards-Version to 4.1.4, no change needed. * Fix CSS text color to avoid the HTML version being unreadable when using a light on dark default browser stylesheet. -- Aurélien COUDERC Thu, 31 May 2018 23:17:33 +0200 The repository is already up on Salsa at [0]. I’ve left the master branch untouched as was on Alioth and created an nmu-3.4.19 branch with the changes above. The complete diff is at [1]. [0] https://salsa.debian.org/dev-ref-team/developers-reference/ [1] https://salsa.debian.org/dev-ref-team/developers- reference/compare/debian%2F3.4.19...nmu-3.4.19 Feel free to say if you think this is not a good idea or would better be done differently. Cheers, -- Aurélien -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.0-rc3-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy 4.1.4.1 Versions of packages developers-reference suggests: ii doc-base 0.10.8 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/doc/developers-reference/developers-reference.css (from developers-reference package)
Bug#248496: raise priority
Am 03.06.2018 um 09:15 schrieb Salvo Tomaselli: > It does not work for me, same thing as what the bugreport has, since > over 10 years… We need more information if we want to tackle the problem. What Debian are you running? What architecture, desktop environment, X server and graphics driver do you use? Add everything that might be interesting to this bug report. Without those information it is very hard to debug the problem. Markus signature.asc Description: OpenPGP digital signature
Bug#900678: slic3r: Segfaults at start since new wxwidgets.
Package: slic3r Version: 1.3.0+dfsg1-2 Severity: important Hi, Slic3r segfaults immediatly after launching. Triaging into it is seems that the update of wxwidgets causes this, at least I can reproduce on my other machine that when I update wxwidgets slic3r begins to fail. Attached is a gdb trace About the wxwdgets triaging: I've downgraded to the version I had before the segfault on the other machine. I did not invesitage if an intermediate version fixes it. The version I've downgraded to was: 3.0.3.1+dfsg2-1. (via snapshot.d.o) This is the aptitude log file for the downgrade: $ cat /var/log/aptitude Aptitude 0.8.10: log report Sun, Jun 3 2018 12:00:38 +0200 IMPORTANT: this log only lists intended actions; actions which fail due to dpkg problems may not be completed. Will install 11 packages, and remove 11 packages. 114 MB of disk space will be freed [REMOVE, NOT USED] fonts-freefont-ttf:amd64 20120503-8 [REMOVE, NOT USED] libalut0:amd64 1.1.0-5+b2 [REMOVE, NOT USED] libftgl2:amd64 2.1.3~rc5-4+nmu1.2 [REMOVE, NOT USED] libwxgtk-media3.0-gtk3-0v5:amd64 3.0.4+dfsg-4 [REMOVE, NOT USED] libwxgtk-media3.0-gtk3-dev:amd64 3.0.4+dfsg-4 [REMOVE, NOT USED] libwxgtk3.0-gtk3-dev:amd64 3.0.4+dfsg-4 [INSTALL, DEPENDENCIES] libwxgtk-media3.0-0v5:amd64 3.0.3.1+dfsg2-1 [INSTALL, DEPENDENCIES] libwxgtk-media3.0-dev:amd64 3.0.3.1+dfsg2-1 [INSTALL, DEPENDENCIES] libwxgtk3.0-dev:amd64 3.0.3.1+dfsg2-1 [DOWNGRADE] libalien-wxwidgets-perl:amd64 0.69+dfsg-2 -> 0.67+dfsg-3+b5 [DOWNGRADE] libwx-glcanvas-perl:amd64 0.09-5 -> 0.09-3+b5 [DOWNGRADE] libwx-perl:amd64 1:0.9932-4 -> 1:0.9932-2 [DOWNGRADE] libwxbase3.0-0v5:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1 [DOWNGRADE] libwxbase3.0-dev:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1 [DOWNGRADE] libwxgtk3.0-0v5:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1 [DOWNGRADE] wx-common:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1 [DOWNGRADE] wx3.0-headers:amd64 3.0.4+dfsg-4 -> 3.0.3.1+dfsg2-1 [REMOVE] darkradiant:amd64 2.6.0-2 [REMOVE] darkradiant-plugins-darkmod:amd64 2.6.0-2 [REMOVE] libwxgtk3.0-gtk3-0v5:amd64 3.0.4+dfsg-4 [REMOVE] libwxgtk3.0-gtk3-0v5-dbgsym:amd64 3.0.4+dfsg-4 [REMOVE] libx11-6-dbgsym:amd64 2:1.6.5-1 Log complete. Let me know if I can somehow help to triage this further. -- tobi -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-2-amd64 (SMP w/8 CPU cores) 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 slic3r depends on: ii libboost-filesystem1.62.0 1.62.0+dfsg-5.1 ii libboost-geometry-utils-perl 0.15-2+b6 ii libboost-system1.62.0 1.62.0+dfsg-5.1 ii libboost-thread1.62.0 1.62.0+dfsg-5.1 ii libc6 2.27-3 ii libencode-locale-perl 1.05-1 ii libexpat1 2.2.5-3 ii libgcc11:8.1.0-5 ii libio-stringy-perl 2.111-2 ii libmath-convexhull-monotonechain-perl 0.1-1+b6 ii libmath-geometry-voronoi-perl 1.3-3 ii libmath-planepath-perl 126-1 ii libmoo-perl2.003004-1 ii libstdc++6 8.1.0-5 pn libstorable-perl ii perl [libtime-hires-perl] 5.26.2-5 ii perl-base [perlapi-5.26.2] 5.26.2-5 Versions of packages slic3r recommends: ii libclass-xsaccessor-perl 1.19-2+b12 ii libio-all-perl0.87-1 ii libopengl-perl0.7000+dfsg-1 ii libpdf-api2-perl 2.033-1 ii libsvg-perl 2.84-1 ii libwx-glcanvas-perl 0.09-5 ii libwx-perl1:0.9932-4 ii libxml-sax-expatxs-perl 1.33-2+b4 slic3r suggests no packages. -- no debconf information Starting program: /usr/bin/perl /usr/bin/slic3r [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe839e700 (LWP 19422)] [New Thread 0x7fffe7b9d700 (LWP 19423)] [New Thread 0x7fffe739c700 (LWP 19424)] Thread 1 "perl" received signal SIGSEGV, Segmentation fault. 0x70858c49 in XQueryExtension (dpy=0x568d7900, name=0x7fffe43b7cc6 "GLX", major_opcode=0x7fffe40730b4, first_event=0x7fffcdb4, first_error=0x7fffe40730b8) at ../../src/QuExt.c:43 43 ../../src/QuExt.c: No such file or directory. #0 0x70858c49 in XQueryExtension (dpy=0x568d7900, name=0x7fffe43b7cc6 "GLX", major_opcode=0x7fffe40730b4, first_event=0x7fffcdb4, first_error=0x7fffe40730b8) at ../../src/QuExt.c:43 #1 0x7fffe43b43b2 in () at /usr/lib/x86_64-linux-gnu/libGLX.so.0 #2 0x7fffe43b0415 in glXQueryVersion () at
Bug#889845: quiterss: Update package to the last version
The developer of QuiteRSS has released version 0.18.11 but the version in the repository is still 0.18.8. Thanks for your attention.
Bug#900677: ruby-google-protobuf: does not install pure ruby files
On Sun, 3 Jun 2018 14:50:55 +0530 Pirate Praveen wrote: > package: ruby-google-protobuf > version: 3.6.0~rc2-1 > severity: grave > justification: makes package unusable > > When trying to use ruby-google-protobuf, I get this error > > LoadError: cannot load such file -- google/protobuf > > if you compare with previous versions of ruby-google-protobuf ( > http://snapshot.debian.org/package/ruby-google-protobuf/3.5.2-1/), > you'll see it does not install the pure ruby files (ruby/lib directory). > Adding X-DhRuby-Root: ruby to ruby-google-protobuf binary section in debian/control fixes this. signature.asc Description: OpenPGP digital signature
Bug#426359: fgetty: checkpassword error for nis account
control: close -1 [2017-01-06 11:37] Dmitry Bogatov > Can you please check your issue with fgetty_0.7-2? I have little > knowledge about NIS, so if bug persist, I could only ask for help. > But does it persist? Closing due timeout on moreinfo. Feel free to reopen.
Bug#898320: Tested 1.3.1 : no change. Linux and android world refuse to communicate
Again linux <->linux OK. Android <-> Android OK . Linux <-> Android KO. See upstream bug 394646 where someone has the same behavior. Contacted devled list. No help. Should be easy for soemeone who know the protocol to debug but with qtnetwork, it is even hard to see what goes on the wire, and what is cyphered, signed or not if you are not a qt dev. -- eric
Bug#900677: ruby-google-protobuf: does not install pure ruby files
package: ruby-google-protobuf version: 3.6.0~rc2-1 severity: grave justification: makes package unusable When trying to use ruby-google-protobuf, I get this error LoadError: cannot load such file -- google/protobuf if you compare with previous versions of ruby-google-protobuf ( http://snapshot.debian.org/package/ruby-google-protobuf/3.5.2-1/), you'll see it does not install the pure ruby files (ruby/lib directory). signature.asc Description: OpenPGP digital signature
Bug#900676: reportbug fails to start; unimplemented optparse subclass
Package: rebportbug Version: 7.1.7 Severity: grave When trying to start reportbug it instantly crashes with following message: –– $ reportbug Traceback (most recent call last): File "/usr/bin/reportbug", line 32, in import optparse File "/usr/lib/python2.7/optparse.py", line 250 raise NotImplementedError, "subclasses must implement" ^ SyntaxError: invalid syntax –– $ dpkg -S /usr/lib/python2.7/optparse.py libpython2.7-minimal:amd64: /usr/lib/python2.7/optparse.py $ apt show libpython2.7-minimal:amd64 Package: libpython2.7-minimal Version: 2.7.13-2+deb9u1 Thx for fixing
Bug#668903: The installer marks everything manually installed.
control: reassign -1 debian-installer Hi, > This ultimately results in a lot of junk accumulated on the system from > the start... you have to pluck packages out manually and check all of > the 350 or so packages installed by the installer to see if they're > actually required or not. debootstrap pulls several packages but not for the packages from tasks, so I want to reassign back to debian-installer. -- Hideki Yamane
Bug#900675: qt5-default: The Qt package is missing the scxml module, including the qscxmlc compiler.
Package: qt5-default Version: 5.10.1+dfsg-7 Severity: important Dear Maintainer, The Qt packages currentlyl available in Debian's repository is missing Qt's SCXML module. Note that Qt Creator ships with support for SCXML state machines and there's already a package available through Debian's repository for state machine charts in QML (qml-module-qtqml-statemachine). -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) 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 qt5-default depends on: ii qtbase5-dev 5.10.1+dfsg-7 ii qtchooser64-ga1b6736-5 qt5-default recommends no packages. Versions of packages qt5-default suggests: ii qt5-qmake 5.10.1+dfsg-7 ii qtbase5-dev-tools 5.10.1+dfsg-7 -- no debconf information
Bug#557322: manpage: mention that dependency resolution can readd excluded packages
control: tags -1 +pending Hi, Now --exlucde works properly and it is not added again (and maybe break dependency). -- Hideki Yamane
Bug#783589: debootstrap --exclude=dash doesn't
control: tags -1 +pending Now we can execute --exclude=dash (however, of course it fails ;) $ DEBOOTSTRAP_DIR=./ sudo ./debootstrap --cache-dir=/home/henrich/tmp/cache --exclude=dash stretch ~/tmp/stretch I: Target architecture can be executed (snip) W: Failure trying to run: chroot "/home/henrich/tmp/stretch" dpkg --force-depends --install /var/cache/apt/archives/base-passwd_3.5.43_amd64.deb W: See /home/henrich/tmp/stretch/debootstrap/debootstrap.log for details In debootstrap.log, > dpkg: warning: 'sh' not found in PATH or not executable > dpkg: error: 1 expected program not found in PATH or not executable > Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and /sbin -- Hideki Yamane
Bug#900532: ITP: estscan -- ORF-independent detector of coding DNA sequences
On 6/3/18 10:01 AM, Göran Weinholt wrote: > Steffen Möller writes: > >> Hello Göran, >> >> On 6/2/18 10:54 PM, Göran Weinholt wrote: >>> Steffen Moeller writes: >>> Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: estscan Version : 3.0.3 * URL : http://estscan.sourceforge.net/ * License : non-free custom Programming Lang: C, Fortran Description : ORF-independent detector of coding DNA sequences Continues packaging seeded by Bio-Linux, package is team maintained at https://salsa.debian.org/med-team/estscan >>> Hello Steffen, >>> >>> I saw "non-free", got curious, and had a look at the license. To me it >>> looks fine for main. >>> >>> I think the reason it might initially look non-free is § 1 (a), but >>> before that it says "under one of the following terms", and § 1 (b) is >>> no more than what's in the GPL and so clearly should be fine for main. >>> Did I perhaps miss something troublesome in the license? >>> >> They don't allow charging for its redistribution with a fee that exceeds >> material/handling/shipping costs. > That's what I thought the confusion was about. But we can ignore § 1 (a) > in the license and choose to redistribute under § 1 (b) instead. Under § > 1 (b) it doesn't say that we aren't allowed to charge a fee for the > initial distribution; the limitation on the fee in that case is for when > someone later comes and asks us for a copy of the source code. > > So one could redistribute the binaries for €100 per CD if one only > charges, let's say, €1-3 per source code CD. Alternatively § 1 (b) > allows us to distribute the binaries accompanied by the source. This is > the same as the GPL and should be fine for main. > > Now I'm curious why you closed the bug... I could formulate an email to > debian-legal and ask about the license, if you're still unsure (and if > it's still relevant)? ;Because I was so damn certain and you could reopen it. I finally reread it. You are right. I'll re-upload to main. Many thanks and greetings Steffen - will close with the upload this time :)
Bug#900471: Odp: Bug#900471: RFS: groonga/8.0.3-1
On Thu, 31 May 2018 13:57:13 +0200
ox16 wrote:
> * Package name : groonga
> it working with Polish language?
Technically, yes.
It seems that Polish full text search example also works.
Here is the example to demonstrate it:
% cat polish.grn
table_remove Examples
table_remove Terms
table_create --name Examples --flags TABLE_HASH_KEY --key_type ShortTex
column_create --table Examples --name sentence --type ShortText
table_create --name Terms --flags TABLE_PAT_KEY --key_type ShortText
--default_tokenizer TokenBigram
column_create --table Terms --name sentence_index --flags
COLUMN_INDEX|WITH_POSITION --type Examples --source sentence
load --table Examples
[
{"_key":"book","sentence":"Janek czyta książkę."},
{"_key":"car","sentence":"To jest samochód Janka."}
]
select Examples --query "sentence:@książkę"
In console:
% mkdir -p testdb
% groonga -n testdb/db < polish.grn
[[0,1528012694.460464,0.01500058174133301],
[[[1],[["_id","UInt32"],["_key","ShortText"],["sentence","ShortText"]],[1,"book","Janek
czyta książkę."
select Examples --query "sentence:@książkę" execute fulltext search by "książkę"
from sentence column in Examples table.
pgp8S9uLHhEqc.pgp
Description: PGP signature
Bug#896706: pcbnew: crashes with a failed assertion on i386, starts fine on amd64
Control: severity -1 serious Hello Mirko, On Sat, Jun 02, 2018 at 02:41:38PM +0200, Mirko Parthey wrote: > OK, I got kicad 5.0.0~rc2+dfsg1-2 from unstable. > Here's a typescript of my gdb session with a backtrace. > ... > #26 0x0041cd2d in PGM_SINGLE_TOP::OnPgmInit (this=) at > ./common/single_top.cpp:322 > #27 0x0042053e in APP_SINGLE_TOP::OnInit (this=0x4b2600) at > ./common/single_top.cpp:128 > #28 0xb7518176 in wxEntry(int&, wchar_t**) () from > /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0 > #29 0xb7518f83 in wxEntry(int&, char**) () from > /usr/lib/i386-linux-gnu/libwx_baseu-3.0.so.0 > #30 0x00419e56 in main (argc=, argv=0xb414) at > ./common/single_top.cpp:239 > (gdb) quit > A debugging session is active. I picked up a older laptop and installed a Debian testing i386 on it and I can reproduce that segfault here too. I also did a GDB trace of such a segfault and forwarded it to the bug report on the upstream bug tracker. It's now mostly up to the upstream developers to find the origin of the segfault which we see. Could be some additional compiler flags that are needed but also some specific platform macros that are needed. I'm not a expert in reading GDB logs so I hope the upstream developers can detect the issues in the logs. I marked this report now as serious as this is a RC bug. Until it's solved we wont see a migration of the kicad packages to testing. Regards Carsten
Bug#900532: ITP: estscan -- ORF-independent detector of coding DNA sequences
Steffen Möller writes: > Hello Göran, > > On 6/2/18 10:54 PM, Göran Weinholt wrote: >> Steffen Moeller writes: >> >>> Package: wnpp >>> Severity: wishlist >>> Owner: Steffen Moeller >>> >>> * Package name: estscan >>> Version : 3.0.3 >>> * URL : http://estscan.sourceforge.net/ >>> * License : non-free custom >>> Programming Lang: C, Fortran >>> Description : ORF-independent detector of coding DNA sequences >>> >>> Continues packaging seeded by Bio-Linux, package is team maintained at >>> https://salsa.debian.org/med-team/estscan >> Hello Steffen, >> >> I saw "non-free", got curious, and had a look at the license. To me it >> looks fine for main. >> >> I think the reason it might initially look non-free is § 1 (a), but >> before that it says "under one of the following terms", and § 1 (b) is >> no more than what's in the GPL and so clearly should be fine for main. >> Did I perhaps miss something troublesome in the license? >> > They don't allow charging for its redistribution with a fee that exceeds > material/handling/shipping costs. That's what I thought the confusion was about. But we can ignore § 1 (a) in the license and choose to redistribute under § 1 (b) instead. Under § 1 (b) it doesn't say that we aren't allowed to charge a fee for the initial distribution; the limitation on the fee in that case is for when someone later comes and asks us for a copy of the source code. So one could redistribute the binaries for €100 per CD if one only charges, let's say, €1-3 per source code CD. Alternatively § 1 (b) allows us to distribute the binaries accompanied by the source. This is the same as the GPL and should be fine for main. Now I'm curious why you closed the bug... I could formulate an email to debian-legal and ask about the license, if you're still unsure (and if it's still relevant)? -- Göran Weinholt Debian developer 73 de SA6CJK signature.asc Description: PGP signature
Bug#900674: RFP: odoc -- documentation generator for OCaml
Package: wnpp Severity: wishlist * Package name: odoc Version : 1.2.0 Upstream Author : Thomas Refis and al. * URL : https://github.com/ocaml/odoc * License : ISC Programming Lang: OCaml Description : documentation generator for OCaml odoc is a documentation generator for OCaml. It reads doc comments, delimited with (** ... *), and outputs HTML. odoc's main advantage over ocamldoc is an accurate cross-referencer, which handles the complexity of the OCaml module system. odoc also offers a good opportunity to improve HTML output compared to ocamldoc. Furthermore, odoc can be used by jbuilder/dune to generate documentation of OCaml projects using jbuilder/dune as a build-system. If you want to maintain odoc, please consider joining the OCaml team: https://wiki.debian.org/Teams/OCamlTaskForce/
Bug#900670: lintian: false positive spelling-error-in-manpage "some system -> some systems"
tags 900670 + pending thanks Fixed in Git, pending upload: https://salsa.debian.org/lintian/lintian/commit/f1f7bebd22fe296a06ae6e8d8e7c8e83950e1893 data/spelling/corrections-multiword | 1 - debian/changelog| 4 2 files changed, 4 insertions(+), 1 deletion(-) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#888709: debootstrap: Silently fails if the target directory exists and is not empty.
control: fixed -1 1.0.97 Hi, This behavior was fixed in 1.0.97 as > * Forbid the usage of non-empty directories with --print-debs and >--make-tarball Now we can see message as below. $ debootstrap --print-debs stretch ~/tmp/stretch E: Target directory '/home/henrich/tmp/stretch' is not empty and it would be wiped -- Hideki Yamane
Bug#900673: ibutils FTCBFS: abuses AC_CHECK_FILE
Source: ibutils Version: 1.5.7+0.2.gbd7e502-1 Tags: patch upstream User: helm...@debian.org Usertags: rebootstrap ibutils fails to cross build from source, because it abuses AC_CHECK_FILE to discover includes. AC_CHECK_FILE is meant for discovering files on the host machine, but here it is being used for discovering files on the build machine. A simple test -f is better and makes ibutils cross buildable. Please consider applying the attached patch. Helmut --- ibutils-1.5.7+0.2.gbd7e502.orig/ibis/config/osm.m4 +++ ibutils-1.5.7+0.2.gbd7e502/ibis/config/osm.m4 @@ -166,7 +166,7 @@ dnl validate the defined path - so the build id header is there - AC_CHECK_FILE($osm_include_dir/opensm/osm_config.h,, + AS_IF([test -f "$osm_include_dir/opensm/osm_config.h"],, AC_MSG_ERROR([OSM: could not find $with_osm/include/opensm/osm_config.h])) dnl now figure out somehow if the build was for debug or not --- ibutils-1.5.7+0.2.gbd7e502.orig/config/osm.m4 +++ ibutils-1.5.7+0.2.gbd7e502/config/osm.m4 @@ -166,7 +166,7 @@ dnl validate the defined path - so the build id header is there - AC_CHECK_FILE($osm_include_dir/opensm/osm_config.h,, + AS_IF([test -f "$osm_include_dir/opensm/osm_config.h"],, AC_MSG_ERROR([OSM: could not find $with_osm/include/opensm/osm_config.h])) dnl now figure out somehow if the build was for debug or not --- ibutils-1.5.7+0.2.gbd7e502.orig/ibmgtsim/config/osm.m4 +++ ibutils-1.5.7+0.2.gbd7e502/ibmgtsim/config/osm.m4 @@ -166,7 +166,7 @@ dnl validate the defined path - so the build id header is there - AC_CHECK_FILE($osm_include_dir/opensm/osm_config.h,, + AS_IF([test -f "$osm_include_dir/opensm/osm_config.h"],, AC_MSG_ERROR([OSM: could not find $with_osm/include/opensm/osm_config.h])) dnl now figure out somehow if the build was for debug or not
Bug#900672: RFS: ddccontrol-db/20180602-1
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "ddccontrol-db" * Package name: ddccontrol-db Version : 20180602-1 Upstream Author : Miroslav Kravec * URL : https://github.com/ddccontrol/ddccontrol-db * License : GPL v2 Section : utils It builds those binary packages: ddccontrol-db - monitor database for ddccontrol To access further information about this package, please visit the following URL: https://mentors.debian.net/package/ddccontrol-db Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/d/ddccontrol-db/ddccontrol-db_20180602-1.dsc Changes since the last upload: * New upstream release * debian/changelog: remove trailing newline Kind regards, Miroslav Kravec
Bug#900671: progres FTCBFS: fails dh_auto_clean
Source: progress Version: 0.13.1+20171106-1 Tags: patch User: helm...@debian.org Usertags: rebootstrap progress fails to cross build from source, because it validates its configuration on every make invocation including clean. While dh_auto_build passes PKG_CONFIG for dh_auto_build it doesn't for dh_auto_clean. The makefile doesn't like that and gives up finding ncurses. The attached patch passes PKG_CONFIG to all targets and thus makes cross building succeed. Potentially, we should consider applying this to debhelper itself, but the number of affected packages is fairly low. Please consider applying the attached patch. Helmut diff --minimal -Nru progress-0.13.1+20171106/debian/changelog progress-0.13.1+20171106/debian/changelog --- progress-0.13.1+20171106/debian/changelog 2018-02-14 07:02:46.0 +0100 +++ progress-0.13.1+20171106/debian/changelog 2018-06-03 09:13:58.0 +0200 @@ -1,3 +1,10 @@ +progress (0.13.1+20171106-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Also pass PKG_CONFIG for all dh_auto_*. (Closes: #-1) + + -- Helmut Grohne Sun, 03 Jun 2018 09:13:58 +0200 + progress (0.13.1+20171106-1) unstable; urgency=medium * New upstream snapshot 0.13.1+20171106. diff --minimal -Nru progress-0.13.1+20171106/debian/rules progress-0.13.1+20171106/debian/rules --- progress-0.13.1+20171106/debian/rules 2018-02-14 06:44:26.0 +0100 +++ progress-0.13.1+20171106/debian/rules 2018-06-03 09:13:57.0 +0200 @@ -2,6 +2,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all export DEB_CFLAGS_MAINT_APPEND = -Wall #-pedantic export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed +-include /usr/share/dpkg/buildtools.mk +export PKG_CONFIG ?= pkg-config export PREFIX=/usr %:
Bug#248496: raise priority
It does not work for me, same thing as what the bugreport has, since over 10 years… Il giorno sab 2 giu 2018 alle ore 15:17 Markus Koschany ha scritto: > > Control: severity -1 normal > Control: tags -1 moreinfo > > On Sat, 2 Jun 2018 12:18:22 +0200 Salvo Tomaselli > wrote: > > severity 248496 grave > > thanks > > > > Raising priority, since the game does not run at all and the package > > seems completely abandoned. > > > > If I'm right, the package will eventually just be dropped. > > Hello, > > the game works for me on amd64 and i386 in Sid. I cannot confirm that > the game is unusable for the majority of users hence I think severity > grave is not justified in this case. > > Please note that the package has been orphaned. It simply needs a new > maintainer. > > https://bugs.debian.org/869291 > > Regards, > > Markus > -- Salvo Tomaselli "Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno." -- Galileo Galilei http://ltworf.github.io/ltworf/
Bug#900670: lintian: false positive spelling-error-in-manpage "some system -> some systems"
it seems a problematic check more generally - e.g. "that's quite some system you have there"
Bug#875738: [Python-apps-team] Bug#875738: cherrytree: The package has a new version available 0.38.2
Hi Johann, On Thu, May 31, 2018 at 6:58 AM, Johann Glaser wrote: > Hi! > > Please package the newest available version 0.38.4 (since 2017-12-02, > i.e., half a year ago). > > https://www.giuspen.com/cherrytree/#downl Even if the latest cherrytree version were packaged, it would be uninstallable in sid due to #822586 [1]. Regards, Vincent [1] https://bugs.debian.org/822586
Bug#896667: It is safe to assume that source only uploads will build against the r-api-3.5? (Was: Bug#896667: transition: r-base-3.5)
On 3 June 2018 at 00:29, Andreas Tille wrote: > On Sat, Jun 02, 2018 at 11:22:07PM +0200, Emilio Pozuelo Monfort wrote: >> > I found this while rebuilding r-cran-cummerbund (level 13) in Ubuntu, >> > so anything else missing is a leaf package (or set of leaf packages, I >> > guess). >> >> Do you need a binNMU for r-cran-fastcluster, or do you need to patch it? >> Please >> be clear if you need actions from me, otherwise I may not always realise it. > > I just manually uploaded. Thanks for your work anyway Thanks Andreas. I see the 1.1.24-2 upload, but I don't see the r-api-3.5 dependency in the r-cran-fastcluster binary package, so whatever caused it to not appear on the tracker is still not fixed.
Bug#894991: [alsa-utils]
Is there any chance of getting this patch included? It should apply cleanly to
1.1.6-1.
Antonio Russo
commit 1d0e242b416435d56c6ffde13f7a3da8ed77949d
Author: Antonio Russo
Date: Sun Jun 3 02:29:46 2018 -0400
Pass XDG_RUNTIME_DIR to alsactl
diff --git a/debian/init b/debian/init
index e6a6e92..fb55ae1 100755
--- a/debian/init
+++ b/debian/init
@@ -62,13 +62,13 @@ restore_levels()
# then it failed somehow. This works around the fact
# that alsactl doesn't return nonzero status when it
# can't restore settings for the card
- if MSG="$(alsactl -E HOME="$ALSACTLHOME" restore $CARD 2>&1 >/dev/null)" && [ ! "$MSG" ] ; then
+ if MSG="$(alsactl -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR="${ALSACTLRUNTIME}" restore $CARD 2>&1 >/dev/null)" && [ ! "$MSG" ] ; then
return 0
else
# Retry with the "force" option. This restores more levels
# but it results in much longer error messages.
alsactl -F restore $CARD >/dev/null 2>&1
- log_action_cont_msg "warning: 'alsactl -E HOME="$ALSACTLHOME" restore${CARD:+ $CARD}' failed with error message '$MSG'"
+ log_action_cont_msg "warning: 'alsactl -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR="${ALSACTLRUNTIME}" restore${CARD:+ $CARD}' failed with error message '$MSG'"
return 1
fi
}
@@ -78,11 +78,11 @@ store_levels()
{
CARD="$1"
[ "$1" = all ] && CARD=""
- if MSG="$(alsactl -E HOME="$ALSACTLHOME" store $CARD 2>&1)" ; then
+ if MSG="$(alsactl -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR="${ALSACTLRUNTIME}" store $CARD 2>&1)" ; then
sleep 1
return 0
else
- log_action_cont_msg "warning: 'alsactl store${CARD:+ $CARD}' failed with error message '$MSG'"
+ log_action_cont_msg "warning: 'alsactl store${CARD:+ $CARD}' -E HOME="$ALSACTLHOME" -E XDG_RUNTIME_DIR=@alsactlruntime@ failed with error message '$MSG'"
return 1
fi
}
diff --git a/debian/patches/alsactl_xdg_runtime.patch b/debian/patches/alsactl_xdg_runtime.patch
new file mode 100644
index 000..5ebeabf
--- /dev/null
+++ b/debian/patches/alsactl_xdg_runtime.patch
@@ -0,0 +1,70 @@
+Author: Antonio Russo
+Description: add new configure switch to set alsactl's runtimedir.
+
+Index: b/alsactl/90-alsa-restore.rules.in
+===
+--- b.orig/alsactl/90-alsa-restore.rules.in
b/alsactl/90-alsa-restore.rules.in
+@@ -2,7 +2,7 @@ ACTION=="add", SUBSYSTEM=="sound", KERNE
+ GOTO="alsa_restore_end"
+
+ LABEL="alsa_restore_go"
+-TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl -E HOME=@alsactlhome@ restore $attr{device/number}"
+-TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl -E HOME=@alsactlhome@ nrestore $attr{device/number}"
++TEST!="@daemonswitch@", RUN+="@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ restore $attr{device/number}"
++TEST=="@daemonswitch@", RUN+="@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ nrestore $attr{device/number}"
+
+ LABEL="alsa_restore_end"
+Index: b/alsactl/Makefile.am
+===
+--- b.orig/alsactl/Makefile.am
b/alsactl/Makefile.am
+@@ -41,6 +41,7 @@ edit = \
+ $(SED) -r -e 's,@sbindir\@,$(sbindir),g' \
+ -e 's,@mydatadir\@,$(mydatadir),g' \
+ -e 's,@alsactlhome\@,$(ALSACTL_HOME_DIR),g' \
++ -e 's,@alsactlruntime\@,$(ALSACTL_RUNTIME_DIR),g' \
+ -e 's,@daemonswitch\@,$(ALSACTL_DAEMONSWITCH),g' \
+ -e 's,@asoundrcfile\@,$(ASOUND_STATE_DIR)/asound.state,g' \
+ < $< > $@ || rm $@
+Index: b/alsactl/alsa-restore.service.in
+===
+--- b.orig/alsactl/alsa-restore.service.in
b/alsactl/alsa-restore.service.in
+@@ -12,5 +12,5 @@ ConditionPathExists=@asoundrcfile@
+ [Service]
+ Type=oneshot
+ RemainAfterExit=true
+-ExecStart=-@sbindir@/alsactl -E HOME=@alsactlhome@ restore
+-ExecStop=-@sbindir@/alsactl -E HOME=@alsactlhome@ store
++ExecStart=-@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ restore
++ExecStop=-@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ store
+Index: b/alsactl/alsa-state.service.in
+===
+--- b.orig/alsactl/alsa-state.service.in
b/alsactl/alsa-state.service.in
+@@ -9,5 +9,5 @@ ConditionPathExists=@daemonswitch@
+
+ [Service]
+ Type=simple
+-ExecStart=-@sbindir@/alsactl -E HOME=@alsactlhome@ -s -n 19 -c rdaemon
+-ExecStop=-@sbindir@/alsactl -E HOME=@alsactlhome@ -s kill save_and_quit
++ExecStart=-@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ -s -n 19 -c rdaemon
++ExecStop=-@sbindir@/alsactl -E HOME=@alsactlhome@ -E XDG_RUNTIME_DIR=@alsactlruntime@ -s kill save_and_quit
+Index: b/configure.ac
+===
+--- b.orig/configure.ac
b/configure.ac
+@@ -413,6 +413,12 @@ AC_ARG_WITH([alsactl-pidfile-dir],
+ [ALSACTL_PIDFILE_DIR="/var/run"])
+
Bug#900640: garmin-forerunner-tools: Lots of URLs/addresses are incorrect
Quoting Diederik de Haas (didi.deb...@cknow.org): > Package: garmin-forerunner-tools > Version: 0.10repacked-10+b1 > Severity: normal > > As the maintainer address is no longer functional (see #899519), I'm > sending it (also) directly to the listed maintainers. > Hopefully that's not (too) inappropriate. > > I recently bought a Garmin Forerunner 645 Music and found this package, > but noticed several issues on its package tracker page, > https://tracker.debian.org/pkg/garmin-forerunner-tools. > > - As listed above and in #899519, the maintainer address no longer > works. > - The upstream web homepage is listed as > http://garmintools.googlecode.com/ but that gives a 404. There is one > that works (https://code.google.com/archive/p/garmintools/) but that's > purely an archived version, so not very useful either. > Through some detours I found that https://github.com/jorgesca/garmintools > is now listed as the new upstream. But other then an import of that same > code, there isn't much/any difference. It does contain the original > issues though, which does seem useful. > Searching on GitHub (https://github.com/search?q=garmintools) I found > several others and looking through various of them, it looks like > https://github.com/phako/garmintools is the one with various new > commits added to them, most recently on 2018-02-23. > OTOH it also contains a commit removing HURD ifdefs. > I could of course create yet another repo and cherrypick various > commits from various repos, but that'll create https://xkcd.com/927/. > - The VCS Browse URL points to > https://git.debian.org/?p=pkg-running/garmin-forerunner-tools.git;a=summary > but when opening that page you get a message that alioth is > discontinued. I tried searching on https://salsa.debian.org/ but > couldn't find garmin-forerunner-tools or pkg-running. > - I did find https://alioth-archive.debian.org/git/pkg-running/ which > contains an archived copy of pkg-running and its sub-repos, including > the repo for this package. > > Looking through > https://qa.debian.org/developer.php?email=pkg-running-devel%40lists.alioth.debian.org > it looks like the other pkg-running packages are in a similar, not so > great, state but I hope there's still interest in improving things :). Good question As for me, I'm in the process of stepping out from Debian, as my priorities have progressively switched from Debian work to other activities over the years. I tried to prepare this properly, but the shutdown of Alioth didn't help: I never took time to invest my time in Salsa before Alioth's complete stop.and I will probably never. I can't speak for other pkg-running team members, but Ralf and Noèl have low activity toowhich, of course, brings concerns about packages we maintained over the years. In anycase, NMU with patches even to fix "trivial" stuff are highly welcomed. Thansk for your interest in these packages signature.asc Description: PGP signature
Bug#894414: pdf-presenter-console: cursor changesto hand over movie area, voice id hear but animation does not start
> Can you explain how to contact "developers on GitHub". I am somewhat > outside my comfort zone here, but eager to learn and very motivated to > support this. The upstream project of pdfpc is at https://github.com/pdfpc/pdfpc/ . You need a github account to open issues there. signature.asc Description: PGP signature
Bug#900670: lintian: false positive spelling-error-in-manpage "some system -> some systems"
Package: lintian Version: 2.5.89 Severity: normal Hi all, I'm packaging libdate-manip-perl. Lintian reports a spelling error for this sentence: The preferred way is to locate the time zone in some system file, or using some system command... I've patched it to replace "some system file" by "some system files" and "some system command" by "some system commands" which seems to be really spelling errors. But Lintian warns always since it doesn't take care of the next word. Note: I'm not English native and may have reported a bad error. If so, please excuse me and close this issue. Regards, Xavier -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils 2.30-20 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.19.0.5+b1 ii file 1:5.33-2 ii gettext0.19.8.1-6+b1 ii intltool-debian0.35.0+20060710.4 ii libapt-pkg-perl0.1.34 ii libarchive-zip-perl1.60-1 ii libclass-accessor-perl 0.51-1 ii libclone-perl 0.39-1 ii libdpkg-perl 1.19.0.5 ii libemail-valid-perl1.202-1 ii libfile-basedir-perl 0.08-1 ii libipc-run-perl20180523.0-1 ii liblist-moreutils-perl 0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl1.74-1 ii libxml-simple-perl 2.25-1 ii libyaml-libyaml-perl 0.69+repack-1 ii man-db 2.8.3-2 ii patchutils 0.3.4-2 ii perl [libdigest-sha-perl] 5.26.2-5 ii t1utils1.41-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.19.0.5 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.53-1 -- no debconf information
Bug#736898: Bug is back
On June 3, 2018 at 12:47PM +0900, tats (at debian.org) wrote: > On June 3, 2018 at 9:21AM +0800, jidanni (at jidanni.org) wrote: >> Preparing to unpack .../120-w3m-el-snapshot_1.4.625+0.20180518-1_all.deb ... >> ERROR: w3m-el-snapshot is broken - called emacs-package-remove as an >> old-style add-on, but has compat file. >> Remove w3m-el-snapshot for emacs >> Unpacking w3m-el-snapshot (1.4.625+0.20180518-1) over (1.4.609+0.20171225-1) >> ... > > Please mention if you are using experimental packages. > > Note that the experimental version of emacsen-common (3.0.0) has > drastically been changed. It seems your emacsen-common installation has a problem, so the file /var/lib/emacsen-common/state/package/installed/emacsen-common is not found. Anyway, I'll remove old-style calls from w3m-el-snapshot to close this bug. Thanks, -- Tatsuya Kinoshita pgp9al70JxawA.pgp Description: PGP signature
