Thanks!
I guess preparing these is pretty straightforward.
Would like to think my efforts to keep debian/rules etc clean and tidy
made this work so easily.
Given that the patch is nothing but a changelog entry, I'm assuming
it's not really worth making a branch on fossil.
" * Backport to bookworm
Well, it would certainly be simple enough: the source code should
compile fine, and the debian/* scripts would need only the very most
minor tweaks.
The fossil upstream is also the sqlite3 upstream. They could not
possibly be more familiar with sqlite3!
When you ask fossil to build using an external (system) sqlite3
library, configuration-time checks are performed to see if the
external sqlite3 is up to snuff. If not, either because it is too
I've uploaded a package with this fixed to unstable, 1:2.24-5, and
it's been autobuilt and pushed out. Seems to work okay, and can be
co-installed with apache2/sid.
Just uploaded 1:2.24-6 that adds Breaks: apach2-bin per your recent message.
Honestly, I'm not confident in my ability to properly
uploaded
will do
Bastien,
Okay, got it. Thanks for letting me know.
I can cherry-pick that fossil commit, but you know the right magic for
a versioned apache2 breakage and how to deal with proposed-updates.
So I think it would make sense for you to do all of this in a
coordinated fashion?
If that's okay with
Well, it's not a *violation* of the DFSG to include derived files in
the upstream sources, as long as the source needed to regenerate them
is also included. That's often done for bootstrapping compilers.
Source tarballs also often include documentation PDFs and such so
people installing the
with that. What do you think? This would be:
Maintainer: Leo Antunes
Uploaders: Alexandre Rossi ,
Barak A. Pearlmutter
and would allow "proper" uploads, not just NMUs.
I merged your "fix build on bookworm" patch, but the package still
builds fine on a chro
I use transmission constantly and would be happy to sponsor. In
principle of course: assuming there are no technical show-stoppers.
I already have my own fork on salsa.debian.org/bap/transmission with
some very minor tweaks.
In the meantime, I note that Sandro Tosi has dropped his
maintainership
The libddccontrol library is, to my knowledge, only used by packages
generated by the same source package, namely ddccontrol and
gddccontrol. And time_t is only used internally, not exposed via the
library's ABI. Under these circumstances, I don't think transitioning
libddccontrol is, technically
This is still a problem.
And here's a scenario where it's worse! Which happened to me.
User "helena" is marked admin. But has never logged in, so as yet has
no password set.
User "barak" is logged in, and wants to run synaptic. That user is set
up to allow sudo with no password.
But oops,
Thanks.
Please feel free to just fix and upload stuff like this, push fix to salsa
git repo. I absolutely don't mind. If you don't I'll get to it in a few
days.
I'm the gmailieer, aka lieer, maintainer.
Yes, please upgrade this!
Lieer is assuming the 2.x version (well, 1.8 or above) of the python
google auth library, with the to_json method. There isn't much I can
do to fix lieer until this package is upgraded.
(See also #1053227)
Well that seems a bit drastic! You don't want to lose *all* the error messages.
I was thinking something which leaves stdout alone and just filters
out annoying stderr lines.
Like this:
#!/usr/bin/bash
set -e
xournalpp "$@" 2> >(egrep -v '^ALSA lib .*snd_')
se. Anyway, patches welcome, at least to Xournal++.
If it really bugs you, as a workaround I'd suggest redirecting
standard error to a log file, maybe via a pipe that removes the
annoying ALSA stuff.
Cheers,
--Barak Pearlmutter
I pushed a quick update, it has a few test failures though.
Yeah, I'll do that: flush the package, with a parting recommendation
on mnemosyne.
Package: kexec-tools
Version: 1:2.0.25-3
Version 2.0.27 is available upstream. Also the packaging was a bit
scruffy around the edges, so I updated the packaging scripts and
yanking in the newest upstream version and put it all in
https://salsa.debian.org/debian/kexec-tools
(I did it because
Dear Alexander,
Since minidlna upstream version 1.3.3 has been out since the end of
May 2023, and I've been testing my packaging of it pretty hard and it
seems significantly more robust than the current version in Debian,
I'm going to take the liberty of doing an NMU of it with a delay of
three
This issue is now pretty much moot, since by default
$ sysctl fs.inotify.max_user_watches
fs.inotify.max_user_watches = 65536
and 64K "should be enough for anyone."
I've done a bit more packaging of dleyna, pushed to
https://salsa.debian.org/debian/dleyna.git branch debian/main, mainly
moving to the latest upstream 0.8.2. My plan is to adopt it by
uploading, which hopefully will result in mopidy-dleyna becoming
usable and then I'll be able to listen to DLNA
woops
I tried this patch with the new upstream release 1.3.3,
see https://salsa.debian.org/bap/minidlna.git branch master
and it didn't really work. I have a computer connected to WiFi and
also a direct ethernet cable connection to a TV, and the TV cable can
bounce up and down, and this patch made
Package: elpa-use-package
Version: 2.4.4-1
I am a fun-loving bloke so /usr/games is on my path and pacman (the
package) is installed. When emacs is started and elpa-use-package
loads and searches for an appropriate value for
system-packages-package-manager it finds the executable
reassign 1042902 elpa-system-packages 1.0.11-2
thanks
The variable system-packages-package-manager gets set to "pacman"
because the executable path is searched for appropriate programs, and
"pacman" is searched for before "apt", and so if the game pacman is
installed (package pacman) and
Package: emacs-gtk
Version: 1:29.1+1-2
Severity: normal
The global variable system-packages-package-manager (introduced in 29.x)
defaults to "pacman" instead of the more debian-appropriate "apt".
enabling hardening.
--Barak Pearlmutter
PS MiniDLNA is fantastic! Thanks for packaging it.
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: gtkbo...@packages.debian.org
Control: affects -1 + src:gtkboard
Nothing depends on this package. It is ancient, unmaintained upstream,
and uses the obsolete SDL 1.2 and GTK 2.
Wow, thanks everyone for tracking this down so quickly!
I'm going to close it, since it was due to non-debian packages.
Package: veyon-service
Version: 4.7.5+repack1-1
Veyon does not have Wayland support, which is slated to be released
with version 5.x in about two and a half years ago. In the meantime,
when client machines are logged in with Wayland, the master cannot
view their screens etc. I would suggest that,
Thanks for noting that.
Already filed for RM, see bugs.debian.org/1033450
PS This is at ROM
Package: ftp.debian.org
Severity: normal
Upstream requested we use the name blackbox-terminal instead of
black-box-terminal, for compatibility with other distribution
channels. So I changed the name up and uploaded to NEW, but was unable
to stop the old name black-box-terminal from getting
Upstream has suggested renaming this to blackbox-terminal, for
compatibility with other distributions, flatpacks, etc, which are
using that name. So I'm doing the rename and re-uploading to new.
I've done a bit of testing, and my prelim 1.2.2 packaging seems to
work fine. Also a tiny bit more yak shaving.
I have not tried to get the unit testing stuff working with the
debian/tests automated test suite business. But if that were done,
this version might be able to get past the freeze.
cool.
force pushed yours to my repo, and rebased some yak shaving onto it
I would say that marking lots of 100% downloaded torrent as 0%, and
refusing to re-verify them, would count as a severity: important bug,
and hence allow 4.0.2 to get into the release. The release team wants
a high-quality release just as much as we do, and transmission is a
leaf package and
Leo,
Thanks for uploading 4.0.1-1. Good idea to disable libtransmission-dev for now.
I did a bit of testing, and it seems to get a bunch of those old "no
bencoded data to parse" errors, and a whole bunch of fully downloaded
torrents showed up as 0%. So I cherry-picked to the tip of
upstream/main
a DD, so
would be happy to do an NMU if you'd like, after a bit of testing of
course.
Cheers,
--Barak Pearlmutter.
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
* Package name: black-box-terminal
Version : 0.13.2
Upstream Author : Paulo Queiroz
* URL or Web page : https://gitlab.gnome.org/raggesilver/blackbox.git
* License : GPL-3+
Description : Black Box aka
Package: wnpp
Owner: Barak A. Pearlmutter
Severity: wishlist
* Package name: libpqmarble
Version : 1.3.0
Upstream Author : Paulo Queiroz
* URL or Web page : https://gitlab.gnome.org/raggesilver/marble
* License : GPL-3+
Description : Paulo Quizroz's collection
For me it triggered verification of all existing torrents, but some of
them which are actually 100% downloaded show as 0% even after
verification. These are (after the cherry picking etc) only ones with
a single file download, rather than a directory. And only some of
them. Some of the ones that
Okay, I cherry-picked upstream commits 487cc27e1..d21a3b622, the
endpoint being the current upstream/main, and built, and installed,
and it seems to solve this problem. The "no bencoded data to parse"
messages are gone. And things verify upon request, with most of them
succeeding. A few failed to
Okay, I installed the package generated by 16c2e55a0 in my repo, which
is a 4.0.1-1 candidate. It seems to work okay EXCEPT ...
(a) is kicks out messages like this
Feb 26 21:49:35 sweat transmission-daemon[1174]: [2023-02-26
21:49:35.396] ERR torrent-metainfo.cc:630 no bencoded data to parse
Testing the 4.0.1 daemon.
Upgrade seems okay, although there's some straggler ghost file
/etc/init/itransmission-daemon.conf
The upgraded daemon invalidates all downloaded data and wants to
verify them, which is a local operation, but is still taking forever.
I think that's supposed to be a
Okay, well...
> Just FYI: I have done some work in the salsa repo[0], but there are still a
> few kinks to iron out before we can ship it. It builds, but my debhelper-foo
> is a bit rusty :)
> If anyone wants to jump in and finish it up, I wouldn't complain!
Don't complain, because I did a
I went and tried to do a trial updating of the package to 4.0.1.
Still monkeying around with that.
It seems that the cmake build scripts have the option -DINSTALL_LIB=ON
to generate a library, but it generates a *static* libtransmisison.a,
and there is no option to generate a dynamic/shared
> >Failing on some inputs is not a justification for a `serious` severity.
>
> *Silently* failing, i.e. saying you succeed but not doing so,
> however is
Regardless of severity, does anyone have any good ideas for fixing
this? Patches welcome! Feel free to just upload a fix if you have the
urge.
Thanks for the bug report.
On a "testing" system, with webcamoid 9.0.0-5.
$ rm -r ~/.cache/Webcamoid
$ webcamoid
[2023-01-20 12:04:13.838, Webcamoid, 0x7f432a7577c0, (0)] warning:
QSocketNotifier: Can only be used with threads started with QThread
[2023-01-20 12:04:14.975, Webcamoid,
I would also find this useful, in my case for the mit-scheme package.
Please do it!
(Should the Debian BTS have an upvote system? It's already basically
reddit, with each package a subreddit and each bug a post.)
I also hate having to guess which dh_* commands do substitution and
which don't.
Just wanted to confirm that upgrading to libgupnp-1.6-0 from sid,
version 1.6.3-1, seems to have completely solved this problem. Rygel
used to crash constantly, and now seems rock solid on a server with a
WiFi link to the home network and exposing a NAT Ethernet connection
to a TV, with both
Cool!
I had assumed, from the log messages etc, that this was likely a race
condition between the network configuration changing and rygel being
notified of, and adjusting to, said configuration.
Okay, here's a manifestation of some network-change rygel-stops issue.
This is rygel 0.42.0-2.
Logs below.
After "systemctl --user restart rygel.service" it works fine.
$ last -1 reboot
reboot system boot 6.0.0-6-amd64Wed Dec 21 09:00 still running
$ systemctl --user status
Package: gnome-music
Version: 42.1-1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter
The package description reads, in part:
> Objectives includes ... a player for DLNA media servers ...
"If wishes were horses, beggars would ride."
Right now there is no DLNA support i
Package: rygel
Version: 0.42.0-2
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter
My rygel DLNA server stopped actually worked (did not show the actual
video files, just directories, on my LG TV; showed the files, but did
not show thumbnails or actually serve their content, on totem
Yes! That fixes it.
Just to be clear: I didn't get a chance yet to, like, actually test it.
Package: install-info
Version: 6.8-6+b1
Severity: normal
X-Debbugs-Cc: none, Barak A. Pearlmutter
The directory file /usr/share/info/dir entry for emacs itself is messed
up, even after a clean regeneration.
Note the strange characters here that mess up the entry:
$ cat -v /usr/share/info/dir
Package: minidlna
Version: 1.3.0+dfsg-2.2+b3
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter
Merge upstream version 1.3.2, packaging updates, and minor patches.
I've put these in a git fork on salsa, see
https://salsa.debian.org/debian/minidlna/-/merge_requests/4
Cheers,
--Barak.
Wow, thanks! Will dput asap.
Can do, although patches would be welcome.
Here's a broader suggestion though. I can change the dependency to
"yt-dlp | youtube-dl", but how about if yt-dlp sets up an alternative
(using update-alternatives) for /usr/bin/youtube-dl to a little script
that tosses a "--compat-options" onto the
Package: rygel
Version: 0.42.0-2
Dear Maintainer,
Thanks for maintaining Rygel. It's made our big TV useful! And tablets!
Everyone on the local network is happy!
To keep everyone happy, I turned on lingering for the involved user (me)
$ loginctl enable-linger $(whoami)
and enabled rygel. This
Updated my prelim packaging to upstream 0.5.4.
Great idea!
Patches welcome.
Package: timekpr-next
Version: 0.5.2-1
Thanks for packaging timekpr-nExT. My 11yo daughter hates it!
There's a new upstream version available.
I did a quick packaging in https://salsa.debian.org/bap/timekpr-next
which installs fine but would require testing.
I note that the upstream author
I light of 2.46, I rejiggered my patches and packaging for that. See
https://salsa.debian.org/bap/xdaliclock branch master.
Package: xdaliclock
Version: 2.44+debian-3
Upstream 2.45 is out, and uses gtk3 and is antialiased.
I've done a prelim packaging (including reworking the upstream
autotools stuff in a patch), feel free to cannibalize any or all as
you see fit; in salsa.debian.org/bap/xdaliclock
Thanks. Good eye!
Turns out upstream had a typo in a git tag, which is what the
packaging tooling sees.
Hardly seems worth bumping an epoch when it will be solved by just
waiting a few weeks. We call this "laziness", right?
I've issued merge requests on salsa to the pulseaudio package that
addresses this issue. All it does is install the modules in
/usr/lib/pulse-MAJOR.MINOR/modules/. Using that small fix, paprefs is
not grayed out anymore.
Just took over paprefs. Yes this is an issue.
You can fix it for now by adding a symbolic link, but yuck.
Open to suggestions.
See https://bugs.debian.org/1003163
(Maybe these bugs should be merged)
The root cause here seems to be that
pa_get_library_version()
in libpulse0 does not include the "+dfsg" suffix.
I'd say that either (A) it should, or (B) the pulse stuff should all
be installed in a directory without the suffix, or (C) there should be
a symbolic link from a non-suffix directory
I don't understand this code in that patch:
+ while (true) {
+ unowned Posix.Passwd passwd =
Posix.getpwent();
+ if (passwd.pw_name ==
GLib.Environment.get_user_name()) {
+
Yes.
I patched over the issue for now by just using the internal sqlite3
library, so I think it can wait until the next official release to
pick up the proper bug fix and go back to using the system sqlite3
library.
I've done a prelim (UNRELEASED) packaging of 1.2, see packaging repo fork
https://salsa.debian.org/bap/paprefs
I've enabled CI, so if you go to CI/CD>Pipelines and click on the
"build" job, you should be able to download a built binary amd64
package as one of the "Job artifacts" on the right.
Package: libsvm-dev
Version: 3.24+ds-6
Severity: wishlist
Any chance of a GPU-enabled version? Appropriate mods to use CUDA are
in https://github.com/prehensilecode/mklabiti-libsvm-cuda although
that might be a bit dated, not sure it's tracked since libsvm 3.0. But
it would be really nice to
You can right click in the left column and there's a menu with one
item: REFRESH.
I don't think it's well placed, a button next to CONNECT would be
better. But it does address this issue...
Package: transmission-remote-gtk
Version: 1.4.1-5
Severity: wishlist
There's a new upstream version available.
I've taken the liberty of doing a prelim updated packaging; it uses
meson, and I patched it to use libayatana-appindicator3-dev, which is
license compatible and the successor to
That's a useful little shell script. But small. Maybe it would make
sense to get it included in /usr/share/doc/openssh-client/examples/?
Or make a package ssh-misc-utils that contains a bunch of scripts for
doing useful little tasks? Basically, to agglomerate it with some
other related things, so
As a stop-gap until this is fixed, you can run this script (as root, obviously).
fix-guake-desktop-link
Description: Binary data
I will file an issue upstream. But I don't expect them to care,
because github (the company) probably views this issue as a feature,
not a bug. This issue ties people to a single central repository and
makes migration nearly impossible, at least for non-wizards. Which is
basically their business
Package: git-lfs
Version: 3.0.2-1
Severity: wishlist
X-Debbugs-Cc: none, Barak A. Pearlmutter
I have a repo whose only remote is on a gitlab instance. I'm using
git-lfs to manage large binary files in this repo. The remote goes down.
Now "git add foo.pdf / git commit", when *
Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
When "convert foo.png foo.eps" gets a security error, it leaves an empty
foo.eps.
/usr/bin/convert should not generate incorrect output files. If the
output cannot be correctly generated, the output file should be
UPDATE!
I've merged and pushed mods for the even-newer just-released upstream
version 3.0, which removes the need for running with privs entirely.
Package: usbview
Version: 2.0-21-g6fe2f4f-2.1
Mark,
There's a new upstream version, 2.2, which addresses those security
CVEs and fixes some other problems, and upstreams a bunch of Debian
mods, and has some other improvements and such.
I've taken the liberty of packaging it, and doing some
Package: imagemagick-6.q16
Version: 8:6.9.11.60+dfsg-1.3
Severity: normal
/usr/bin/convert should not generate incorrect output files. If the
output cannot be correctly generated, the output file should be removed.
The current behaviour is a problem when convert is used in a Makefile,
where the
Seems to work!
Thanks for the bug report.
I'm unable to replicate this with some other PDF file using version 4.5.0-3.
Could I trouble you to upgrade to the version in testing and see if it
still happens?
And if so, I need details: a particular PDF file it does this on, and
also info about the environment:
Great!
Just for a bit of eye candy, here's what it looks like in use:
$ systemctl --user status fetchmail.service
*●* fetchmail.service - Fetchmail Daemon
Loaded: loaded (/home/barak/.config/systemd/user/fetchmail.service;
enabled; vendor preset: enabled)
Active: *active (running)*
Agreed: it would probably make sense for these systemd support
materials to go upstream. (Modulo approval, smoothing off rough edges,
etc.)
Let me know if there's anything I should do to help.
I've written a unit so I can run fetchmail under systemd as a user service.
I'd suggest that the file /usr/lib/systemd/user/fetchmail.service (see
below) be included in the package.
It would also make sense to describe how to actually enable it, by
putting something like the following into
It looks to me like the pcre3 dependency in the terminus package is
entirely due to its use of valac and other build support. There
doesn't appear to be any direct use, except in a build dependency.
If I remove that build dependency, libpcre3-dev is still pulled into
the build environment, due to
Lovely.
After a quick look through that discussion, it seems that the "right"
thing to do is install into whatever
$ pkg-config systemd --variable=systemdsystemunitdir
gives, and one day that will swizzle but there's no need to worry about it.
And in the meantime, no need to pollute pre/post
Thanks for the report, Paul.
Wow, that's annoying! I'd assumed debhelper had some dh_ thing in
its pipeline that automatically noticed .service files being installed
in the relevant places and emitted pre/post code to tickle systemd
appropriately, or that dpkg would trigger on the .service
Looks like this is not necessary?
Package: ftp.debian.org
Severity: normal
Upstream no longer supports building for i386. Well, trying to build
on i386 runs out of memory, and upstream no longer releases i386
binaries, so I'm taking that to mean i386 support is kaput.
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it, using autoconf 2.71. Could you check if the current
version still exhibits the problem?
This doesn't seem like an autoconf issue, as the problem crops up
post-configuration. Unless I'm missing something. And, I'm unable to
reproduce it. Could you check if the version I just uploaded still
exhibits the problem?
Package: deborphan
Version: 1.7.33
The last line of "deborphan --help" is not terminated: no final EOL, aka
NL, aka 0x0A, aka C-j.
$ deborphan --help | tail -1 ; echo '***UNTERMINATED LINE***'
See also: deborphan(1), orphaner(8)***UNTERMINATED LINE***
Okay, I used a git snapshot for the version and tarball, and all seems well.
1 - 100 of 793 matches
Mail list logo
