Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi, I'm the one Samuel talked to on the linked issue. I wanted to quickly chime in to give the viewpoint of the polybar team and explain our priorities on the sample config. While I did express interest in auto-generating config files, this is not a priority right now (and it likely won't be for a while). I also don't see a good way to do this in the current codebase without duplicating a lot of logic around what options a module supports. So I encourage you not to go with option D. I think C is a good option to go for even in the long-term, but unfortunately it is also the one that will give you the most work, Samuel, because you need to create a generic config. I would do it for you, but unfortunately I really don't have the time right now. This still doesn't really solve the font issue, I would suggest either trying to create a config without using any fancy font icons and using ASCII characters only, this would almost guarantee that the bar displays correctly for everyone. Otherwise you're not getting around some icon or emoji font. I see that debian has a package named `fonts-font-awesome` that seems to be providing FontAwesome4 which is very popular and could well be used for such a config. I would also suggest using `ttf-unifont` which has a good coverage of the first two unicode planes. Another option would also be to not ship any config at all. If you need any help feel free to reach out. Regards, Patrick On 3/22/20 7:48 PM, Samuel Henrique wrote: > Hello Antoine, > > On Mon, 2 Mar 2020 at 20:13, Antoine Beaupré wrote: >> I tried the package available here: >> >> https://salsa.debian.org/debian/polybar >> >> It works well! One unfortunate problem I have found, however, is that it >> requires the siji font to work in its default configuration. That font >> is not available in Debian right now (#894413) but worse, even if it >> would be, it's a bitmap font which requires enabling those across the >> board (`rm /etc/fonts/conf.d/70-no-bitmaps.conf`) which, in turns, means >> that bitmap fonts *will* be used everywhere. > I briefly discussed with upstream about having a default config for > polybar in here: > https://github.com/polybar/polybar/issues/2016#issuecomment-589976084 > > And the summary is that there is no such thing as a default > configuration right now, > we are shipping an example config file that is not supposed to be used > by people as > it contains specifics from the machine used to build the package, this > also means that > the package is non-reproducible at this point. > > Upstream seems to be interested in having an option to autogenerate a > config file at > runtime if none is found, the user is currently supposed to either > have the file or generate > it using upstream: https://github.com/polybar/polybar#configuration > > You do raise a valid point, I agree that we should make the example > config as working out-of-the-box > as possible, > > There are multiple ways we can approach this issue: > > A) Patch the example file with some font that comes on Debian per default, > this > will not solve the reprobuild issue and the file will probably still > be broken for some > users, but at least is closer to a working one. > > B) Provide a config generator and mention it in the docs, can be > upstream's one, assuming > that it will not require the user to install the build-deps. Solves > the reprobuild issue as we > can ship a hardcoded non-working example. > > C) Provide a hardcoded generic example, it will have to omit some > functionality but > at least they can be commented out so the user might fill in with their specs. > > D) Wait for upstream to add a feature to auto generate the config when > none is found. > A new issue has to be created to track this, as the other one was more > about the config > location. It will also take an unknown amount of time until someone > works on that. > > I believe either B,C or D would properly solve the issue but I don't > mind doing A meanwhile. > In case you would like to have A, could you suggest a font that comes > preinstalled that > worked for you? I'm afraid we're gonna have to rely on some extra font > and add it to the > package's Recommends because the font has to have the needed symbols. > > I appreciate input/help towards any of those solutions. > >> Also note that I previously mentioned the problems with that font in >> this bug report... > I have missed that, thanks for the heads up. > > Regards, >
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hello Antoine, On Mon, 2 Mar 2020 at 20:13, Antoine Beaupré wrote: > I tried the package available here: > > https://salsa.debian.org/debian/polybar > > It works well! One unfortunate problem I have found, however, is that it > requires the siji font to work in its default configuration. That font > is not available in Debian right now (#894413) but worse, even if it > would be, it's a bitmap font which requires enabling those across the > board (`rm /etc/fonts/conf.d/70-no-bitmaps.conf`) which, in turns, means > that bitmap fonts *will* be used everywhere. I briefly discussed with upstream about having a default config for polybar in here: https://github.com/polybar/polybar/issues/2016#issuecomment-589976084 And the summary is that there is no such thing as a default configuration right now, we are shipping an example config file that is not supposed to be used by people as it contains specifics from the machine used to build the package, this also means that the package is non-reproducible at this point. Upstream seems to be interested in having an option to autogenerate a config file at runtime if none is found, the user is currently supposed to either have the file or generate it using upstream: https://github.com/polybar/polybar#configuration You do raise a valid point, I agree that we should make the example config as working out-of-the-box as possible, There are multiple ways we can approach this issue: A) Patch the example file with some font that comes on Debian per default, this will not solve the reprobuild issue and the file will probably still be broken for some users, but at least is closer to a working one. B) Provide a config generator and mention it in the docs, can be upstream's one, assuming that it will not require the user to install the build-deps. Solves the reprobuild issue as we can ship a hardcoded non-working example. C) Provide a hardcoded generic example, it will have to omit some functionality but at least they can be commented out so the user might fill in with their specs. D) Wait for upstream to add a feature to auto generate the config when none is found. A new issue has to be created to track this, as the other one was more about the config location. It will also take an unknown amount of time until someone works on that. I believe either B,C or D would properly solve the issue but I don't mind doing A meanwhile. In case you would like to have A, could you suggest a font that comes preinstalled that worked for you? I'm afraid we're gonna have to rely on some extra font and add it to the package's Recommends because the font has to have the needed symbols. I appreciate input/help towards any of those solutions. > Also note that I previously mentioned the problems with that font in > this bug report... I have missed that, thanks for the heads up. Regards, -- Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
On 2020-02-18 22:30:59, Samuel Henrique wrote: > Control: owner -1 ! > > On Mon, 27 Jan 2020 at 13:41, Jason Pleau wrote: >> >> I pushed what I had here: https://gitlab.com/jpleau/polybar/ >> >> It's not targetting debian (simply because I'm using ubuntu these >> days). Feel free to take whatever you find useful > > Thanks for that Jason, I pushed the current state of the packaging to salsa. > > I will be doing the upload the the NEW queue soon, I just want to do some > extra checks and tests to confirm everything is ok. I tried the package available here: https://salsa.debian.org/debian/polybar It works well! One unfortunate problem I have found, however, is that it requires the siji font to work in its default configuration. That font is not available in Debian right now (#894413) but worse, even if it would be, it's a bitmap font which requires enabling those across the board (`rm /etc/fonts/conf.d/70-no-bitmaps.conf`) which, in turns, means that bitmap fonts *will* be used everywhere. This is most notable when browsing GitHub in Firefox, as it will now decide to use "Helvetica" which is shipped by the xfonts-75dpi package (a dependency of xorg and task-desktop, of all things). This makes things generally horrible for me, and I don't think it's a reasonable expectation. Note that there is a truetype version of the font in https://github.com/fauno/siji/blob/master/ttf/siji.ttf ... but it doesn't display as well.. Also note that I previously mentioned the problems with that font in this bug report... a. -- The most prudent course for any society is to start from the assumption that the Internet should be fundamentally outside the domain of capital. - The Internet's Unholy Marriage to Capitalism
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Control: owner -1 ! On Mon, 27 Jan 2020 at 13:41, Jason Pleau wrote: > > I pushed what I had here: https://gitlab.com/jpleau/polybar/ > > It's not targetting debian (simply because I'm using ubuntu these > days). Feel free to take whatever you find useful Thanks for that Jason, I pushed the current state of the packaging to salsa. I will be doing the upload the the NEW queue soon, I just want to do some extra checks and tests to confirm everything is ok. Regards, -- Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi, sorry for the delay. On Sat, Jan 18, 2020 at 7:57 PM Samuel Henrique wrote: > > Hello Jason, > > > Feel free to take over the ITP and the packaging. I had deleted the > > repo because I wanted to start over when I decided not to split the > > libraries and I forgot to re-create and push what I had so far. I'll > > try to have it on salsa over the weekend. > > Great, I managed to get a working deb package, but there are still some things > like d/copyright and documentation fixes missing. > > After I get your changes I will merge them together and then finish what's > missing. I'm aiming to get it in the NEW queue in a week, so hopefully it > will get accepted before the end of February (and it can hit Ubuntu 20.04). > > If it's of any concern for you, I don't mind about how you send/publish your > work or how polished it is, you can just send me the debian folder if it's > easier > for you, I'm sure it will be useful anyway. > > Regards, > I pushed what I had here: https://gitlab.com/jpleau/polybar/ It's not targetting debian (simply because I'm using ubuntu these days). Feel free to take whatever you find useful Thanks for taking overe ! > -- > Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hello Jason, > Feel free to take over the ITP and the packaging. I had deleted the > repo because I wanted to start over when I decided not to split the > libraries and I forgot to re-create and push what I had so far. I'll > try to have it on salsa over the weekend. Great, I managed to get a working deb package, but there are still some things like d/copyright and documentation fixes missing. After I get your changes I will merge them together and then finish what's missing. I'm aiming to get it in the NEW queue in a week, so hopefully it will get accepted before the end of February (and it can hit Ubuntu 20.04). If it's of any concern for you, I don't mind about how you send/publish your work or how polished it is, you can just send me the debian folder if it's easier for you, I'm sure it will be useful anyway. Regards, -- Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi On Sat, Jan 11, 2020 at 5:08 PM Samuel Henrique wrote: > > Hello Jason, > > I'm interested in having polybar packaged on Debian, > > I can see that you closed the ITP of the other two libs libxpp and i3ipcpp > stating that they are no longer needed, and that the repository for polybar's > packaging on salsa is not available anymore. > > Do you have update0s on its packaging? I'd be happy to help or takeover from > where you stopped (if you have given up). > > From reading the discussion, I'm tempted to not split polybar's libs into > different > packages. I assume that's the current direction you're going as well. > Feel free to take over the ITP and the packaging. I had deleted the repo because I wanted to start over when I decided not to split the libraries and I forgot to re-create and push what I had so far. I'll try to have it on salsa over the weekend. > > Regards, > > -- > Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hello Jason, I'm interested in having polybar packaged on Debian, I can see that you closed the ITP of the other two libs libxpp and i3ipcpp stating that they are no longer needed, and that the repository for polybar's packaging on salsa is not available anymore. Do you have update0s on its packaging? I'd be happy to help or takeover from where you stopped (if you have given up). >From reading the discussion, I'm tempted to not split polybar's libs into different packages. I assume that's the current direction you're going as well. Regards, -- Samuel Henrique
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Small update, I pushed a change to i3ipcpp that also builds a shared library in addition to the static library. (The i3ipcpp patches I will probably be able to send upstream at some point). polybar correctly uses the shared library, I think it's better this way. I don't think I can do the same with xpp, since it is a header only library and a shared library would probably be pointless. I think I can even remove the static library (libxpp.a); it's empty. The static linkage happens with the xcb libraries anyway, not with xpp. -- Jason Pleau
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi (again..!) Didn't expect to get something to work so soon regarding the splitting of the packages. On salsa: https://salsa.debian.org/jpleau-guest/polybar (BRANCH: split_pkg) https://salsa.debian.org/jpleau-guest/libxpp https://salsa.debian.org/jpleau-guest/i3ipcpp In my sid chroot, all 3 now build fine, and the installed package works on my machine (you'll probably find the same issues you did before with the config and fonts though, haven't worked those yet) I have a patch that I will have to carry for polybar, which includes bits of xpp's CMake file to include the necessary XCB include / libraries (for linking). I think that's a bit less ugly than carrying the whole thing together :) Cheers -- Jason Pleau
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi, I'll try to answer your questions :) On 03/28/2018 10:51 AM, Antoine Beaupré wrote: > On 2018-03-27 21:15:35, Jason Pleau wrote: >> Hi. >> >> I took a few hours last weekend to work on this. > > Awesome, thanks for the work! > >> While I was able to have "working" packages for both xpp and i3ipcpp, >> I could not get polybar to use them (the whole thing is glued together >> nicely it seems and trying to split them caused me headaches). So I >> went ahead and worked on packaging the whole repo (and submodules) >> together. > > Can you expand on the problems you've encountered? Sure. Basically, by itself xpp, it's a header-only library. To build a project using it you have to include xpp's CMakeLists.txt from cmake, which then includes other cmake modules to find the different XCB modules. xpp's CMake file then generates the appropriate XCB_* libraries for your own project (in this case, polybar) to link against. So, if I was to take "xpp" into it's own package, polybar currently would have no way to know which XCB libraries to link against, since it uses xpp's own CMakeFile to find those. That's where I was stuck (I don't really use CMake so this stuff is out of my reach for the time being) > >> Repo: https://salsa.debian.org/jpleau-guest/polybar >> >> Current status: it builds in a chroot and works on my sid install. > > I have tried to build this in stretch and failed: > > $ sbuild -c stretch > dh clean --buildsystem=cmake --builddirectory=build >dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build >dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build >dh_clean -O--buildsystem=cmake -O--builddirectory=build > dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream > tarball found at ../polybar_3.1.0.orig.tar.{bz2,gz,lzma,xz} > E: Failed to package source directory /home/anarcat/dist/polybar > 1$ uscan > uscan warn: No watch file found > 1$ gbp buildpackage -c stretch > dh clean --buildsystem=cmake --builddirectory=build >dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build >dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build >dh_clean -O--buildsystem=cmake -O--builddirectory=build > gbp:error: upstream/3.1.0 is not a valid treeish > > So a few things here: > > * a debian/watch file would be useful, even if just to find out new >versions are coming out... > * the upstream tree should be tagged > > When those are fixed, I get this: > > sbuild-build-depends-polybar-dummy : Depends: debhelper (>= 11) but it is > not going to be installed > > So it might also be useful to make the DH dependency >= 11~ to allow for > easier backporting. I can send a merge request for that on Salsa (or a > patch here) if you want. > 1) watch file: I can add the watch file, if only to check for new versions. 2) debhelper version: sure, I didn't really test building for stretch but I see no harm in changing the version for debhelper if it means polybar can be backported (no need to do a MR I'll take care of it) >> TODO: >> >> - There's a few copyright info missing (ie: lib/concurrentqueue)- > > Seems to be 2-clause BSD. Yep, I saw it but I didn't add the changes yet to debian/copyright (hence the TODO title!) > >> - After installing the package, it won't do anything because the config >> file is not found (it should be in $HOME/.config/polybar). There is one >> shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to >> tell the users that when they install the package? > > /usr/share/doc/polybar/README.Debian is usually where I would expect > that kind of information to be, or in the manpage, or in the error > message directly.. Also, I would expect to find the config.gz file in an > examples/ subdirectory there. > > Maybe a more long-term solution would be to ship the sample config file > in /etc/polybar/config and patch the package to look for there on top of > $XDG_CONFIG_HOME. The proper place to look for those is XDG_CONFIG_DIRS, > which defaults to /etc/xdg, which I've always found weird. See this spec > for details: > > https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html Yes I think upstream would be in favor of having a "system-wide" config file to use as fallback. /etc/polybar or /etc/polybar/config, I'll have to see what other programs do. > >> Note that I made a custom get-orig-source rule. The tarball didn't >> contain xpp and i3ipcpp (github generated tarballs don't include >> submodules). It seems to work fine, feedback welcome on this one.. > > hmm... that does look kind of nasty. :p Why is the version number > hardcoded in $GIT_VER? Why not just use DEB_VERSION_UPSTREAM there? Initially I was using DEB_VERSION_UPSTREAM, but then I thought what if I needed to package a version that has no release (ie: a git revision). Doing it this way lets me use either DEB_VERSION_UPSTREAM, a git tag, or a specific commit. > > It's fine for testing
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
On 2018-03-28 10:51:23, Antoine Beaupré wrote: > Anyways, I guess that's an upstream problem as well, but it does seem > like the default font provided in the example config file (Siji) is not > in Debian, so that might be a nice addition. :) For what it's worth, I managed to make polybar load the Siji font, but only after installing a TrueType version of the font: https://github.com/stark/siji/issues/8 But even then, the status bar is basically blank... Not sure what's going on there, but I reverted back to i3bar for now, unfortunately. -- The university must paint itself black, mulatto, worker anddd peasant. If not, people will break down their doors and paint the university the color they like. - Ernesto "Che" Guevara
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
On 2018-03-27 21:15:35, Jason Pleau wrote: > Hi. > > I took a few hours last weekend to work on this. Awesome, thanks for the work! > While I was able to have "working" packages for both xpp and i3ipcpp, > I could not get polybar to use them (the whole thing is glued together > nicely it seems and trying to split them caused me headaches). So I > went ahead and worked on packaging the whole repo (and submodules) > together. Can you expand on the problems you've encountered? > Repo: https://salsa.debian.org/jpleau-guest/polybar > > Current status: it builds in a chroot and works on my sid install. I have tried to build this in stretch and failed: $ sbuild -c stretch dh clean --buildsystem=cmake --builddirectory=build dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build dh_clean -O--buildsystem=cmake -O--builddirectory=build dpkg-source: error: can't build with source format '3.0 (quilt)': no upstream tarball found at ../polybar_3.1.0.orig.tar.{bz2,gz,lzma,xz} E: Failed to package source directory /home/anarcat/dist/polybar 1$ uscan uscan warn: No watch file found 1$ gbp buildpackage -c stretch dh clean --buildsystem=cmake --builddirectory=build dh_auto_clean -O--buildsystem=cmake -O--builddirectory=build dh_autoreconf_clean -O--buildsystem=cmake -O--builddirectory=build dh_clean -O--buildsystem=cmake -O--builddirectory=build gbp:error: upstream/3.1.0 is not a valid treeish So a few things here: * a debian/watch file would be useful, even if just to find out new versions are coming out... * the upstream tree should be tagged When those are fixed, I get this: sbuild-build-depends-polybar-dummy : Depends: debhelper (>= 11) but it is not going to be installed So it might also be useful to make the DH dependency >= 11~ to allow for easier backporting. I can send a merge request for that on Salsa (or a patch here) if you want. > TODO: > > - There's a few copyright info missing (ie: lib/concurrentqueue)- Seems to be 2-clause BSD. > - After installing the package, it won't do anything because the config > file is not found (it should be in $HOME/.config/polybar). There is one > shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to > tell the users that when they install the package? /usr/share/doc/polybar/README.Debian is usually where I would expect that kind of information to be, or in the manpage, or in the error message directly.. Also, I would expect to find the config.gz file in an examples/ subdirectory there. Maybe a more long-term solution would be to ship the sample config file in /etc/polybar/config and patch the package to look for there on top of $XDG_CONFIG_HOME. The proper place to look for those is XDG_CONFIG_DIRS, which defaults to /etc/xdg, which I've always found weird. See this spec for details: https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html > Note that I made a custom get-orig-source rule. The tarball didn't > contain xpp and i3ipcpp (github generated tarballs don't include > submodules). It seems to work fine, feedback welcome on this one.. hmm... that does look kind of nasty. :p Why is the version number hardcoded in $GIT_VER? Why not just use DEB_VERSION_UPSTREAM there? It's fine for testing now, but I doubt this tarball would pass NEW: we'd need to split it into those three packages, probably...? Also: when we mess around with the tarballs like this, we usually tag the upstream version number accordingly, say with "+dfsg1" or something. In this case, it's not because of the DFSG, but still - we shouldn't make this package look like upstream, otherwise it brings confusion to the ecosystem, because the checksums don't match upstream. At the very least, this stuff should be documented in debian/README.source. Final nitpicks on the package: * the changelog should close this ITP * please follow DEP3 patch tagging guidelines to explain if patches were sent back upstream, if so where, and if not why. :) http://dep.debian.net/deps/dep3/ Also, I am having trouble making the thing work meaningfully. It seems it requires quite a bit of configuration... Here's what the default config gives me by default: warn: No monitor specified, using "DP1" error: Disabling module "bspwm" (reason: Could not find socket: /tmp/bspwm_0_0-socket) error: module/xbacklight: Could not get data (err: XCB_NAME (15)) error: Disabling module "xbacklight" (reason: Not supported for "DP1") error: Disabling module "wlan" (reason: Invalid network interface "net1") error: Disabling module "battery" (reason: No suitable way to get current charge state) warn: Systray selection already managed (window=0x30c) warn: Dropping unmatched character (U+e096) warn: Dropping unmatched character (U+e099) warn: Dropping unmatched character (U+e09a) warn: Dropping unmatched character (U+e09c) warn: Dropping unmatched character (U+e26f) warn:
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi. I took a few hours last weekend to work on this. While I was able to have "working" packages for both xpp and i3ipcpp, I could not get polybar to use them (the whole thing is glued together nicely it seems and trying to split them caused me headaches). So I went ahead and worked on packaging the whole repo (and submodules) together. Repo: https://salsa.debian.org/jpleau-guest/polybar Current status: it builds in a chroot and works on my sid install. TODO: - There's a few copyright info missing (ie: lib/concurrentqueue)- - After installing the package, it won't do anything because the config file is not found (it should be in $HOME/.config/polybar). There is one shipped in /usr/share/doc/polybar/config.gz, but surely there's a way to tell the users that when they install the package? Note that I made a custom get-orig-source rule. The tarball didn't contain xpp and i3ipcpp (github generated tarballs don't include submodules). It seems to work fine, feedback welcome on this one.. Thanks -- Jason Pleau
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hello. On 02/24/2018 11:11 AM, Antoine Beaupré wrote: > On 2018-02-23 22:47:08, Jason Pleau wrote: >> Hi. >> [...] >> i3ipcpp (github.com/jaagr/i3ipcpp, forked from drmgc/i3pcpp) >> - auss (github.com/jaagr/auss, forked from drmgc/auss) >> - jsoncpp (seems to be in Debian as src:libjsoncpp) >> xpp (github.com/jaagr/xpp, forked from jotrk/xpp) >> >> >> I don't mind doing the work of packaging these 3 libraries, however I >> would package the forks, unless someone wants to step in and try to get >> the forks merged into their original upstreams. > > Makes sense. Should we file RFPs for those or will you Just Do It? :) I just filed the ITPs (#892007, #892008). I have working packages for both on my machine here, just need to iron out a few details. >> Of course, I would welcome any help with this. > > I don't have much time, but I would gladly test packages and I can > sponsor/review uploads. > Awesome thanks. Will let you know when I have something ready! > A. > -- Jason Pleau
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
On 2018-02-23 22:47:08, Jason Pleau wrote: > Hi. > > On 02/20/2018 01:51 PM, Antoine Beaupre wrote: >> On Sat, Feb 25, 2017 at 10:48:12PM -0500, Jason Pleau wrote: >>> I plan to maintain this package in collab-maint on alioth >> >> Any progress here? I'm interested in tryint that stuff out... >> >> . >> > > I originally replied on IRC but I'll go into more details here : > > There are a few missing packages in Debian before I can start working on > polybar itself: > > When we look at the lib/ folder there are these libraries that aren't in > the archive: > > i3ipcpp (github.com/jaagr/i3ipcpp, forked from drmgc/i3pcpp) > - auss (github.com/jaagr/auss, forked from drmgc/auss) > - jsoncpp (seems to be in Debian as src:libjsoncpp) > xpp (github.com/jaagr/xpp, forked from jotrk/xpp) > > > I don't mind doing the work of packaging these 3 libraries, however I > would package the forks, unless someone wants to step in and try to get > the forks merged into their original upstreams. Makes sense. Should we file RFPs for those or will you Just Do It? :) > There are also two headers included > - concurrentqueue/include/moodycamel/blockingconcurrentqueue.h > - concurrentqueue/include/moodycamel/concurrentqueue.h > > These headers seem to be included in two other projects (radmap and > salmon). Is it ok to also include these directly with polybar ? I would assume so, unless the code is identical and there is a meaningful way to factor those out in the long term (e.g. get all the upstreams to agree to move those to a library). If there's already code duplication at that level, I'd say ignore this for now. > I'll try to get started on this soon, it's been a year since I filed the > ITP and I am still using polybar from a manual build / install.. That would be great. > Of course, I would welcome any help with this. I don't have much time, but I would gladly test packages and I can sponsor/review uploads. A. -- The desire to sacrifice an entire lifetime to the noblest of ideals serves no purpose if one works alone. - Che Guevara
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Hi. On 02/20/2018 01:51 PM, Antoine Beaupre wrote: > On Sat, Feb 25, 2017 at 10:48:12PM -0500, Jason Pleau wrote: >> I plan to maintain this package in collab-maint on alioth > > Any progress here? I'm interested in tryint that stuff out... > > . > I originally replied on IRC but I'll go into more details here : There are a few missing packages in Debian before I can start working on polybar itself: When we look at the lib/ folder there are these libraries that aren't in the archive: i3ipcpp (github.com/jaagr/i3ipcpp, forked from drmgc/i3pcpp) - auss (github.com/jaagr/auss, forked from drmgc/auss) - jsoncpp (seems to be in Debian as src:libjsoncpp) xpp (github.com/jaagr/xpp, forked from jotrk/xpp) I don't mind doing the work of packaging these 3 libraries, however I would package the forks, unless someone wants to step in and try to get the forks merged into their original upstreams. There are also two headers included - concurrentqueue/include/moodycamel/blockingconcurrentqueue.h - concurrentqueue/include/moodycamel/concurrentqueue.h These headers seem to be included in two other projects (radmap and salmon). Is it ok to also include these directly with polybar ? I'll try to get started on this soon, it's been a year since I filed the ITP and I am still using polybar from a manual build / install.. Of course, I would welcome any help with this. Thanks ! -- Jason Pleau
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
On Sat, Feb 25, 2017 at 10:48:12PM -0500, Jason Pleau wrote: > I plan to maintain this package in collab-maint on alioth Any progress here? I'm interested in tryint that stuff out... . signature.asc Description: PGP signature
Bug#856179: ITP: polybar -- fast and easy-to-use status bar
Package: wnpp Severity: wishlist Owner: Jason Pleau* Package name: polybar Version : 3.0.4 Upstream Author : Michael Carlberg * URL : https://github.com/jaagr/polybar/ * License : MIT/Expat Programming Lang: C++ Description : fast and easy-to-use status bar The main purpose of Polybar is to help users create awesome status bars. It has built-in functionality to display information about the most commonly used services, such as: * Systray icons * Window title * Playback controls and status display for MPD using libmpdclient * ALSA volume controls * Workspace and desktop panel for bspwm and i3 * Workspace module for EWMH compliant window managers * Keyboard layout and indicator status * CPU and memory load indicator * Battery display * Network connection details * Backlight level * Date and time label * Time-based shell script execution * Command output tailing * User-defined menu tree * Inter-process messaging Users can also develop their own modules and/or integrate modules created by others. It can be used a replacement for status bars / panels used in different window managers and desktop environments. I plan to maintain this package in collab-maint on alioth