Re: Following Pipewire developments
Hello, everybody out there! On 2021/11/09 at 05:06 am, riveravaldez wrote: Sorry if late and obvious, but just in case, have you already checked this? https://wiki.debian.org/PipeWire#Debian_Testing.2FUnstable Yes, I have read the Wiki. However, I am disinclined to use unstable repositories into Debian stable. Thank you anyway. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: Following Pipewire developments
On 11/8/21, Yoann LE BARS wrote: > > Hello, everybody out there! > > On 2021/11/08 at 2:39 pm, Henning Follmann wrote: >> The easiest way to get a current version of pipewire is >> to install fedora core. > > Yes, this is something I have considered. I have already tried and use > Fedora, but I prefer Debian in general. Sorry if late and obvious, but just in case, have you already checked this? https://wiki.debian.org/PipeWire#Debian_Testing.2FUnstable Kind regards and good luck!
Re: Following Pipewire developments
Hello, everybody out there! On 2021/11/08 at 2:39 pm, Henning Follmann wrote: The easiest way to get a current version of pipewire is to install fedora core. Yes, this is something I have considered. I have already tried and use Fedora, but I prefer Debian in general. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: Following Pipewire developments
Hello, everybody out there! Thank you for the answer. On 2021/11/08 at 2:08 pm, Charles Curley wrote: Do you know that the version in Bullseye will not work? Have you tried it? No, I have not tested it yet. I thought I would rather get some information first. You could pull in the package for Bookworm or Sid and try installing that. "apt pipewire." But if the installation breaks, you get to keep all the pieces. Yes. I am not really found in breaking my distro! You could also try pulling it in from the git repo and installing that. https://pipewire.org To be consistent with Linux standards, I would set --prefix=/usr/local It appears Ardour and Musescore are available as Debian packages, although neither is the most recent version. That suggests that one or both will build easily on Debian. I would consider building them from source. Then you can bypass the flatpack entirely. Well, concerning Ardour, it is not that easy to compile. Best regards. -- Yoann LE BARS https://le-bars.net/yoann/ Diaspora* : yleb...@framasphere.org
Re: [OT, deeply] Guix
On Mon, Nov 8, 2021 at 9:55 AM Curt wrote: > On 2021-11-08, David Wright wrote: > >> >> In contrast, with NixOS/Guix that list is available in a plain text > >> >> editable file. > > > > I'm not sure I'd call scheme a "plain text". Or do you mean something > > other than the file that commences with: > > > > (operating-system > > ;; ... > > > >> > in Debian there is /var/lib/apt/extended_states > >> > > I thought plain text meant "a pure sequence of character codes" without > any formatting information attached to it (e.g. HTML) or something. As > Here's the thing. We already have many ways to install debian and any other kind of linux-like OS in a completely declarative way. We don't need to learn a programming language to do it. Here are some of those ways: Saltstack, Puppet, chef, ansible, AWS Cloudformation, XML And we're at the point where the upfront learning of those tools pays-off later EVEN for single servers and desktops. Cause installation can be a pain sometimes, on slightly oddball platforms especially, your install tool config becomes a backup mechanism cause your desktop is too big to backup :-) etc. etc. Why not embrace the monster? Ship debian to be autoconfigged, not installed Just thinking out loud :-)
Re: [OT, deeply] Guix
On 2021-11-08, David Wright wrote: >> >> In contrast, with NixOS/Guix that list is available in a plain text >> >> editable file. > > I'm not sure I'd call scheme a "plain text". Or do you mean something > other than the file that commences with: > > (operating-system > ;; ... > >> > in Debian there is /var/lib/apt/extended_states >> I thought plain text meant "a pure sequence of character codes" without any formatting information attached to it (e.g. HTML) or something. As very much opposed to binary, of course. Then again, Wikipedia opines plain text is a "loose term." Anyhow, scheme is probably pretty plain for Stefan because I think he's a Lisp hacker in another life.
Re: [OT, deeply] Guix
On Sun 07 Nov 2021 at 08:58:23 (-0500), Stefan Monnier wrote:
> didier gaumet [2021-11-07 03:16:12] wrote:
> > Le mardi 26 octobre 2021 à 09:25 -0400, Stefan Monnier a écrit :
> > [...]
> >> Think of it this way: currently, you can more or less figure out
> >> which
> >> packages you decided to install on your machine by going through the
> >> list
> >> of installed packages and filtering out all those that are marked as
> >> "automatically" installed.
> >>
> >> But you can only manipulate this list indirectly, via `apt install`
> >> and
> >> `apt remove`.
> >
> > to have the list of all automatically installed packages:
> > # apt-mark showauto
> >
> > to have the list of all manually installed packages:
> > # apt-mark showmanual
> >
> > to verify if the package PACKAGE have been automatically installed
> > # apt-mark showauto $PACKAGE
> >
> > to verify if the package PACKAGE have been manually installed
> > # apt-mark showmanual $PACKAGE
>
> I'm not sure exactly what you mean to say with the above.
> Of course, we can extract some kind of description of the current state
> with APT commands, but it's quite different from having it inside a text
> file that you edit.
>
> The differences include:
>
> - The list is "in your face". When I look at `apt-mark showmanual`, for
> about half of the packages I vaguely remember explicitly installing
> them at some point but don't need them any more, others I'm pretty sure
> I never (consciously) installed manually.
I look at the list of packages I actually installed by using the
command (that I keep up my sleeve):
$ zgrep -i -h -e commandline $(reverse $(sort99 /var/log/apt/history*)) | \
grep -v -e 'upgrade$' -e 'autoremove$' | \
sed -e 's/Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o
APT::Keep-Fds::=6 -q -y --no-remove/[d-i]/;s/Commandline: apt-get -o
APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6
-q/[d-i]/;s/Commandline: apt-get -y/[bas]/;s/Commandline: apt-get/[man]/;' | \
less
(Sorry about the long line.)
It does depend on having sufficient history:
$ grep -A1 log /etc/logrotate.d/apt
/var/log/apt/term.log {
rotate 60
--
/var/log/apt/history.log {
rotate 60
$
The reverse() and sort99() just deal with the sort-order of rotated
logs¹, grep removes uninteresting commands, and the sed filter tidies
the output by taking advantage of the stereotype commands used at
various stages: the installer, my personal list of "base" packages,
and later, casual installs.²
It's not the neatest output, but it would be simple to edit into
a file that could replicate a system, or act as the basis for
installing a new system from the next Debian revision. It certainly
saves having to remember to update my Christensen-style machine log
every time I install a package.
> - The list file naturally lends itself to extensions:
> - It could contain comments, so you could easily remove a package but
> keeping a note about it so it's easy to re-add.
> - It could contain conditional elements, so the same file could be
> used on different machines that need slightly different
> packages installed.
> - It could contain additional information per package, such as whether
> to install the recommended dependencies, some config information so you
> don't get queried during install, some file renamings, a list of
> "overrides" (to ignore a specific dependency and/or allow installing
> officially mutually-exclusive packages), ...
>
> It fundamentally changes the way you think about it, I think.
>
> >> In contrast, with NixOS/Guix that list is available in a plain text
> >> editable file.
I'm not sure I'd call scheme a "plain text". Or do you mean something
other than the file that commences with:
(operating-system
;; ...
> > in Debian there is /var/lib/apt/extended_states
>
> Not a fun read, tho. AFAICT it's just a verbose way to keep the set of
> not-manually-installed packages, so it includes all the info I want to
> be implicit ;-)
>
> Also, regarding "editable", I suspect that if you edit this file by hand
> and introduce an error in there you're probably not going to get much
> support ;-)
I would agree. I did post a script last year that attempted to
construct a list of top-level packages using dpkg-query. (It could be
improved, I'm sure, by someone who knows their way around apt and dpkg
introspection better than I do.) But it's obviously easier to
construct/maintain a list of packages intentionally installed
than to guess/"deduce" it from manipulation of the system's package
list and dependencies.
> > Perhaps (not sure) comparing on each machine the results of
> > # apt-cache unmet
> > could give you valuable info
>
> Thanks, I didn't know about this one.
I'd not met unmet either. I'm not sure whether it meets any
requirement for me. For example, it tells me:
Package parl-desktop-world version 1.9.18 has an unmet dep:
Depends: firefox-esr-l10n-as
Depends: firefox-esr-l10n
Re: Following Pipewire developments
On Mon, Nov 08, 2021 at 08:15:47AM +0100, Yoann LE BARS wrote: > > Hello, everybody out there! > > I am running Debian stable (Bullseye). Now, it turns out I need to use > some > new version of Musescore and Ardour–because of few bugs and several > functionalities I need. As these applications are available as flatpaks, I > can easily use them. The trouble is, to be able to use flatpaks with Jack, I > have to use Pipewire. As Pipewire is quite recent, I probably would rather > use some recent version of Pipewire. > > As far as I know, Pipewire is not available on Backports: > > https://packages.debian.org/search?keywords=pipewire&searchon=names&suite=all§ion=all > > Is there a way to use some recent version of Pipewire with Debian > stable? > > Best regards. I aknow this amounts to heresy saying this in a debian ML But.. The easiest way to get a current version of pipewire is to install fedora core. -H -- Henning Follmann | hfollm...@itcfollmann.com
Re: Following Pipewire developments
On Mon, 8 Nov 2021 08:15:47 +0100 Yoann LE BARS wrote: > As Pipewire is quite recent, I probably > would rather use some recent version of Pipewire. Do you know that the version in Bullseye will not work? Have you tried it? > > As far as I know, Pipewire is not available on Backports: > > https://packages.debian.org/search?keywords=pipewire&searchon=names&suite=all§ion=all > > Is there a way to use some recent version of Pipewire with > Debian stable? You could pull in the package for Bookworm or Sid and try installing that. "apt pipewire." But if the installation breaks, you get to keep all the pieces. You could also try pulling it in from the git repo and installing that. https://pipewire.org To be consistent with Linux standards, I would set --prefix=/usr/local It appears Ardour and Musescore are available as Debian packages, although neither is the most recent version. That suggests that one or both will build easily on Debian. I would consider building them from source. Then you can bypass the flatpack entirely. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: Occasional failure of X to start
Hi, i wrote: > > It would be interesting to learn whether after such a start failure > > on your machine the file > > /var/log/xdm.log > > shows indications that it was created newly. Richmond wrote: > It seems so. I hadn't noticed it was always on a Sunday but could be. So it looks really like bug 948346. (My unqualified theory is that xdm writes a log message line which triggers the log rotation before xdm has prepared for catching and processing signal USR2. This would explain why the rotate can reliably hit the short timespan when xdm is vulnerable.) Consider to send a mail to 948...@bugs.debian.org saying that you experience the problem too. Eduard Bloch, a (former ?) Debian Developer, seems to have a workaround but Julien Cristau (current Debian Developer of xdm ?) seems not to accept it. Maybe more bug confirmations can help Edi's workaround to get in. > I should configure logrotate /etc/logrotate.d/xdm remove weekly and put > size=1G then hopefully it won't happen for a few years? Looks worth a try. If it works, then consider to mention it in your mail to 948...@bugs.debian.org . Have a nice day :) Thomas
Looking for Brasero testers on Debian Testing for bug 998718
Hi, i am looking for volunteers with up-to-date Debian Testing, a CD/DVD/BD burner, Brasero, and the willingness to reboot after bug 998718 struck. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998718 indicates that a DVD drive ASUS DRW-24D5MT gets disconnected from the kernel when Brasero tries to write a Debian netinst ISO to a CD-RW medium. The drive then gets reconnected with another device file (probably /dev/sr1) which becomes target of the /dev/cdrom link and works. But the old device file (/dev/sr0) does not vanish and lures software into using it, which then fails with a kernel error that indicates a bad connection to the drive. Only rebooting resolves this mess. The bug is only observed with Brasero on Testing. K3B, wodim and xorriso burn CD-RW without spoiling the relation of kernel and drive. Brasero does not cause the problem if run on Debian Stable. My question is whether this happens with other drives too, i.e. whether the ASUS firmware has a particular stake in the bug. Please send answers to 998...@bugs.debian.org Cc: mauro.sacche...@gmail.com Have a nice day :) Thomas
Re: Re: Re: Can't connect bluetooth headset after resent update (testing)
> Checked but no luck. I can pair headset but can't use it( Another thread here reported following > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997862&archived=no&mbox=no&mboxmaint=norelated > to bug #997862 which seemed to work for me, that is,installing a package > libspa-0.2-bluetooth.and I found on the PA devel mailing listBug#993011: > pulseaudio-module-bluetooth: no longer detects bluetooth headphones > do you have libspa-0.2-bluetooth installed? > This solution worked for me! Thanks a lot
