Package: libpcre2-dev
Version: 10.42-4+b1
Severity: wishlist
Hey.
Currently, general purpose manpages like pcre2pattern(3) are also
in libpcre2-dev.
IMO it would make sense to either ship them in a -doc package or
perhaps at least one of the lib packages?
Thanks,
Chris.
Hey.
Just a note:
In 2019, tsmuxer has been released under Apache 2.0 license.
See https://github.com/justdan96/tsMuxer .
Cheers,
Chris.
Package: bash-completion
Version: 1:2.13.0-1
Severity: wishlist
Hey.
2.14.0 is out which allegedly fixes the bug[0] that remote scp file
completion was no longer working.
Thanks,
Chris.
[0] https://github.com/scop/bash-completion/issues/1157
Hey.
Seems there were at least a series of commits from upstream last
November and few again this January.
And there even seem to be some more in their dev branch.
The number of CVEs mentioned by Salvatore is worrying, but it looks
even much worse over the years for ntfs-3g:
On Sat, 2024-04-27 at 03:15 +0200, Guilhem Moulin wrote:
> Yup that'd make sense to me (and I see you did that already), thanks!
:-)
Unfortunately I doubt it will be possibly to do some fully generic
solution.
So best we'll get is probably either an unconditional inclusion or some
simpler
Control: reassign -1 initramfs-tools
Control: severity -1 important
Control: retitle -1 copy_exec doesn't detect libgcc dependency anymore when
pthread is used
Hey.
I think I found the root cause (thanks to Guilhem Moulin, who
pointed[0] me to it).
Apparently (which wasn't on my radar at all
On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> built using glibc ≥2.34. AFAICT the “if the ldd output includes
> libpthread then run copy_libgcc()” logic from initramfs-tools is
> mostly moot
> now
Ah, I just realised glibc "merged" libpthread ^^
Therefore...
> but despite what I
Hey Guilhem
On Sat, 2024-04-27 at 01:48 +0200, Guilhem Moulin wrote:
> Even it weren't, libpthread wouldn't show up since src:argon2 from
> bookworm
> and later is built using glibc ≥2.34.
When argon2 builds, it uses -pthread ... not really sure what that does
exactly, the manpage merely says it
Package: argon2
Version: 0~20190702+dfsg-4+b1
Severity: wishlist
Hey.
I stumbled over some odd issue, originally described here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068849#84
In short:
I use the argon2 tool inside the initramfs, into which I copy it via
initramfs-tools’
Hey guys.
I kinda ran into a similar issue.
I use my own OpenPGP keyscript which is highly improved upon that
("decrypt_gnupg") shipped by the package.
One thing that I do is offer optionally feeding the entered passphrase
trough argon2 (the standalone tool from the package of the same name)
Hey.
Just upgraded (via aptitude) to the most recent apt in sid on a number
of nodes (this time, all *without* any Icinga/Prometheus stuff)... and
on all nodes the locking issue showed up:
# aptitude
Performing actions...
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
On Sat, 2024-04-20 at 07:54 -0400, P. J. McDermott wrote:
> Then the salvage procedure can play out for the full 28+ days
> specified
> by developers-reference (21 days to allow the maintainer to object
> followed by a DELAYED/7 adoption upload). I've already soft-proposed
> to
> salvage in bug
Hey.
On Sun, 2024-03-31 at 01:46 +, Thorsten Glaser wrote:
> Yes, a multi-team task force is working on it and will inform users
> once it is known how to proceed, inclusing how much to throw away
> and rebuild.
Kindly wanted to ask whether anything has come out meanwhile of that?
I've
Package: ca-certificates-java
Version: 20230710~deb12u1
Severity: important
Hey.
Actually I think this should have a higher severity, since the
trusted certs may very well be quit security critical.
Nevertheless:
I just traced a bug for some hours, where it eventually turned out
that
Hey David.
Thanks for your elaborate mail
On Wed, 2024-04-17 at 21:55 +0200, David Kalnischkies wrote:
> > Unpacking util-linux-extra (2.38.1-5+deb12u1) over (2.38.1-5+b1)
> > ...
> > Setting up util-linux-extra (2.38.1-5+deb12u1) ...
> > dpkg: error: dpkg frontend lock was locked by another
On Thu, 2024-04-18 at 00:34 +0200, Santiago Vila wrote:
> >
> I think you might be overestimating the importance of this.
Well I haven't said it would be super important (not at least that the
dirs are created - what might be more important is, if e.g. owners are
changed, like when stuff was
On Wed, 2024-04-17 at 23:43 +0200, Santiago Vila wrote:
> Yes. An empty $2 means that the package is installed for the
> very first time, i.e. installed by debootstrap.
>
> This is actually explained in the last question here:
>
> /usr/share/doc/base-files/FAQ
Isn't that quite unfortunate?
It
Hey.
FYI: I have upgraded to 13.1, but still didn't get a
/usr/local/libexec.
Guess that's because $2 in the script is not empty?
Cheers,
Chris.
btw: There already is #586486 but to me it looked rather like a
different issue.
Package: xserver-xorg-core
Version: 2:21.1.12-1
Severity: wishlist
Hey.
Joking:
" Debin's xorg lacks critical security patches, I demand make me maintainer
immediately "
Too soon for XZ jokes? O:-P
Seriously, there's a new upstream version out (21.1.13), which incorporates
not only the fix
Package: aptitude
Version: 1.21.22
Severity: important
Hey.
May very well be an issue in APT or rather dpkg, still, since I always see it
from aptitude, I report it here. Please re-assign accordingly.
I'm seeing this since quite some releases and also every now and then in
unstable
(though
Package: less
Version: 590-2
Severity: wishlist
Hey.
Less 590 is quite outdated (from somewhere mid 2021)... would be
nice to have the current version. There's been quite some changes
meanwhile including improvements to follow mode.
Cheers,
Chris.
Hey.
I mostly forgot the details of this issue ^^
On Mon, 2024-04-15 at 13:08 +0200, Santiago Vila wrote:
> I'd like to be sure that things will not break horribly
> for somebody.
What I can say at least (which is of course not a definite answer) is,
that I personally run my systems since quite
Hey.
There seems to be a somewhat similar issue reported by Jakub Wilk on
oss-security:
https://www.openwall.com/lists/oss-security/2024/04/12/5
where quoting causes troubles (though I couldn't replay the demo).
Any chance to get both fixed in Debian unstable?
Cheers,
Chris.
On Thu, 2024-04-11 at 22:12 +0200, Julian Andres Klode wrote:
> > => First, I'm not sure whether this is the right behaviour, as
> > the
> > "original/modified" file seems to get removed, but it - being
> > a
> > local file - may actually be something of value to the user.
> > So
Source: vobcopy
Version: 1.2.1-4
Severity: minor
Hey.
The site listed in the homepage field:
Homepage: http://vobcopy.org
seems dead and links eventually to some (I guess) Turikish football website.
Should perhaps be removed and replaced with the github repo:
Package: apt
Version: 2.7.14
Severity: normal
Tags: security
Hey.
I noted the following behaviour - which may or may not be regarded as
security relevant.
So this is rather a heads up, and in case you think it's fine as it is,
just close it.
I always remembered that apt-get source was ought to
Hey.
Also with respect to having this documented in the release note, you
may want to have a look at my comment:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065806#47
I.e. I think it might be usefull to not just indicate that/how people
may use "nousergroups" again, but also to refer to
My I suggest one further improvement:
I think it would be nice if there was a sentence like:
"See the pam_umask(8) manpage for alternative means to change the
UMASK, for example per-user only."
I guess there are users that would actually want to keep the new
default, but have it e.g.
Hey Sam.
There's a typ in the NEWS enty:
>this user a group name that differs from the user name or add
|
should probably be "use"
Also, I had to think twice what's meant by "pat" ;-)
> matches their primary user name (user pat's default group is also
>called
One more thing:
Is anyone on the Debian side trying to figure out how far we've been
practically affected?
I mean let's assume we're "lucky", and the backdoor is only in
5.6.0/5.6.1... and that none of the adversary's earlier commits
introduced any serious holes[0] which wouldn't be known yet.
Hey.
Can we be confidently sure that going back to 5.4.5 is enough?
At least the git tag for that seems to be still signed by the
adversary:
https://git.tukaani.org/?p=xz.git;a=tag;h=9e4835399118b98954f110f76af2a0d504d2f531
The last one, still from Lasse Collin seems to be 5.4.1:
Source: pam
Version: 1.5.3-6
Severity: normal
Hey.
Somwhere in between 1.5.2-9.1+b1 and 1.5.3-6 the default umask for non-root
users has changed from 0022 to 0002.
Interestingly, root doesn't seem to be affected.
Intially I suspected b01196659c785b04abc387d324fae61e2ec3b1aa, but at least
when
On Sat, 2024-03-09 at 16:06 -0600, bigops wrote:
> The crypttab which is part of the cryptsetup package in its man page
> does not include the option _netdev. _netdev is required for
> unlocking Luks volumes via Clevis/Tang.
>
> Confirmed that the block device is not unlocked without this option
On Thu, 2024-02-29 at 13:31 -0700, Sam Hartman wrote:
> > > > >
> I tried to make the revert work either if you didn't have libpam0t64
> at
> all or if you did, but we're more focused on people who never
> upgraded.
>
> If you do run into breakage, we'll work with you to find a solution.
I
Hey.
On Thu, 2024-02-29 at 20:37 -0800, Steve Langasek wrote:
> Thanks for this report.
Another case:
Removing libreadline8:amd64 (8.2-3+b1) ...
awk: error while loading shared libraries: libreadline.so.8: cannot open shared
object file: No such file or directory
awk: error while loading
Package: libssl3t64
Version: 3.1.5-1.1
Severity: normal
X-Debbugs-Cc: vor...@debian.org
Hey there.
Just a friendly meant heads up:
I saw another case similar to #1065017, i.e. where during the t64 transition.
a library is missing while sort (which I think is also considered essential?) is
On Fri, 2024-02-23 at 08:09 +0100, Niels Thykier wrote:
> > Against what would one file such request? ftp.debian.org?
> That would be my best guess indeed.
Done so in #1065123.
Cheers,
Chris.
Package: ftp.debian.org
Severity: wishlist
Hey there.
Currently, AFAIU, the Contents file contains a list of all files in each package
mapped to section/packagename, with different files per arch.
This is unfortunately still not enough to provide exact package lists as e.g.
done
by apt-file,
On Thu, 2024-02-29 at 13:30 +, Simon McVittie wrote:
> The advice for "end users" would be don't run unstable or
> experimental,
> and wait for maintainers to fix release-critical bugs like this one
> as
> they are detected.
Well "end user" is a broad range :-)
I guess quite some people do
On Thu, 2024-02-29 at 08:14 +0100, Helmut Grohne wrote:
> Can you locate a more complete upgrade log?
Attached is the excerpt from APT's term.log, if that helps.
Cheers,
Chris.
term.log.xz
Description: application/xz
On Thu, 2024-02-29 at 08:50 -0700, Sam Hartman wrote:
> > > > >
> Steve and I agreed to revert the rename on IRC, effectively
> accepting
> the ABI break because it doesn't matter for the archive.
> We may look at better solutions when we have a bit of time.
Do you happen to know whether
Hey Simon.
On Thu, 2024-02-29 at 10:33 +, Simon McVittie wrote:
> Yes, the workaround for this is to reinstall any package that carries
> GSettings schemas. gsettings-desktop-schemas is a common one, but
> actually
> any package that has files in /usr/share/glib-2.0/schemas/ should be
>
On Thu, 2024-02-29 at 06:53 +0100, Paul Gevers wrote:
> Well, officially downgrading isn't supported (although it typically
> works) *and* losing files is one of the problems of our merged-/usr
> solution (see [1]). I *suspect* this might be the cause. We're
> working
> hard (well, helmut is)
On Wed, 2024-02-28 at 21:57 -0800, Steve Langasek wrote:
> Furthermore, this is a downgrade from a replacing package to a
> replaced
> package. Unless you also --reinstall the package at the end, missing
> files
> are quite to be expected.
Shouldn't that case be something that DPKG could detect
Attached is the aptitude log.
Cheers,
Chris.
Aptitude 0.8.13: log report
Thu, Feb 29 2024 02:17:21 +0100
IMPORTANT: this log only lists intended actions; actions which fail
due to dpkg problems may not be completed.
Will install 83 packages, and remove 21 packages.
471 kB of disk space will
Package: libglib2.0-0t64
Version: 2.78.4-2
Severity: critical
Justification: breaks unrelated software
X-Debbugs-Cc: debian-de...@lists.debian.org
Hey.
CCing d-d since there seems some further deeper problem with the t64
transition (namely lib files getting lost, when "downgrading" i.e.
Source: pam
Version: 1.5.3-4
Severity: normal
Hey.
During upgrade to 1.5.3-4 I got:
Removing libpam0g:amd64 (1.5.2-9.1+b1) ...
runuser: error while loading shared libraries: libpam.so.0: cannot open shared
object file: No such file or directory
Guess there may be some timing issue, when
Package: dash
Version: 0.5.12-6
Severity: normal
Tags: upstream
Hey.
POSIX describes[0] unset to:
> unset values and attributes of variables and functions
While the exact detials are perhaps a bit unclear (see the discussion at [1], I
think it is rather clear that unset, on a variable that has
Source: dvdbackup
Version: 0.4.2-4.1
Severity: minor
Hey.
The Vcs-* package fields and perhaps also Homepage (the SF site and
repo there seems even more outdated compared to launchpad) may be
outdated.
Cheers,
Chris.
On Thu, 2024-02-22 at 08:59 +0100, Niels Thykier wrote:
> One challenge we have here is that a package can have multiple
> versions
> in a given suite at the same time; notably in unstable.
And multiple arches...
> For people that want better support here, please request the archive
>
Hey.
I took the liberty to forcemerge these two bugs (578727 and 525813) as
they seem to be about the same thing.
My suggestion would be that per default, the apt-file should print the
package name with =version.
Perhaps with the exception if only one version is available (or maybe
there should
Hey Guillem.
On Fri, 2024-02-16 at 05:26 +0100, Guillem Jover wrote:
>
> Thanks!
Well rather: thank you, for your constant efforts to DPKG and the whole
ecosystem.
> > At least it seems to make it impossible to definitely find out
> > whether a package
> > is not installed (respectively not
Package: dpkg
Version: 1.22.4
Severity: normal
Hey.
dpkg-query manpage says:
EXIT STATUS
0 The requested query was successfully performed.
1 The requested query failed either fully or partially, due to no
file or package being found (except for
Source: cryptsetup-nuke-password
Version: 4+nmu1
Severity: wishlist
Hey.
I think the description should add some important details:
*If* a sufficently advanced 3-letter-government organisation would seize
someone’s computer,
it's rather unlikely that the idea of wiping the master keys with a
Hey.
I've just force pushed the PR[0] over at salsa, which:
- Rebased the patchset on current master.
- Also fixed a bug in the previous a36873c2, where the IFS= was not
just wrong (it would have needed to be IFS=' ' but also ineffective,
as it wouldn’t be used for the expansion of $*.
The
Control: tags -1 + patch
Hey Dylan and people from the multimedia team.
I'd have made a PR at:
https://salsa.debian.org/multimedia-team/libaacs/-/merge_requests/2
which packages the already built aacs_info in a new libaacs-bin
package.
Would be nice if this could be reviewed, merged and a new
On Tue, 2024-01-16 at 09:47 +0100, Matteo Bini wrote:
> for
> instance if it's fine to make as many DEB packages as the source
> tarballs CDEmu is divided in.
Probably best if you ask at the mentors mailing list. But I'd guess
it's totally fine.
Though I'd personally probably keep everything in
Hey Matteo.
Are you still working on packaging CDemu for Debian?
If not, Robert Ayrapetyan indicated interest in taking the ITP over:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237925#84
Cheers,
Chris
Package: openjdk-17-jre-zero
Version: 17.0.9+9-2
Severity: normal
Hey.
Since upgrading the other OpenJDK packages to 17.0.10~6ea-1,
openjdk-17-jre-zero is uninstallable.
Cheers,
Chris.
Package: git-delta
Version: 0.16.5-5
Severity: normal
Control: forwarded -1 https://github.com/dandavison/delta/issues/1593
Hey.
It seems delta alone fails to run when git is not installed.
$ touch 1 2
$ delta 1 2
Failed to execute the command 'git': No such file or directory (os error 2)
$
Package: debian-reference
Version: 2.109
Severity: normal
Hey.
Something looks odd with the package’s files registration in Debian.
On upgrade from 2.108 to 2.109 I got:
Unpacking debian-reference-common (2.109) over (2.108) ...
dpkg: warning: unable to delete old directory
Hey Paul.
AFAICS, this works now in at least the version as of sid.
Can we close this issue?
Thanks,
Chris.
Hey.
Few weeks ago I've again stumbled over this, and tried to fix it, but
my Qt coding skills are worse than absolutely zero ^^
I did however found e.g. this:
https://gitlab.cs.fau.de/rudis/passt-mac/-/commit/00d4f8fc2c729b1baf723cacd2b5942b032b6784
which seems a commit that fixes a similar
Hey John.
On Wed, 2023-12-06 at 09:17 +0100, John Paul Adrian Glaubitz wrote:
> I am naturally aware of the new release because I am in direct
> contact with
> one of the upstream maintainers. The withheld update to 2.x is
> intentional
> for two reasons.
Ah I see. :-)
Then I wrongly thought
Package: python3-ntp
Version: 1.2.2+dfsg1-3
Severity: normal
Hey.
When upgrading to the current version, I got.
Setting up python3-ntp (1.2.2+dfsg1-3) ...
/usr/lib/python3/dist-packages/ntp/util.py:641: SyntaxWarning: invalid escape
sequence '\]'
m = re.match("([:.[\]]|\w)*", inhost)
a weakness of mine), re-implemented it properly.
PS: I'm attaching the patch series here, too, though I guess I'd prefer
to discuss things on salsa/Gitlab.
>From 4091b4a3c12d8ef98fd949d09ab53d9dfaaf6efa Mon Sep 17 00:00:00 2001
From: Christoph Anton Mitterer
Date: Sun, 10 Dec 2023 05:23
On Sun, 2023-12-10 at 01:23 +0100, Pali Rohár wrote:
> There is also beta version of udffsck for udftools:
> https://github.com/pali/udftools/pull/7
Ah nice. Is that going to be released/packaged?
Thanks,
Chris
Hey.
FIY: It seems netbsd developed a fsck for UDF[0], but it would require
porting to LInux.
Cheers,
Chris.
[0] https://wiki.netbsd.org/projects/project/fsck_udf/
Hey.
Just for the records:
At least as of now, ssh no longer seems to add the multiple 0x0 to it's
cmdline.
But I guess the "problem" (should it ever come back or exist for other
programs) in pgrep/pkill still remains.
Cheers,
Chris.
Package: ausweisapp2
Version: 1.26.7-2
Severity: wishlist
Hey.
A new upstream major version (2.x) is out, and they've apparently also
rebranded it back to just "AusweisApp" (i.e. no longer a 2 in the name).
Cheers,
Chris.
Source: libaacs
Version: 0.11.1-2
Severity: wishlist
Hey.
Upstream contains the aacs_info program at:
src/examples/aacs_info.c
would it be possible to build and package that (e.g. as libaacs-tools or so),
too?
Thanks,
Chris.
On Sun, 2023-11-26 at 15:52 +1100, Dmitry Smirnov wrote:
> https://salsa.debian.org/debian/smartmontools/-/commit/625f38bc
Thanks :-)
And sorry again for the noise and not having checked --install in
detail before reporting.
Cheers,
Chris
Hey Paul.
On Sun, 2023-11-26 at 11:01 +0800, Paul Wise wrote:
> BTW Chris, I imagine you might have some issues for this page:
>
> https://wiki.debian.org/PrivacyIssues
In which respect?
AFAICS that page is mainly about privacy (in the sense of calling
home).
My main concern is rather
Package: duperemove
Version: 0.11.2-3
Severity: wishlist
Hey
Debian’s 0.11.2 is older than 2 years. 0.14.1 is out with many changes.
Thanks,
Chris.
Control: severity -1 normal
Control: tags - security
Hey.
On Sun, 2023-11-26 at 12:23 +1100, Dmitry Smirnov wrote:
> I think you misunderstood that invocation of `update-smart-drivedb`
> in postinst is an equivalent of
>
> ```
> cp -f /usr/share/smartmontools/drivedb.h
>
If you really insist on having that functionality, wouldn't it be
anyway better to:
- Add a systemd.timer that regularly (perhaps weekly?) calls
update-smart-drivedb instead of doing it only once in postinst,
where it's unlikely to be of much use, because the package was just
upgraded, so
Package: smartmontools
Version: 7.4-1
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: Debian Security Team
Hey.
The most recent upgrade forces people to use
update-smart-drivedb by doing it already in the postinst and not leaving it
up to the user whether he wants
Package: sshfs
Version: 3.7.3-1.1
Severity: normal
Hey.
The following problem persits also in unstable.
Doing the following fails:
# mount foo.example.org:/ /mnt -t fuse.sshfs -o setuid=someUser,furtherOptions
fuse: unknown option(s): `-o setuid=someUser'
Whereas it does work if one calls
Just for the records:
There's now a fix for this at:
https://github.com/systemd/systemd/pull/30074
(which I confirmed working)
>From my side it's not super important to have that cherry picked.
I'd hope it might still make it into 255, so for that I can easily wait
and it saves you guys some
Control: forwarded -1 https://github.com/systemd/systemd/issues/30083
On Fri, 2023-11-17 at 13:48 +, Luca Boccassi wrote:
> Please open an issue on github and attach debug level logs showing
> the
> error
Done.
Cheers,
Chris.
On Fri, 2023-11-17 at 15:37 +0100, Michael Biebl wrote:
> downgrades are not officially supported by Debian.
Sure... and if it's not fixable... well then it's not. But at least it
would be better then to abort the downgrade if it's detected that e.g.
a DE is running.
In my case it didn't matter
On Fri, 2023-11-17 at 08:40 +0100, Bastian Venthur wrote:
> If bash completion is not enabled on purpose, I would
> consider this behaviou a bug. But I believe just enabling the bash
> completion
> by default would be the better solution.
In any case, please do not enable the fzf-completion (i.e.
Package: systemd
Version: 255~rc2-1
Severity: normal
Hey.
The following two issues are both solved when downgrading to 254.5-1 (and
completely
rebooting the system, before trying again - they also shop up again, only after
completely rebooting the upgraded systemd again):
1) I have a somewhat
Package: debhelper
Version: 13.11.7
Severity: wishlist
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org
Hey there.
Would it make sense and be possible for the systemd debhelper programs to
support systemd generators?
I think of something like just copying the file to the right
Hey.
Upstream has released 6.6.1, which contains an important fix.
6.6 should not be used, see:
https://lore.kernel.org/linux-btrfs/20231105222046.19483-1-dste...@suse.com/T/#u
Cheers,
Chris.
Package: btrfs-progs
Version: 6.3.2-1
Severity: wishlist
Hey.
6.6 is out ad 6.3 is rather outdated now :-)
Cheers,
Chris.
Package: webext-ublock-origin-firefox
Version: 1.52.0+dfsg-1
Severity: wishlist
Hey.
1.53.0 is out since a few days :-)
Thanks,
Chris.
FYI: Ubuntu is apparently also consider to add this:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24#issuecomment-1768955946
Cheers,
Chris.
Hey.
Seems a new upstream version is out:
https://github.com/strukturag/libheif/releases/tag/v1.17.0
Cheers,
Chris
Package: openssh-client
Version: 1:9.4p1-1
Severity: wishlist
Hey there.
I've recently filed:
https://github.com/openssh-gsskex/openssh-gsskex/issues/24
(not sure whether this is actually the current upstream, if there's
any at all, of Debian's GSSAPI patch).
In short, the problem is, that the
Hey Jeremy
It seems everything is now fixed upstream (see
https://github.com/strukturag/libheif/issues/974).
But upstream also said[0] a new release might follow in the next
days,... so I guess you don't really need to cherry pick the various
commits that were now necessary.
[0]
Hey Unit 193.
Just a heads up:
I recently filed https://github.com/yt-dlp/yt-dlp/issues/8193 and it
was implemented via:
https://github.com/yt-dlp/yt-dlp/pull/8205
So in future versions you can drop the Recommends on:
python3-xattr | python3-pyxattr | attr
probably altogether.
Thanks,
Hey Jeremy
On Sat, 2023-09-30 at 05:39 -0400, Jeremy Bícha wrote:
> I pushed my change to the wip/10421242 branch of
> https://salsa.debian.org/multimedia-team/libheif if someone wants to
> do a test build.
I finally came around testing this.
1) building (with all build-deps installed)
Thanks for fixing this, Jonathan. :-)
Cheers,
Chris.
Hey.
On Fri, 2023-09-29 at 20:13 -0400, Jeremy Bícha wrote:
> Please install pipewire-audio instead of pipewire directly.
a) That still leaves the problem of other processes freezing?
b) Shouldn't other packages, which now depend on
pipewire-pulse|pulseaudio, then rather depend on
Package: pipewire
Version: 0.3.80-2
Severity: normal
Hey there.
Recently, cinnamon-settings-daemon in version 5.8.1-2 started to prefer
pipewire(-pulse) over pulseaudio, so I thought cinnamon would be ready
for it and gave it a try.
That is, I've installed pipewire (and pipewire-pulse) but no
Package: firefox
Version: 118.0-1
Severity: wishlist
Hey.
Numerous packages have started to suggest:
pipewire-pulse | pulseaudio
(or vice versa).
It seems firefox also works with pipewire-pulse, so maybe firefox should adopt
the same alternative?
Thanks,
Chris.
Hey folks.
I filed an issue upstream at:
https://github.com/junegunn/fzf/issues/3457
which describes the situation leading to this bug and discusses
possible solutions.
The main problem is IMO, that right now, fzf's completion.bash file
contains both, code for:
a. completing options for fzf
Just for the records:
The workaround I've proposed before (using something like
/etc/bash_completion.d/fzf) may not be the best way either.
I'm looking into what should be done (see also discussion
at https://github.com/scop/bash-completion/issues/1055), but perhaps
the ideal solution would
1 - 100 of 3909 matches
Mail list logo
