Bug#902866: flameshot: Will not run, exits with error "Could not connect to display"
Hi Prescott > It's been a while but luckily I've kept all my config changes in a git repo! Thank you for your quick response and being able to dig this up! > >How do you select to start bspwm: via a menu in your DM, after logging into > >your DM, from your ~/.xsession, ~/.xinitrc, etc.? > So I start bspwm by running `startx` at boot and had `exec bspwm` as the WM > launch command This might be the crucial point: I’m guessing you are using ~/.xinitrc? If you can reproduce the issue with ~/.xinitrc, could you test whether it also occurs when you use ~/.xsession instead (i.e. remove ~/.xinitrc!)? AFAICT /etc/X11/Xsession.d/95dbus_update-activation-env sets up dbus correctly but everything in /etc/X11/Xsession* is only active if startx runs /etc/X11/xinit/xinitrc and it will not if ~/.xinitrc exists. Thank you henk On Fri, 24 Feb 2023 11:25:16 -0600 Prescott HM wrote: > >I’m thinking your (dbus) environment is not initialized correctly when > >starting your X-session. How do you start it? > >Do you use some Display Manager, like xdm, gdm, etc.? > >How do you select to start bspwm: via a menu in your DM, after logging into > >your DM, from your ~/.xsession, ~/.xinitrc, etc.? > > It's been a while but luckily I've kept all my config changes in a git repo! > > So I start bspwm by running `startx` at boot and had `exec bspwm` as the WM > launch command, but had gotten it fixed by correctly starting it with `exec > dbus- run-session -- bspwm`. > > I think the biggest issue was as someone new to trying out lauching a > graphical > session without a display manager, there really wasn't any indication of > what exactly is needed to manually start that's taken for granted. It finally > clicked when I started using other programs that require a D-Bus environment, > and trying out Void Linux on some machines had me going through their docs > where it's clearly stated that a session bus may be required for some > software.
Bug#902866: flameshot: Will not run, exits with error "Could not connect to display"
Hi Prescott Do you still have this issue? > I just realized the issue, although it doesn't seem to be related to > flameshot directly. The program runs as a D-BUS service, and for some reason > the DISPLAY environment variable isn't being set. This sounds like this bug needs to be reassigned to some other package. I’m thinking your (dbus) environment is not initialized correctly when starting your X-session. How do you start it? Do you use some Display Manager, like xdm, gdm, etc.? How do you select to start bspwm: via a menu in your DM, after logging into your DM, from your ~/.xsession, ~/.xinitrc, etc.? Please report back so proper steps can be taken. Cheers henk On Mon, 20 Aug 2018 14:59:39 + Prescott Hidalgo-Monroy wrote: > Hi, > > I just realized the issue, although it doesn't seem to be related to > flameshot directly. The program runs as a D-BUS service, and for some reason > the DISPLAY environment variable isn't being set. The issue is resolved by > running > > dbus-update-activation-environment DISPLAY XAUTHORITY > > I had to do the same with systemd and implement a DISPLAY set in my startup > script in order for dunst to work as a non-root user. These issues didn't > come up under Stretch, so I'm not sure what changed when upgrading to Testing. > > > Regards, > Prescott Hidalgo-Monroy > > ‐‐‐ Original Message ‐‐‐ > On July 3, 2018 9:05 PM, Boyuan Yang <073p...@gmail.com> wrote: > > > Control: tag -1 + help > > > > > 在 2018年7月4日星期三 CST 上午12:41:49，Prescott Hidalgo-Monroy 写道： > > > > > > Just tried with the bspwm version in the Buster repos, still have the same > > > issue and error messages. > > > Regards, > > > Prescott HM > > > > > Hi, > > > > > Unfortunately I couldn't reproduce your problem on all major DEs and some > > WMs. > > I am not able to test bspwm at this moment. I'd suggest that you report this > > problem to upstream http://github.com/lupoDharkael/flameshot meanwhile. > > > > > --- > > > > > Regards, > > Boyuan Yang > > > > > > ‐‐‐ Original Message ‐‐‐ > > > On July 2, 2018 12:18 PM, Prescott Hidalgo-Monroy > > > > monroy.com> wrote: > > > > > > > Using git upstream bspwm v0.9.5-5-g229b6fd, and it's all local use. > > > > I might try the bspwm version from the repos as well, it's on v0.9.5-1. > > > > Regards, > > > > Prescott > > > > ‐‐‐ Original Message ‐‐‐ > > > > On July 2, 2018 10:10 AM, Boyuan Yang 073p...@gmail.com wrote: > > > > > > > > > > Control: severity -1 important > > > > > Control: tag -1 + moreinfo > > > > > 在 2018年7月2日星期一 CST 下午10:33:29，Prescott 写道：
Bug#1000627: apache2: missing dependency setting
Control: tags -1 upstream Hi On Fri, 3 Jun 2022 23:53:50 +0200 Michael Biebl wrote: > I'd like to refer to https://systemd.io/NETWORK_ONLINE/ as well. > Especially to "Should network-online.target be used?" which suggest > better and more robust options then using network-online.target AFAICT there is an upstream bugreport for implementing IP_FREEBIND: https://bz.apache.org/bugzilla/show_bug.cgi?id=58725 This seems to have already been implemented, at least in 2.5/trunk: https://httpd.apache.org/docs/trunk/mod/mpm_common.html#listen Since this bug only occurs when the user specifies an IP address to listen on, our default config is not affected AFAIU. So the easiest way to fix this bug is to wait and maybe add a comment before the default 'Listen' directives to add the freebind option when changing the 'Listen' to a specific IP address. This can only be done once we package a release containing that option, though. In the meantime the only workaround seems to be to wait for the network-online.target but since this is not necessary for the stock config, I don’t really want to do that.
Bug#1004275: php upgrade apache2: After upgrade php install apache2 and i have intalled lighttpd
Control: tags -1 moreinfo Control: reassign php Hi Thank you for your report. On Mon, 24 Jan 2022 01:33:24 +0100 wrote: > After apt update & upgrade a new php update appear but the upgrade also > installed apache2. Can you provide a log of your commands and outputs? Which php package(s) were updated from which version to which version? > I am running lighttpd server and apache2 it's not neccesary on my system. Makes sense. Which version of lighthttpd is installed? I’m reassigning this package to php, exclusively, because I don’t think any change in the apache2 package(s) can fix the issue. Cheers henk
Bug#745605: please retest
Control: tags -1 -fixed-upstream It seems this bugreport was tagged 'fixed-upstream' automatically after the upstream bug was closed automatically due to age or inactivity. AFAICT the bug is not fixed, the change proposed in [1] / [2] does not seem to be applied, see [3]. Someone would need to retest this (as described in upstream’s bugtracker’s closing comment), report back, and depending on result either close this bug or reopen upstream’s bug; or alternatively provide a minimal example how to reproduce it for someone else to test. Thanks! [1]: https://bz.apache.org/bugzilla/show_bug.cgi?id=35049#c1 [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745605#55 [3]: https://svn.apache.org/viewvc/httpd/httpd/trunk/server/protocol.c?view=markup#l80
Bug#714083: default-ssl.conf should also be prefixed with 000- to be sure to be first ssl virtualhost
Control: retitle -1 default-ssl.conf should also be prefixed with 000- to be sure to be first ssl virtualhost Control: severity -1 normal Control: tags -1 help Increased severity because this does easily cause problems, unexpected behaviour, confusion, and support requests when an ssl vhost is put in a config with a filename that is sorted before 'default-ssl.conf', e.g. 'custom-vhost.conf' or 'a-vhost.conf'. There is already a pull request [1] that was already merged but then reverted because changing this config file’s name is not trivial and I had not thought of how to do this migration on productive systems. Concrete questions are: * how to deal with this on all variations of systems ** unchanged, not activated (will dpkg/ucf/whatever-handles-these-config-files do the right thing? I guess the old file will be removed and the new file placed, but how to be certain?) ** changed, not activated (what do we do? move the existing file? remove it, install the new?) ** unchanged, activated (similar to first variant, but how to deal with the symlink in sites-enabled/?) ** changed, activated (do we even do anything in this case or just assume that it’s working as intended and leave the admin to it?) Concrete suggestions, patches, references to relevant docs, merge requests, etc. welcome! Cheers henk
Bug#706996: vifm: new upstream version available
Hey Salvatore, On Mon, 06 May 2013 20:18:12 +0200 Salvatore Bonaccorso wrote: > There is 0.7.4b out as latest release and a new beta release (0.7.5b) > available for vifm. > > Would it be possible to package the newest versions? Yes, I’m in contact with upstream and most issues have already been fixed. I’m now waiting for upstream to give an estimation for the release of 0.7.5 and probably wait for that until preparing an upload. Thanks for the report and best regards henk signature.asc Description: PGP signature
