[qubes-users] hplib complaint with fedora-28 qube manager update , what to do?
Hello, The following below was/is after using a manually opened xterm that successfully runs $sudo dnf update and closing the template/s The Qubes Manager is showing green dots on the Fed-28 (Q4.0.1?) templates needing update but: when I use the QManager to update I am seeing some complaint about hplip I tried to highlight and copy it but any clicking in the xterm and it disappears . start a terminal for the template gives me this: [user@fedora-28 ~]$ sudo dnf upgrade Last metadata expiration check: 4:24:34 ago on Sun 30 Dec 2018 01:46:31 PM HST. Dependencies resolved. Problem 1: cannot install the best update candidate for package hplip-3.18.6-7.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-3.18.6-11.fc28.x86_64 Problem 2: cannot install the best update candidate for package hplip-libs-3.18.6-7.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-libs-3.18.6-11.fc28.x86_64 Problem 3: cannot install the best update candidate for package libsane-hpaio-3.18.6-7.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by libsane-hpaio-3.18.6-11.fc28.x86_64 Problem 4: package hplip-libs-3.18.6-7.fc28.x86_64 requires hplip-common(x86-64) = 3.18.6-7.fc28, but none of the providers can be installed - cannot install both hplip-common-3.18.6-11.fc28.x86_64 and hplip-common-3.18.6-7.fc28.x86_64 - problem with installed package hplip-libs-3.18.6-7.fc28.x86_64 - cannot install the best update candidate for package hplip-common-3.18.6-7.fc28.x86_64 - nothing provides libnetsnmp.so.35()(64bit) needed by hplip-libs-3.18.6-11.fc28.x86_64 PackageArchVersion RepositorySize Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): hplip-common x86_64 3.18.6-11.fc28 updates 110 k Skipping packages with broken dependencies: hplip x86_64 3.18.6-11.fc28 updates 16 M hplip-libs x86_64 3.18.6-11.fc28 updates 204 k libsane-hpaio x86_64 3.18.6-11.fc28 updates 127 k Transaction Summary Skip 4 Packages Nothing to do. Complete! -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4b8be1e4-7abb-d740-a26b-0ddefc95473d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] dom0 bell
Hi, I never understood the purpose of the loudspeaker bell in linux, but on my machine, it is particularly loud and annoying. Is there a reasonable way to deactivate it forever? Thank you (and a happy new year), Bernhard -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/80e5a723-0bf2-c307-c5bf-12f4297bf1dd%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Ubuntu templates
On 20181230 at 16:34 + unman wrote: > > Not starting redoing everything to the point where the build > > process stopped would be a good first step. > > Yes, it's very aggravating. I would work around this by commenting > out the packages that *have* been built, so the build can start again > from where it failed. I (having started using Unix with 4.2BSD on a VAX where things tended to take really long) wrote a csh script around make doing every single component one-by-one and checking the exit state of the make jobs I'm starting. Looks ridiculous but works unattended. > I'm not surehow this could be done otherwise By formulating further dependencies that check whether the goals are already existing. If something that has been done flawlessly is remade the thing has been missing in the dependencies. Another good indicator that something is wrong with the makefile is getting into a mess if using -j is causing any kind of race condition or premature target being done. And no, "make -j4 qubes-vm" does not work which means that rules fire before all prerequisites have been done. > download. Maybe a "download all required additional data" makeMaybe a > "download all required additional data" maktarget > > > > would be a good idea, too. Or did I miss that? > > There's make get-sources, of course, but I dont think that is what > you mean. No, rather a target get-packages that will download all .deb/.rpm/.whatever that will later be used to create the root environments for VM templates. This step is coming REALLY late (after building all qubes-packages) and I definitely do not see any reason to rebuild all the qubes-* components because a package download fails. Wrong order. > I strongly recommend a caching proxy. apt-cacher-ng works pretty much > out the box. If you downloaded it once it stays in qubes-builder. (Which is another target that is missing -- old packages are kept in there if later builds are getting more recent versions.) So unless you are using a tool with high tolerance to interrupted downloads this will not help that much. And places with unstable network connections are easy to find. Btw: If I understood the license clauses of Ubuntu correctly you can do with it whatever you want as long as you do not call it (genuine or derived) (U)buntu. So if you provide a minimal template with sufficiently free space (and calling it Pronto instead of Ubuntu) that pulls down the "trade dress and feel" on a first run should be well within the limits. Maybe that's a way to do it. Although I would consider having supported Arch and a CentOS template much more important. Debian is a glacier and Fedora... I'd better not start thinking about that. But it will take considerable resources to keep all necessary components working. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/09b9a55ffa2e817c32a91e1c1e8da9112d49561d.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Ubuntu templates
On Sun, Dec 30, 2018 at 04:35:07PM +0100, Achim Patzner wrote: > On 20181227 at 10:58 + unman wrote: > > There's an open issue relating to making build more fault tolerant, but > > since I never see that problem, it's not a priority. > > Not starting redoing everything to the point where the build process > stopped would be a good first step. Yes, it's very aggravating. I would work around this by commenting out the packages that *have* been built, so the build can start again from where it failed. I'm not surehow this oculd be done otherwise, except having a build target (start-from) which skipped pachkage in the build list before that one. > > > (I use > > apt-cacher-ng as a caching proxy which might help. Certainly does on the > > template updating.) > > Probably. Sitting in jakarta and trying to do a make qubes-vm followed > by make template was tiring with every second package failing to > download. Maybe a "download all required additional data" make target > would be a good idea, too. Or did I miss that? There's make get-sources, of course, but I dont think that is what you mean. I strongly recommend a caching proxy. apt-cacher-ng works pretty much out the box. The only change required is to make it listen on port 8082 and some minor config for Fedora. Also, since the move to https , you have to make some changes to keep caching. The simplest way is to use http://HTTPS/// in the sources.list and then the proxy will will be able to cache packages but will still fetch them under https. > > > On your second point did you read > > https://qubes.3isec.org? I've been > > running those for about two years. > > Sadly not but I will take a look at it now; I gave up using other > people's templates when the Arch template was running out of updates... > And to be honest: Using the Builder environment is a good exercise. > Agreed. > > Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181230163452.d7noiwmyssaxenru%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Ubuntu templates
On 20181227 at 10:58 + unman wrote: > There's an open issue relating to making build more fault tolerant, but > since I never see that problem, it's not a priority. Not starting redoing everything to the point where the build process stopped would be a good first step. > (I use > apt-cacher-ng as a caching proxy which might help. Certainly does on the > template updating.) Probably. Sitting in jakarta and trying to do a make qubes-vm followed by make template was tiring with every second package failing to download. Maybe a "download all required additional data" make target would be a good idea, too. Or did I miss that? > On your second point did you read > https://qubes.3isec.org? I've been > running those for about two years. Sadly not but I will take a look at it now; I gave up using other people's templates when the Arch template was running out of updates... And to be honest: Using the Builder environment is a good exercise. Achim -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/b7255ae890dcbce5e18f7de9d4d3f66574ebf5fd.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] xsel via qrexec fails to set clipboard, "conversion refused"
On Fri, Dec 28, 2018 at 10:28:12AM -0800, Dave C wrote: > I've written a qrexec script which, among other things, attempts to place > something into the clipboard, using `xsel`. > > xsel fails, with error: "xsel: Conversion refused" > > Attempting to troubleshoot, I've learned that `xsel -o` can show the contents > of the clipboard, but `xsel` fails to set the clipboard. Both `xsel -v` and > `xsel -b -v` fail with the "conversion refused" messages. `xsel` works fine > when I run it from a terminal. The error occurs only when running via qrexec. > > For some context, if you're interested... I recently became aware of a > password manager with some interesting features: > https://github.com/renatoathaydes/go-hash. I'd like to modify it, so that it > both opens a URL in a VM, and places a password in that VM's clipboard. I've > got most of that working, except that I can't get the password into the > clipboard, because xsel fails with "conversion refused". > It would help if you provided a copy of your script and some detail on where you are calling xsel, how you are handling it on the receiving side, and what templates you are using. Are you using the normal Qubes clipboard paste mechanism or are you rolling your own? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181230133252.7ryqpl54gmbyybvl%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] qvm-run on R4 with Windows VM
On Qubes 3.2, I was able to start executables on my Windows VM through a launcher with a qvm-run command: "qvm-run -q --tray -a VMname -- 'cmd.exe /c "C:\path\to\file.exe"' " However, when I try this on Qubes 4, it doesn't work, the Windows VM doesn't even start with this command. How can I fix this? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a01a0a26-8cc2-4adc-8ee4-d08f8eb38544%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: 35c3 session: Introduction to Qubes OS
torsdag den 27. december 2018 kl. 12.12.36 UTC-5 skrev Wojtek Porczyk: > Hi qubes-users, > > During 35th Chaos Communication Congress in Leipzig we'll be organizing an > introductory session to Qubes OS: > > https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS Was it recorded, so others can view it later? I cannot find it here: https://media.ccc.de/c/35c3 ? Sincerely Max -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0552fa55-3c06-4169-a8b3-9f54e8c789b0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How risky is GPU pass-through?
On Sunday, December 30, 2018 at 9:34:58 AM UTC+1, John Smiley wrote: > No. I knew exactly what you were talking about. That’s okay. You just keep > on with your mind in neutral. I won’t waste time n a closed mind. John, You never commented on the videos that show gaming working in a VM so I am not sure who has the closed mind? Anyway, no problems, we can agree we disagree and part friends. Blessings, John -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0d657969-ede6-42ab-b6b8-319019b55ea1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How risky is GPU pass-through?
No. I knew exactly what you were talking about. That’s okay. You just keep on with your mind in neutral. I won’t waste time n a closed mind. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8541bcef-1c72-40b1-9796-d0e74770ab61%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
