Re: Screen sharing ungoogled-chromium
Hi, Would you consider to use a custom flaptak Teams package? Check it out, screen sharing does work for me. -- Alexey On May 1, 2022 06:25:13 phodina via wrote: Jitsi works in chromium and I'm able to share screen. But I'm trying to switch to Guix as my work laptop but in order to do that the Teams screen share would have to work. Anyway it's proprietary garbage so if there isn't anybody who got it working let's just close the discussion. Petr Sent from ProtonMail mobile Original Message On Apr 28, 2022, 7:41 PM, Giovanni Biscuolo wrote: Hi phodina this sounds like an upstream bug, or do you think it depends on Guix packaging? phodina via writes: > Hi, > > I'm attempting to share my screen in the chromium browser (100.0.4896.127-1). > > I've enabled the #enable-webrtc-pipewire-capturer flag and I also have xdg-desktop-portal install on my Guix System. > > However, when I click in Teams do you mean Microsoft Teams? I never used that service, sorry I cannot help here. [...] > Does somebody use the screen sharing feature? I regurarly use the screen sharing feature in Jitsi and it works out of the box (some previous ungoogled-chromium had issues with video on Jisti, depending on servers) HTH! Gio' -- Giovanni Biscuolo Xelera IT Infrastructures
Re: Questions about guix handling emacs packages
Hi, Fredrik Salomonsson writes: > Hi Zimoun, > > zimoun writes: > >> Yes and no. :-) >> You can see for example this blog entry [1]. >> >> [1] https://guix.gnu.org/blog/2017/creating-bundles-with-guix-pack/ > > Thanks for the link. Will give guix pack a try when I'm back at my > machine at work. Right now I'm working from home so I don't need to have > emacs on my work machine. Tramp covers that bit for me. > >>> > Is it fixed now for you? >>> >>> emacs-magit - yes. emacs-ts is still failing. >> >> Could you open a bug report for this? > > I was too slow :). Did a `guix pull` and updated to > 86a03090afa711dfa2f141caee820b66d7942bc3 and it is now fixed. Will > create a bug report for emacs-lua-mode and emacs-ledger-mode as those > two are still broken for me. > > Thanks again for all your help. AFAIK emacs-ts is failing on check. There are couple of PRs in the upstream: https://github.com/alphapapa/ts.el/pull/9 https://github.com/alphapapa/ts.el/pull/8 Regarding the magit highlighting, emacs 27 has a new face attribute :extend. You can read about the issue here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37774 ,[ C-h i d m emacs s :extend ] |This is one of the few faces that has the ‘:extend t’ attribute by | default, which implies that the same face is used to highlight the text | and space between end of line and the window border. To highlight only | the text you could set this attribute to ‘nil’. ` Magit fix is on the master already https://github.com/magit/magit/commit/891ebdca58ef498ff3b94c8ac2921cc6b72c3d25 In the meantime you can do something like this: --8<---cut here---start->8--- (dolist (face '(magit-diff-hunk-heading magit-diff-hunk-heading-highlight magit-diff-hunk-heading-selection magit-diff-hunk-region magit-diff-lines-heading magit-diff-lines-boundary magit-diff-conflict-heading magit-diff-added magit-diff-removed magit-diff-our magit-diff-base magit-diff-their magit-diff-context magit-diff-added-highlight magit-diff-removed-highlight magit-diff-our-highlight magit-diff-base-highlight magit-diff-their-highlight magit-diff-context-highlight magit-diff-whitespace-warning magit-diffstat-added magit-diffstat-removed magit-section-heading magit-section-heading-selection magit-section-highlight magit-section-secondary-heading magit-diff-file-heading magit-diff-file-heading-highlight magit-diff-file-heading-selection)) (set-face-attribute face nil :extend t)) --8<---cut here---end--->8--- -- Alexey
Re: Dovecot + pigeonhole packaging
Gábor Boskovits writes: > Hello Alexey, > > Alexey Abramov ezt írta (időpont: 2019. aug. 28., Sze, > 22:30): > >> Hi guix, >> >> >> My system requires me to have dovecot and pigeonhole. So I packaged it. I >> created two none public packages and merged them into one big package. >> > > Is this on Guix System? > If yes, then guix system has a dovecot-service: > https://guix.gnu.org/manual/en/html_node/Mail-Services.html > maybe you could have a look at that, and see if it helps. Yes, I am migrating my mail server and a working laptop to Guix. >> But wouldn't it be better to do it the same way as debian does?Every >> component lives in a separate package, and if I need some library I don't >> have to install the giant package. >> > > In guix packages can be split to multiple outputs. You can also define > separate packages, > but these are less common. Would multiple outputs make sense in this case? > https://guix.gnu.org/manual/en/html_node/Packages-with-Multiple-Outputs.html >> >> >> The problem I encountered is that dovecot has mail_plugin_dir property >> which does not accept multiple folders. It means I have to put and install >> new plugins in the very same directory with existing plugins. rpath is not >> an option here. Even if a library knows where to load its dependencies, >> dovecot doesn't aware of it. >> >> >> Is there a way to have shared store folder? Debian overrides rpath to all >> dovecot extensions and set it to /usr/dovecot/lib. >> > > If dovecot follows symlinks on plugin resoltuion, then the service > configuration > could be extended by a plugins keyword, like it was for postgresql > extensions, > that sets up a symlink is a well known location to the store item of the > package > providing the plugin. Thanks for the symlink tip! I am using guix on my laptop as a foreign distr and was struggle with the path to the lib. I didn't know how to get that folder. Thanks! (string-append %current-profile "/lib/dovecot") fixed everything. -- Alexey
Dovecot + pigeonhole packaging
Hi guix, My system requires me to have dovecot and pigeonhole. So I packaged it. I created two none public packages and merged them into one big package. But wouldn't it be better to do it the same way as debian does?Every component lives in a separate package, and if I need some library I don't have to install the giant package. The problem I encountered is that dovecot has mail_plugin_dir property which does not accept multiple folders. It means I have to put and install new plugins in the very same directory with existing plugins. rpath is not an option here. Even if a library knows where to load its dependencies, dovecot doesn't aware of it. Is there a way to have shared store folder? Debian overrides rpath to all dovecot extensions and set it to /usr/dovecot/lib. Or maybe create a dummy package and use it as a storage for the libraries? What is the right approach here? I also checked how nixos does it, and I don't like this approach, they patch source code and install their libs in /etc -- Alexey
