Well, it's in the configure.ac script already so I'll just leave in
there and maybe someday it will work.
rable to aliasing.
Cheers,
--Barak.
On Tue, 7 Jan 2025 at 16:27, Andreas Tille wrote:
>
> Hi Barak,
>
> thanks a lot for your bug report against routine-update. Any hints for
> potential enhancements are perfectly welcome.
>
> Am Mon, Jan 06, 2025 at 09:39:00PM + sch
Package: routine-update
Version: 0.2.2
Instead of using the appropriate git commands, routine-update seems to
check if there is a .git/config file or something like that. But git
submodule will place a text file .git with a pointer to the gitdir in
it, as below.
$ ls -ld .git
-rw-rw-r-- 1 barak b
Xiao Sheng,
Thanks for testing that -mabi=ilp32f patch.
wuruilong (and other loong folks),
Here is what the build log says:
> configure:5169: gcc -o conftest ... -mabi=ilp32f ... conftest.c ...
> gcc: error: unrecognized argument in option '-mabi=ilp32f'
> gcc: note: valid arg
I would suggest that the "right" way to handle this is to use
update-alternatives, and have /usr/bin/transmission-remote-gui have at
least three alternatives:
- /usr/bin/transgui
- /usr/bin/transmission-remote-gtk
- /usr/bin/tremotesf
and for all these to "Provide: transmission-remote-gui".
This
I've NMUed libcpuid (+5 day delay) and cpu-x (+7 day delay) to get
these off my desk. The newer upstream versions really are necessary
for modern machines, and a freeze is lurking. Feel free to cancel, of
course...
Cheers,
--Barak.
Package: libcpuid
Version: 0.6.5+repack1-1
There is a new upstream version, 0.7.1, and 0.7+ is required by the
new upstream version of cpu-x. I've done a prelim packaging and pushed
it to the master branch of
https://salsa.debian.org/bap/libcpuid
I updated the symbols file with three (3) new sym
Thanks for checking so diligently.
Package: cpu-x
Version: 5.0.4-1
I've done a prelim packaging of the new upstream version 5.1.1 on a
fork of the maintenance repo, https://salsa.debian.org/bap/cpu-x
Fixed the libpci bug while I was at it.
Seems to work fine on a few of my machines, the GPU issue is fixed,
and upstream put the da
I'm having trouble analyzing this issue.
$ env EDITOR=J-Jonah-Jameson blackbox-terminal --command 'printenv
EDITOR > editor'
$ cat editor
J-Jonah-Jameson
As you can see, blackbox-terminal does not fiddle with $EDITOR. The
string "EDITOR" does not appear in the source code.
I'd conjecture your $E
I am unable to reproduce this bug. It's a timing thing (fails if
something is too fast), so might fail if the machine is too fast, or
if the accounting on CPU time is off due to other threads and cache
misses not being counted against the right thread, or something like
that. In any case, I've lowe
Package: transmission-remote-gtk
Version: 1.5.1-1
Upstream has released version 1.6.0 and I've done a tentative packaging.
https://salsa.debian.org/bap/transmission-remote-gtk.git
branch: debian
This is based on 1.5.1-1 (via debsnap; could not find this in any
accessible git repository), with mi
To give an example of where this is needed, the package
microsoft-edge-beta
available from the non-debian repo
$ cat /etc/apt/sources.list.d/microsoft-edge-beta.list
deb [arch=amd64] https://packages.microsoft.com/repos/edge/ stable main
installs an alternative:
$ update-alternatives --display
This is an upstream issue.
That said, there are really two problems. First, the executable cannot
be built without any graphics support. Second, it cannot be built
without WX support, using direct X11 instead. These are both upstream
issues.
This means that it isn't possible for me to work around
Yeah, I think the github-backup package can go away. It suffers from
sufficient bit-rot so as to be basically unusable.
And there are other tools in the space.
There is a python-based alternative that actually works and is
actively maintained,
https://github.com/clockfort/GitHub-Backup
and an alt
Okay, I'll forward it upstream.
Package: latexmk
Version: 1:4.85-1
Severity: wishlist
Thanks for maintaining latexmk, which I love! I'm a total convert,
proselytizing all my LaTeX-using friends to abandon crufty Makefiles
with multiple idiosyncratic invocations of pdflatex, mkindex, etc, and
just use latexmk.
The one big fly in
Thanks for the bug report & patch.
Have merged it in git repo on salsa.
But there are so many mods in-tree I will probably just move it to be
a regular commit.
Anyway, planning to upload as soon as I create a pkgconfig .pc support
file, since the /usr/bin/libmcrypt-config it comes with is pretty
c
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 b
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 you,
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 softwar
ahead 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
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 s
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, synapt
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_')
It's great that people are using Xournal++, and care enough about it
to be bothered by this!
These are coming from libsndfile1. Many Linux GUI programs do output a
constant stream of harmless warnings, and Xournal++ is hardly the
worst offender. The "right" fix is presumably to tell libsndfile1 (t
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 2.0.2
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 da
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 mu
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 things
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
/usr/games/pacman
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 "/usr/gam
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".
Package: minidlna
Version: 1.3.2+dfsg-1.1
Severity: wishlist
I've done a packaging of the new upstream release, 1.3.3, in branch
master of https://salsa.debian.org/bap/minidlna forked from the
debian/minidlna repo, which also includes a quick update of the
packaging scripts for things like enablin
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 through
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. (Als
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 theref
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
Package: duplicity
Version: 0.8.22-1+b3
Upstream has shifted to a new homepage and development repo, and is up
to 1.2.2 as of Jan 2023. I've prepared a preliminary packaging of the
latest release, as a series of commits on top of the
salsa.debian.org/debian/duplicity repo, in a fork of that repo,
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 collecti
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 go
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 v
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
(84)
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 featu
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 bit
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
libtra
> >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. P
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, 0x7f432a757
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. Ple
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 bounci
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 rygel.service
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 or
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 front
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 maint
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 enjoy
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 libappin
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 a
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 mo
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
1 - 100 of 811 matches
Mail list logo
