Re: chromecast: no audio when casting screen, works with tab
El mié., 16 dic. 2020 23:16, Andrea Borgia escribió: > Hi. > > > System in running "Testing", using KDE, I'm trying to get Chromium to send > audio via Chromecast as well as video. > > > After enabling the relevant flag[1], I've tried casting a single tab and > playing a video. It worked well, with audio coming from TV. > > Stopped the transmission, switched source to desktop and restarted: video > is shown, audio remains from computer. > > Additionally, using Chrome directly (ughs, I know...) I get the same > results. > > On the other hand, with the office laptop using Windows, both Chromium > (nightly) and Chrome can share full desktop with audio. > > > In short: casting from Linux can only send audio from single tab. This is > of course a problem for applications without native Chromecast support, > especially with my own laptop having very weak speakers. > > Has anyone more recent information[2]? Pointers to hard evidence > confirming it won't work are also welcome. > It is a known issue , see https://support.google.com/chromecast/thread/27045993?hl=en Maybe somebody know how usé ffmpg to send desktop without lag to Chromecast (my quick test (from the first result on Google/duckeuckgo) was not ok)? A hipotetical solution would be record Desktop with ffmpeg, use sometype of proxy to play the recording on a localhost http URL which could be played from chromium and then send the tab to chromecast Regards
Re: ps2pdf: why differences in different instances using unchanged PS source file
On Tue 15 Dec 2020 at 11:06:33 (+1300), David Warring wrote: > On Mon, Dec 14, 2020 at 10:14 AM Tom Browder wrote: > > On Sun, Dec 13, 2020 at 11:03 The Wanderer wrote: > > > On 2020-12-13 at 11:40, Tom Browder wrote: > > > > personalized calendar for my wife. This year I have been cleaning up > > > > my old Perl generating code (in preparation for converting it to Raku > > > > [https://raku.org]) and noticed I am getting a different pdf output > > > > for each run, even when the PS output source file is unchanged! > > ... > > > What observation leads you to notice that the files are different? > > > > When I have both files under git revision control and committed, a > > rerun shows no change in the PS but a change in the PDF. > > > > I read the rest of this post and your additional post. Thank you for > > your forensic information. As long as I know what has changed, thanks > > to you, I am content for the moment. > > I have a Raku online friend (in CC above) who is an expert on PDF and > > has built voluminous tools with his PDF modules in Raku. I think he > > will either know about the problem or possibly know how to fix it > > since he deals with the binary output and modifying it after the fact. > > > Yes quite right. As The Wanderer points out the CreationDate and ModDate > differ, as do the uuid in the Catalog Metadatas and the trailer ID. > > I've found that deleting the optional dates from the Info dictionary, the > Metadata entry from the Catalog and resetting the ID does seem to be enough > to make output PDFs identical. In the simple case at least. > > This gist https://gist.github.com/dwarring/1e4e056d84d6fe125262bba1da1f58fb > does > this using the Raku PDF module. Usage is: > > p2s2pdf-strip.raku in.pdf [out.pdf] # post-process ps2pdf output > > I've used the lower level PDF::Reader interface, which doesn't often get > used directly. But in this case, we also need to bypass Raku PDF also > attempting to update the same fields. The PDF also needs to be rewritten, > rather than being incrementally updated. Another way of tackling this is to use faketime when creating the PDF file, which deals with the times and uuids. The only difference left is the pair of ID strings (each 32 hex chars) at the end, which I assume are random (when generated by ps2pdf). One way of dealing with this is to run cmp -bl a.pdf b.pdf and subtract the integer at the beginning of the first line of output from that in the last line. The difference should not exceed 65 (2×32+2-1). If writing a script to perform this check, one might parameterise this number, as I did notice that convert (from ImageMagick) must take a different approach to generating its IDs. The strings are 64 chars long, but identical from run to run. So although just using faketime can produce a perfect match in this case, it's a warning that the IDs may have different properties when generated by other conversion tools. Cheers, David.
Re: Debian 10 64bit
On Wed 16 Dec 2020 at 16:00:08 -0600, David Wright wrote: > On Tue 15 Dec 2020 at 19:33:53 (+0100), john doe wrote: > > On 12/15/2020 6:34 PM, Tixy wrote: > > > On Tue, 2020-12-15 at 11:36 +0100, john doe wrote: > > > > On 12/15/2020 10:19 AM, Andrei POPESCU wrote: > > > > > > The Debian Installer will configure 'sudo' for the first user only if > > > > > you leave the root password blank. This is explained during the > > > > > install. > > > > > > > > That doesn't look to be the case anymore, I just installed Buster with > > > > Mate and sudo is installed. > > (Already refuted.) > > > > Because sudo is a recommended package of task-desktop, which is a > > > dependency of task-mate-desktop. But if you gave it a root password > > > during install then it didn't add the user you created at install time > > > into the 'sudo' group, so no user can use sudo. > > Not until root configures it, (which *could* involve adding users > to the sudo group). > > > > (This does make me > > > wonder why 'sudo' is recommended by task-desktop in the first place.) > > I can't answer that as I don't run any DE. Neither do I have a DE, but we all have access to the task-desktop changelog: tasksel (3.44) unstable; urgency=medium [ nicoo ] * Team upload. * Add myself as uploader. * task-desktop - Depend on libu2f-udev. (Closes: #891472) - Depend on sudo. (Closes: #773550) -- nicoo Wed, 23 May 2018 23:56:54 +0200 -- Brian.
Re: Preseeding Postfix for No configuration
On Wed 16 Dec 2020 at 19:00:29 (+0100), Erik wrote: > On 16-12-2020 18:24, Dan Ritter wrote: > > Erik wrote: > > > I am doing an unattended install of Debian Buster with postfix being > > > added using apt-install in the preseed/late_command. > > > > > > Without a postfix preseed definition in my preeseed file, I get the > > > expected > > > question about what kind of mail configuration I would like. > > > When I select "No configuration", installation continues as expected and I > > > end up with a postfix installation without main.cf and without master.cf. > > > > > > But when I preseed postfix with "d-i postfix/main_mailer_type select No > > > configuration" > > > as both debconf-get-selections and > > > https://preseed.debian.net/debian-preseed/buster/amd64-main-full.txt > > > confirm I should do, I get an extra question asking me about the system > > > mail > > > name. > > > Clearly, this question is out of place for a "No configuration" install. > > > And as a result I end up with a main.cf and a master.cf, which contradicts > > > the "No configuration". > > > > > > So something is going wrong. Apparently the preseeded selection for > > > configuration type is accepted, as that question is not asked, but it > > > is not interpreted as "No configuration". > > If you don't want any configuration, you must be supplying > > configuration later on -- so why don't you refrain from > > installing postfix via the preseed, and install it later when > > you are ready to configure it? > > Because the configuration is preseeded as well. The installl is > entirely unattended > and the apt-install is supposed to only install Postfix itself. After > that, the configuration > will be added automatically too. > > Of course I can overwrite the files that get installed, but that's not > the point here. > The point is that there is a bug somewhere that makes the installer do > the wrong > thing when the same answer as given manually, is given via preseeding. > The same answer should not lead to different results. I'm not a pre-seeder, so I don't know how much gets logged to VC4 and /var/log/installer/syslog (its final resting place), but you could compare the logs from the two runs. And, taking care with the jumping timezones, the log can also be tied in with file creation/modification times. Cheers, David.
chromecast: no audio when casting screen, works with tab
Hi. System in running "Testing", using KDE, I'm trying to get Chromium to send audio via Chromecast as well as video. After enabling the relevant flag[1], I've tried casting a single tab and playing a video. It worked well, with audio coming from TV. Stopped the transmission, switched source to desktop and restarted: video is shown, audio remains from computer. Additionally, using Chrome directly (ughs, I know...) I get the same results. On the other hand, with the office laptop using Windows, both Chromium (nightly) and Chrome can share full desktop with audio. In short: casting from Linux can only send audio from single tab. This is of course a problem for applications without native Chromecast support, especially with my own laptop having very weak speakers. Has anyone more recent information[2]? Pointers to hard evidence confirming it won't work are also welcome. Thanks in advance, Andrea. [1] chrome://flags/#load-media-router-component-extension [2] https://askubuntu.com/questions/855137/ubuntu-14-04-chromecast-desktop-casting-no-audio
Re: Debian 10 64bit
On Tue 15 Dec 2020 at 19:33:53 (+0100), john doe wrote: > On 12/15/2020 6:34 PM, Tixy wrote: > > On Tue, 2020-12-15 at 11:36 +0100, john doe wrote: > > > On 12/15/2020 10:19 AM, Andrei POPESCU wrote: > > > > The Debian Installer will configure 'sudo' for the first user only if > > > > you leave the root password blank. This is explained during the install. > > > > > > That doesn't look to be the case anymore, I just installed Buster with > > > Mate and sudo is installed. (Already refuted.) > > Because sudo is a recommended package of task-desktop, which is a > > dependency of task-mate-desktop. But if you gave it a root password > > during install then it didn't add the user you created at install time > > into the 'sudo' group, so no user can use sudo. Not until root configures it, (which *could* involve adding users to the sudo group). > > (This does make me > > wonder why 'sudo' is recommended by task-desktop in the first place.) I can't answer that as I don't run any DE. > Or at the very least, if sudo is installed having it configured with > the user added to the sudo group regardless of if a root password is set. It would appear that you don't understand any other manner in which sudo can be configured besides just bestowing on a user the power of %sudo ALL=(ALL:ALL) ALL with membership of the sudo group. It takes man sudoersover 2400 lines to describe its flexibility. Cheers, David.
Re: Debian 10 64bit
On Wed 16 Dec 2020 at 10:09:44 (+), Keith Bainbridge wrote: > I was not offered to set a root passwd during the last 2 Buster installs I > did. Admittedly, with mateDE and MAYBE that makes a difference. Who's going > to try it to prove the point? It'll be several days before I can. Will do if > I don't see somebody beat me to it. It takes about two minutes to get to these screens, which follow the shadow passwords question: ┌──┤ [?] Set up users and passwords ├──┐ │ │ │ If you choose not to allow root to log in, then a user account will │ │ be created and given the power to become root using the 'sudo' │ │ command. │ │ │ │ Allow login as root? │ │ │ ││ │ │ └──┘ (Yes was selected.) ┌──┤ [!!] Set up users and passwords ├──┐ │ │ │ You need to set a password for 'root', the system administrative │ │ account. A malicious or unqualified user with root access can have│ │ disastrous results, so you should take care to choose a root password │ │ that is not easy to guess. It should not be a word found in │ │ dictionaries, or a word that could be easily associated with you. │ │ │ │ A good password will contain a mixture of letters, numbers and│ │ punctuation and should be changed at regular intervals. │ │ │ │ The root user should not have an empty password. If you leave this│ │ empty, the root account will be disabled and the system's initial │ │ user account will be given the power to become root using the "sudo" │ │ command. │ │ │ │ Note that you will not be able to see the password as you type it.│ │ │ │ Root password:│ │ │ │ _ │ │ │ │ [ ] Show Password in Clear│ │ │ ││ │ │ └───┘ Selecting MATE is irrelevant, because that decision is only made many steps further on, as indicated here: […] │ Configure the network │ → │ Set up users and passwords │ │ Configure the clock │ │ Detect disks│ │ Partition disks │ │ Install the base system │ │ Configure the package manager │ → │ Select and install software │ │ Install the GRUB boot loader on a hard disk │ […] If required by your answers above, sudo will be installed automatically during the "finish-install" step. Obviously it may also get installed as a dependency of some software you selected at an earlier stage. Cheers, David.
[bullseye] xterm CR paste niet meer
Misschien dat een van jullie dat weet: sinds een paar weken is copy/paste veranderd in een xterm. Eerst kon je een CR wel mee-pasten, nu moet je een extra geven. Er is vast iets veranderd bij een update, en het zal vast wel in een van de 7320 regels van de manpage staan, maar om dat te gaan zitten bestuderen is nou niet echt een van m'n hobbies. Ik roep het zo aan: uxterm -bg black -fg white Waarom ze dat nou na 25 jaar gaan zitten aanpassen is me een raadsel. Iemand een hint? R. -- richard lucassen http://contact.xaq.nl/
Re: Preseeding Postfix for No configuration
On 16-12-2020 18:24, Dan Ritter wrote: Erik wrote: I am doing an unattended install of Debian Buster with postfix being added using apt-install in the preseed/late_command. Without a postfix preseed definition in my preeseed file, I get the expected question about what kind of mail configuration I would like. When I select "No configuration", installation continues as expected and I end up with a postfix installation without main.cf and without master.cf. But when I preseed postfix with "d-i postfix/main_mailer_type select No configuration" as both debconf-get-selections and https://preseed.debian.net/debian-preseed/buster/amd64-main-full.txt confirm I should do, I get an extra question asking me about the system mail name. Clearly, this question is out of place for a "No configuration" install. And as a result I end up with a main.cf and a master.cf, which contradicts the "No configuration". So something is going wrong. Apparently the preseeded selection for configuration type is accepted, as that question is not asked, but it is not interpreted as "No configuration". If you don't want any configuration, you must be supplying configuration later on -- so why don't you refrain from installing postfix via the preseed, and install it later when you are ready to configure it? Because the configuration is preseeded as well. The installl is entirely unattended and the apt-install is supposed to only install Postfix itself. After that, the configuration will be added automatically too. Of course I can overwrite the files that get installed, but that's not the point here. The point is that there is a bug somewhere that makes the installer do the wrong thing when the same answer as given manually, is given via preseeding. The same answer should not lead to different results. I can deal with this bug, now I know it's there. Erik
Re: Preseeding Postfix for No configuration
Erik wrote: > I am doing an unattended install of Debian Buster with postfix being > added using apt-install in the preseed/late_command. > > Without a postfix preseed definition in my preeseed file, I get the expected > question about what kind of mail configuration I would like. > When I select "No configuration", installation continues as expected and I > end up with a postfix installation without main.cf and without master.cf. > > But when I preseed postfix with "d-i postfix/main_mailer_type select No > configuration" > as both debconf-get-selections and > https://preseed.debian.net/debian-preseed/buster/amd64-main-full.txt > confirm I should do, I get an extra question asking me about the system mail > name. > Clearly, this question is out of place for a "No configuration" install. > And as a result I end up with a main.cf and a master.cf, which contradicts > the "No configuration". > > So something is going wrong. Apparently the preseeded selection for > configuration type is accepted, as that question is not asked, but it > is not interpreted as "No configuration". If you don't want any configuration, you must be supplying configuration later on -- so why don't you refrain from installing postfix via the preseed, and install it later when you are ready to configure it? -dsr-
Preseeding Postfix for No configuration
Hi, I am not sure where to go with this. It relates to postfix, but is not a problem with postfix itself. May one of you can help me along. I am doing an unattended install of Debian Buster with postfix being added using apt-install in the preseed/late_command. Without a postfix preseed definition in my preeseed file, I get the expected question about what kind of mail configuration I would like. When I select "No configuration", installation continues as expected and I end up with a postfix installation without main.cf and without master.cf. But when I preseed postfix with "d-i postfix/main_mailer_type select No configuration" as both debconf-get-selections and https://preseed.debian.net/debian-preseed/buster/amd64-main-full.txt confirm I should do, I get an extra question asking me about the system mail name. Clearly, this question is out of place for a "No configuration" install. And as a result I end up with a main.cf and a master.cf, which contradicts the "No configuration". So something is going wrong. Apparently the preseeded selection for configuration type is accepted, as that question is not asked, but it is not interpreted as "No configuration". Any suggestions as to what I might be doing wrong, or where to better ask my question if this is not the right place? regards, Erik
python3.9 venv testing error message
as it is testing perhaps there is a temporary glitch in the packages for python3.9, but it has been there for at least a week if not longer. oh, i do have python-is-python3 and there are no python2 programs anywhere on this system that i know of. when i run the command: = $ python -m venv env setting up virtual environment /home/me/src/salsa/env The virtual environment was not created successfully because ensurepip is not available. On Debian/Ubuntu systems, you need to install the python3-venv package using the following command. apt-get install python3-venv You may need to use sudo with that command. After installing the python3-venv package, recreate your virtual environment. Failing command: ['/home/me/src/salsa/env/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip'] = the package mentioned is installed: = $ dpkg -l | grep python3-venv ii python3-venv 3.9.0-4amd64 pyvenv-3 binary for python3 (default python3 version) = any ideas? :) thanks! songbird
Re: Debian 10 64bit
On 12/16/20 2:09 AM, Keith Bainbridge wrote: I was not offered to set a root passwd during the last 2 Buster installs I did. Admittedly, with mateDE and MAYBE that makes a difference. Who's going to try it to prove the point? It'll be several days before I can. Will do if I don't see somebody beat me to it. Keith BAINBRIDGE I have done many installs recently, several machines, but am occupied this morning. I believe the installation goes exactly as described in the manual, but there are always some details that don't fit. https://debian-handbook.info/browse/stable/sect.installation-steps.html#id-1.7.12.10 best of luck next time ke1thozgro...@gmx.com Sent from my Aphone On 15 December 2020 7:01:32 pm UTC, Brian wrote: On Tue 15 Dec 2020 at 19:33:53 +0100, john doe wrote: On 12/15/2020 6:34 PM, Tixy wrote: On Tue, 2020-12-15 at 11:36 +0100, john doe wrote: On 12/15/2020 10:19 AM, Andrei POPESCU wrote: On Lu, 14 dec 20, 19:45:54, Jerry Mellon wrote: I finally got around to installing debian 10 on my 64bit system(thus removing the i386version I had originally instaled). The install went well and I asked for a seperate Home particion. When I booted the system and try to do "apt-get update and apt-get upgrade" using "sudo" it would not let me do that. Said I was not a sudo user. I then tried "su root" which failed as well as it said I was not a sudo user. I went to the sudouse file and changed it to make me a user. Sudo as myself worked fine but su root still did not work. After seeing the email concering problems with sudo and su root I decided to reload. I did but did a use whole disk (no home part). After booting I did have to go to the sudouser file an change it again but the su root worked with out a problem. You probably set a root password during install. The Debian Installer will configure 'sudo' for the first user only if you leave the root password blank. This is explained during the install. That doesn't look to be the case anymore, I just installed Buster with Mate and sudo is installed. Because sudo is a recommended package of task-desktop, which is a dependency of task-mate-desktop. But if you gave it a root password during install then it didn't add the user you created at install time into the 'sudo' group, so no user can use sudo. (This does make me wonder why 'sudo' is recommended by task-desktop in the first place.) Or at the very least, if sudo is installed having it configured with the user added to the sudo group regardless of if a root password is set. You are being obtuse. d-i does not install sudo unless it is requested. That's the only point at issue. It is the only thing that matters. Why Mate chooses to install sudo is a different issue. It does not invalidate The Debian Installer will configure 'sudo' for the first user only if you leave the root password blank. This is explained during the install. What a particular package does has no bearing on the design of d-i's base system. -- Brian.
Re: [testing] installer un flatpak
Le mercredi 16 décembre 2020 à 14:20 +0100, Daniel Caillibaud a écrit : > Le 16/12/20 à 13h09, Gaëtan PERRIER a écrit : > > Le problème c'est que debian est en train de dégager python2 ce qui pose > > soucis avec pas mal de logiciels qui ne sont pas compatibles python3. > > dans buster il y a encore tous les paquets python2, ils disparaissent de > sid ? > Oui une grande partie a été supprimé. De python 2 il reste: python2:amd64/testing 2.7.18-2 uptodate python2-minimal:amd64/testing 2.7.18-2 uptodate python2.7:amd64/testing 2.7.18-1 uptodate python2.7-dev:amd64/testing 2.7.18-1 uptodate python2.7-minimal:amd64/testing 2.7.18-1 uptodate Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] installer un flatpak
Le 16/12/20 à 13h09, Gaëtan PERRIER a écrit : > Le problème c'est que debian est en train de dégager python2 ce qui pose > soucis avec pas mal de logiciels qui ne sont pas compatibles python3. dans buster il y a encore tous les paquets python2, ils disparaissent de sid ? -- Daniel Dans la marine on ne fait pas grand chose mais on le fait de bonne heure. devise Shadok
Re: [testing] installer un flatpak
Le mercredi 16 décembre 2020 à 13:17 +0100, Gaëtan PERRIER a écrit : > Le mercredi 16 décembre 2020 à 12:09 +0100, Sébastien NOBILI a écrit : > > Bonjour, > > > > Le 2020-12-15 20:02, Gaëtan Perrier a écrit : > > > Par contre j'ai essayé: > > > > > > flatpak install ~/Téléchargements/chirp-daily-20201128.flatpak > > > error: The application com.danplanet.chirp/x86_64/master requires the > > > runtime > > > org.freedesktop.Platform/x86_64/19.08 which was not found > > > > > > Mais l'erreur n'est pas franchement plus parlante ... > > > > C'est une dépendance qui te manque. > > > > Pour faire une analogie avec un monde que tu connais sûrement mieux, tu > > as > > téléchargé un .deb que tu veux installer avec "apt install > > ./fichier.deb" mais > > tu n'as pas configuré APT pour qu'il connaisse les sources de repo APT > > de Debian. > > > > Flatpak ne sait donc pas où trouver cette dépendance. > > > > Chez moi : > > > > flatpak search org.freedesktop.Platform > > Description > > Application Version > > Branch Remotes > > Freedesktop Platform - Shared libraries > > org.freedesktop.Platform 20.08.2 > > 20.08 flathub > > Freedesktop Platform - Shared libraries > > org.freedesktop.Platform 19.08.12 > > 19.08 flathub > > Freedesktop Platform - Shared libraries > > org.freedesktop.Platform 18.08.39 > > 18.08 flathub > > openh264 - OpenH264 Video Codec provided by Cisco Systems, Inc. > > org.freedesktop.Platform.openh264 2.1.0 > > 2.0 flathub > > > > J'imagine que cette commande ne retourne rien chez toi. Si tel est le > > cas, > > il te faudra déclarer le dépôt Flathub. > > > > C'est documenté là (étape 4) : https://flatpak.org/setup/Debian/ > > > > Sébastien > > > > Effectivement la commande ne retourne rien. Je pensais que le fait > d'installer > les paquets faisait le nécessaire pour que ce soit fonctionnel. > Pour quelque chose qui est censé simplifier l'installation de logiciels c'est > dommage de devoir mettre les mains dans le cambouis pour le faire fonctionner > surtout que lorsque l'on installe flatpak il n'y a pas d'avertissement ... > > Gaëtan J'ai réussi à installer le flatpak mais 100 Mo pour un logiciel qui en fait 4 en tant normal. Quelle gabegie ! Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] installer un flatpak
Le mercredi 16 décembre 2020 à 12:09 +0100, Sébastien NOBILI a écrit : > Bonjour, > > Le 2020-12-15 20:02, Gaëtan Perrier a écrit : > > Par contre j'ai essayé: > > > > flatpak install ~/Téléchargements/chirp-daily-20201128.flatpak > > error: The application com.danplanet.chirp/x86_64/master requires the > > runtime > > org.freedesktop.Platform/x86_64/19.08 which was not found > > > > Mais l'erreur n'est pas franchement plus parlante ... > > C'est une dépendance qui te manque. > > Pour faire une analogie avec un monde que tu connais sûrement mieux, tu > as > téléchargé un .deb que tu veux installer avec "apt install > ./fichier.deb" mais > tu n'as pas configuré APT pour qu'il connaisse les sources de repo APT > de Debian. > > Flatpak ne sait donc pas où trouver cette dépendance. > > Chez moi : > > flatpak search org.freedesktop.Platform > Description > Application Version > Branch Remotes > Freedesktop Platform - Shared libraries > org.freedesktop.Platform 20.08.2 > 20.08 flathub > Freedesktop Platform - Shared libraries > org.freedesktop.Platform 19.08.12 > 19.08 flathub > Freedesktop Platform - Shared libraries > org.freedesktop.Platform 18.08.39 > 18.08 flathub > openh264 - OpenH264 Video Codec provided by Cisco Systems, Inc. > org.freedesktop.Platform.openh264 2.1.0 > 2.0 flathub > > J'imagine que cette commande ne retourne rien chez toi. Si tel est le > cas, > il te faudra déclarer le dépôt Flathub. > > C'est documenté là (étape 4) : https://flatpak.org/setup/Debian/ > > Sébastien > Effectivement la commande ne retourne rien. Je pensais que le fait d'installer les paquets faisait le nécessaire pour que ce soit fonctionnel. Pour quelque chose qui est censé simplifier l'installation de logiciels c'est dommage de devoir mettre les mains dans le cambouis pour le faire fonctionner surtout que lorsque l'on installe flatpak il n'y a pas d'avertissement ... Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] installer un flatpak
Le mercredi 16 décembre 2020 à 12:04 +0100, Daniel Caillibaud a écrit : > Le 15/12/20 à 22h26, Gaëtan Perrier a écrit : > > Bon j'ai laissé tombé le flatpak et j'ai fini par utiliser la version > > Windows avec Wine ... :( > > Sur https://trac.chirp.danplanet.com/chirp_daily/LATEST/ est mentionné > l'existence d'un ppa pour ubuntu. > > C'est probable que ça fonctionne pour debian, regarde sur > https://launchpad.net/~dansmith/+archive/ubuntu/chirp-snapshots/+packages > pour récupérer un .deb > > Je sais pas quelle version d'ubuntu ressemble à ta version de debian (à > priori faut prendre la distrib ubuntu sortie juste après ta version de > debian et tenter le .deb prévu pour cette version ubuntu sur ta debian), > mais tu risques pas grand chose à tenter un > dpkg -i lepaquet.deb > S'il te manque des dépendances, ça va les lister, installe les à partir de > tes dépôt debian puis recommence, et si tu ne trouves pas les bonnes > dépendances dans ta debian, essaie un deb prévu pour une autre version > d'ubuntu. > Le problème c'est que debian est en train de dégager python2 ce qui pose soucis avec pas mal de logiciels qui ne sont pas compatibles python3. Il y a bien une branche python3 de chirp (utilisée pour faire le paquet debian) mais elle ne semble pas active (dernier commit en février) et le résultat n'est pas franchement fonctionnel. Le problème est encore plus criant avec un excellent logiciel comme displaycal qui va se retrouvé dégagé de debian car il n'y pas de version python3. C'est une des raisons qui me font fuir le python. Gaëtan signature.asc Description: This is a digitally signed message part
Re: [testing] installer un flatpak
Bonjour, Le 2020-12-15 20:02, Gaëtan Perrier a écrit : Par contre j'ai essayé: flatpak install ~/Téléchargements/chirp-daily-20201128.flatpak error: The application com.danplanet.chirp/x86_64/master requires the runtime org.freedesktop.Platform/x86_64/19.08 which was not found Mais l'erreur n'est pas franchement plus parlante ... C'est une dépendance qui te manque. Pour faire une analogie avec un monde que tu connais sûrement mieux, tu as téléchargé un .deb que tu veux installer avec "apt install ./fichier.deb" mais tu n'as pas configuré APT pour qu'il connaisse les sources de repo APT de Debian. Flatpak ne sait donc pas où trouver cette dépendance. Chez moi : flatpak search org.freedesktop.Platform Description Application Version Branch Remotes Freedesktop Platform - Shared libraries org.freedesktop.Platform 20.08.2 20.08 flathub Freedesktop Platform - Shared libraries org.freedesktop.Platform 19.08.12 19.08 flathub Freedesktop Platform - Shared libraries org.freedesktop.Platform 18.08.39 18.08 flathub openh264 - OpenH264 Video Codec provided by Cisco Systems, Inc. org.freedesktop.Platform.openh264 2.1.0 2.0flathub J'imagine que cette commande ne retourne rien chez toi. Si tel est le cas, il te faudra déclarer le dépôt Flathub. C'est documenté là (étape 4) : https://flatpak.org/setup/Debian/ Sébastien
Re: [testing] installer un flatpak
Le 15/12/20 à 22h26, Gaëtan Perrier a écrit : > Bon j'ai laissé tombé le flatpak et j'ai fini par utiliser la version > Windows avec Wine ... :( Sur https://trac.chirp.danplanet.com/chirp_daily/LATEST/ est mentionné l'existence d'un ppa pour ubuntu. C'est probable que ça fonctionne pour debian, regarde sur https://launchpad.net/~dansmith/+archive/ubuntu/chirp-snapshots/+packages pour récupérer un .deb Je sais pas quelle version d'ubuntu ressemble à ta version de debian (à priori faut prendre la distrib ubuntu sortie juste après ta version de debian et tenter le .deb prévu pour cette version ubuntu sur ta debian), mais tu risques pas grand chose à tenter un dpkg -i lepaquet.deb S'il te manque des dépendances, ça va les lister, installe les à partir de tes dépôt debian puis recommence, et si tu ne trouves pas les bonnes dépendances dans ta debian, essaie un deb prévu pour une autre version d'ubuntu. -- Daniel On tue un homme, on est un assassin. On tue des millions d'hommes, on est un conquérant. On les tue tous, on est un dieu. Edmond Rostand
Re: Problemes amb les X, com als vells temps [resolt]
Finalment aquest matí, el què un upgrade t'ha tret, un upgrade t'ho torna. Tinc un altre cop nvidia funcionant correctament, ja no es queixa a l'instal·lar els paquets nvidia-legacy-340xx-* i puc tornar a activar el composite del xfce4, que sembla que no però es trobava a faltar. A la que Bullseye sigui estable tornaré a provar de passar-me a nouveu, aviam que tal. Gràcies en especial a l'Àlex per mirar-s'ho. Xavi On 2020-12-03 10:49, xavi wrote: Hola, Després de fer un upgrade a debian testing, l'escriptori del meu vell ordinador d'escriptori es queda fregit (al cap d'una estona d'ús). Us dono una mica de dades: . Processador AMD 5050e (que era una meravella que consumia poquíssim). (No té a veure amb el tema, però ho menciono per si algú més el fa servir, que opini :-) ). . Tarja gràfica: root@zigoto:~# lspci | grep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation G98 [GeForce 8400 GS Rev. 2] (rev a1) root@zigoto:~# Amb els drivers de nouveau me dona problemes, l'escriptori (xfce4) se'm queda congelat. Tal i com recomanava xserver-xorg-video-nouveau, instal·lo els paquets que recomana o suggereix: Recommends: libgl1-mesa-dri (>= 9.0) Suggests: firmware-misc-nonfree Però res, continua igual. Amb el driver propietari d'nvidia (que a més em sembla mig abandonat a Debian per aquesta tarja?) ha aguantat uns dies, però avui m'ha donat problemes a l'actualitzar a testing, no me reconeixia un dels dos monitors i l'altre sortia amb una resolució menor, ara l'estic reinstal·lant aviam que tal. Si provo de reinstal·lar els drivers propietaris de nvidia em peta: root@zigoto:~# apt install xserver-xorg-video-nvidia-legacy-340xx S'està llegint la llista de paquets… Fet S'està construint l'arbre de dependències S'està llegint la informació de l'estat… Fet xserver-xorg-video-nvidia-legacy-340xx ja està en la versió més recent (340.108-8). El paquets següents s'han instal·lat automàticament i ja no són necessaris: linux-headers-5.9.0-2-amd64 linux-headers-5.9.0-2-common linux-image-5.9.0-2-amd64 Empreu «apt autoremove» per a suprimir-los. 0 actualitzats, 0 nous a instal·lar, 0 a suprimir i 1 no actualitzats. 2 no instal·lats o suprimits completament. Després d'aquesta operació saran 0 B d'espai en disc addicional. Voleu continuar? [S/n] S'està configurant nvidia-legacy-340xx-kernel-dkms (340.108-8)… Removing old nvidia-legacy-340xx-340.108 DKMS files... -- Deleting module version: 340.108 completely from the DKMS tree. -- Done. Loading new nvidia-legacy-340xx-340.108 DKMS files... Building for 5.9.0-4-amd64 Building initial module for 5.9.0-4-amd64 Error! Bad return status for module build on kernel: 5.9.0-4-amd64 (x86_64) Consult /var/lib/dkms/nvidia-legacy-340xx/340.108/build/make.log for more information. dpkg: s'ha produït un error en processar el paquet nvidia-legacy-340xx-kernel-dkms (--configure): el subprocés «s'ha instal·lat el script nvidia-legacy-340xx-kernel-dkms del paquet post-installation» retornà el codi d'eixida d'error 10 dpkg: problemes de dependències impedeixen la configuració de nvidia-legacy-340xx-driver: nvidia-legacy-340xx-driver depèn de nvidia-legacy-340xx-kernel-dkms (= 340.108-8) | nvidia-legacy-340xx-kerne l-340.108; tot i així: El paquet nvidia-legacy-340xx-kernel-dkms encara no està configurat. El paquet nvidia-legacy-340xx-kernel-340.108 no està instal·lat. El paquet nvidia-legacy-340xx-kernel-dkms que proveeix nvidia-legacy-340xx-kernel-340.108 no està configurat . dpkg: s'ha produït un error en processar el paquet nvidia-legacy-340xx-driver (--configure): problemes de dependències - es deixa sense configurar S'han trobat errors en processar: nvidia-legacy-340xx-kernel-dkms nvidia-legacy-340xx-driver needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) root@zigoto:~# M'estic plantejant baixar-me el driver propietari del web de NVIDIA, esborrar tots els drivers de nvidia via apt remove *nvidia* i instal·lar-lo via: # ./NVIDIA-Linux-x86_64-340.108.run Ara ho provaré i aviam que tal. Però molaria si algú més s'hi ha trobat i si en té cap solució per poder continuar fent servir els drivers de nouveau. Merci per endavant. Xavi Per si algú si ha trobat.
Re: Debian 10 64bit
Keith Bainbridge wrote: > I was not offered to set a root passwd during the last 2 Buster installs > I did. Admittedly, with mateDE and MAYBE that makes a difference. Who's > going to try it to prove the point? It'll be several days before I can. > Will do if I don't see somebody beat me to it. I ran the buster arm64 installer twice in QEMU last week (ncurses ui) and it asks to set root pwd and to create a normal user account as it did always before.
Re: Debian 10 64bit
I was not offered to set a root passwd during the last 2 Buster installs I did. Admittedly, with mateDE and MAYBE that makes a difference. Who's going to try it to prove the point? It'll be several days before I can. Will do if I don't see somebody beat me to it. Keith BAINBRIDGE ke1thozgro...@gmx.com Sent from my Aphone On 15 December 2020 7:01:32 pm UTC, Brian wrote: >On Tue 15 Dec 2020 at 19:33:53 +0100, john doe wrote: > >> On 12/15/2020 6:34 PM, Tixy wrote: >> > On Tue, 2020-12-15 at 11:36 +0100, john doe wrote: >> > > On 12/15/2020 10:19 AM, Andrei POPESCU wrote: >> > > > On Lu, 14 dec 20, 19:45:54, Jerry Mellon wrote: >> > > > > I finally got around to installing debian 10 on my 64bit system(thus >> > > > > removing the i386version I had originally instaled). The install went >> > > > > well and I asked for a seperate Home particion. When I booted the >> > > > > system >> > > > > and try to do "apt-get update and apt-get upgrade" using "sudo" it >> > > > > would >> > > > > not let me do that. Said I was not a sudo user. I then tried "su >> > > > > root" >> > > > > which failed as well as it said I was not a sudo user. I went to the >> > > > > sudouse file and changed it to make me a user. Sudo as myself worked >> > > > > fine but su root still did not work. >> > > > > >> > > > > After seeing the email concering problems with sudo and su root I >> > > > > decided to reload. I did but did a use whole disk (no home part). >> > > > > After booting I did have to go to the sudouser file an change it >> > > > > again >> > > > > but the su root worked with out a problem. >> > > > >> > > > You probably set a root password during install. >> > > > >> > > > The Debian Installer will configure 'sudo' for the first user only if >> > > > you leave the root password blank. This is explained during the >> > > > install. >> > > >> > > That doesn't look to be the case anymore, I just installed Buster with >> > > Mate and sudo is installed. >> > >> > Because sudo is a recommended package of task-desktop, which is a >> > dependency of task-mate-desktop. But if you gave it a root password >> > during install then it didn't add the user you created at install time >> > into the 'sudo' group, so no user can use sudo. (This does make me >> > wonder why 'sudo' is recommended by task-desktop in the first place.) >> > >> >> Or at the very least, if sudo is installed having it configured with >> the user added to the sudo group regardless of if a root password is set. > >You are being obtuse. > >d-i does not install sudo unless it is requested. That's the only point >at issue. It is the only thing that matters. > >Why Mate chooses to install sudo is a different issue. It does not >invalidate > > > The Debian Installer will configure 'sudo' for the first > > user only if you leave the root password blank. This is > > explained during the install. > >What a particular package does has no bearing on the design of d-i's >base system. > >-- >Brian. >
Re: Debian 10 64bit
On Tue, Dec 15, 2020 at 02:11:45PM -0600, Nicholas Geovanis wrote: > I smile at this discussion, having gone through this same thought-cycle so > many times. > I claim this is motivation for the separation of a graphical client > workstation, simpler and separate from the server, having ONLY a > single-user identity at a time. In other words, re-implementation of the > XWindows approach. > I think that identity, access and security friction as we see in this > discussion will eventually push the pendulum back in that other direction. > Except for those who dont mind the in/decrement in complexity and > responsiveness in an installation that provides both. In the data center > this separation is enforced for many years; X-Windows is not installed on > servers. There's almost never a need for it there and it presents another > attack surface. Agree, in general. One nitpick: it's "X", "X11" or "the X Window System". Calling it "X Windows" is giving in to The Reptile's influence. [Sorry. I'm a bit of a language nerd. I've already asked my doctor, she says she can't do anything about it] I think what happened (somewhere between 1990 and early 2000s) is, that with everyone having a computer on her desk, the idea of separate users became blurry. Desktop environments had one "real user", and she was sitting right there, next to the graphics hardware. Unix got many things right from the beginning, because this multi-user paradigm was deeply rooted in there from day one: battle-tested by students keen on playing pranks, with people using the system /at the same time/ (*GASP!*) from different time zones. Whoever has seen time handling in Windows during its period from Windows 3.1 to Windows 95 and XP has had a lot to laugh. And to weep. So the desktop environments started aping Windows more and more, and, although the underlying system was inherently multi-user, they became kind of single-user. Watch all that "multiseat" nonsense of the time (promoted, afaik, by some bigger Linux "vendors" [1]). Then, with the take-off of the browser and Active-X 3.0 [2] (aka Javascript), multi-user becomes interesting again, but for different reasons. If you do some archaeology, you'll find that many things have been reinvented in some strange, sometimes perverted way [3]... and slapped on top of the existing layer. Cgroups vs. process groups; systemd's socket activation vs. (x)inetd; and so on. The future? Usually I'm called an optimist, but this time... sorry. I think we'll be back to that terminal thingie: people will have a browser on their desktops/pockets/retinas; that browser will be written in node.js and be totally controlled by Google, and will be running on dedicated hardware. It will be "open source", mind you, but it will be so fiendishly complex that you'll need some AI-driven SDK whose training data will be Google's and Palantir's trade secrets to even stand a chance to hack at it. Know what? I'm glad I passed my 2^6 th year. It was my last power of two ;-P But then, I meet so incredibly smart young people, who surprise me in (well, duh!) unforeseen ways... this, again, keeps me alive and curious :-D Cheers [1] It might seem I'm bashing here early Linux vendors. Not at all: Red Hat and Suse did and do a lot to keep the lights on for many a cool hacker. OTOH they are capitalist enterprises in the classical sense (i.e. the money dictates where things go), so they pick up some of the antipatterns of the trade. Things are as they are. [2] Active-X 2.0 being Flash. Java applets never got an own version, sorry ;-) [3] Not saying that there wasn't an itch to scratch, mind you. There sure was. Often, though, you'll also witness some amount of "second system syndrome" [5] [5] https://en.wikipedia.org/wiki/Second_system_syndrome - t signature.asc Description: Digital signature
Re: FW: Re: Release status of i386 for Bullseye and long term support for 3 years?
David wrote: > On Wed, 16 Dec 2020 at 00:41, deloptes wrote: [snip] > > Some discussion around those questions occurred in the thread from > which Andrei forwarded one message. The thread begins here: > https://lists.debian.org/debian-release/2020/12/msg00139.html > > so that's probably a good place to begin reading for anyone interested > in this topic. Definitely a good reading and here is where I see myself https://lists.debian.org/debian-release/2020/12/msg00214.html "There were surprisingly many users complaining that their hardware was no longer supported after the i386 baseline was raised from 586 to 686 in stretch." The Geode I have is 586 with following enabled flags: fpu de pse tsc msr cx8 pge cmov mmx mmxext 3dnowext 3dnow cpuid But as noted since stretch the stock kernel does not work as it is 686. The stock kernel did not work also before, because of the the board - the chipset that requires legacy drivers combined with non legacy and the bios that is very picky. I must admit I do not recall raising bug or asking for advice
