Bug#856179: ITP: polybar -- fast and easy-to-use status bar

[Jason Pleau]

Package: wnpp
Severity: wishlist
Owner: Jason Pleau <ja...@jpleau.ca>

* Package name : polybar
Version : 3.0.4
Upstream Author : Michael Carlberg <c...@rlberg.se>
* 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

[Antoine Beaupre]

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...

.

[Jason Pleau]

Hi.

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

[Antoine Beaupré]

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

[Jason Pleau]

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

[Antoine Beaupré]

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=0x300000c)
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: Dropping unmatched character  (U+e028)
warn: Dropping unmatched character  (U+e026)
warn: Dropping unmatched character  (U+e19c)
warn: Dropping unmatched character  (U+e0ca)
warn: Dropping unmatched character  (U+e10c)

Now a bunch of those are normal: I didn't specify a monitor, I don't
have a working xbacklight, no wlan and no battery. But I have no idea
what's going on with that "unmatched character": this floods my logs and
makes this rather ... difficult to use. It looks like there's something
seriously wrong in the unicode in the default config file:

$ grep 'format-prefix = ' doc/config.cmake | sed 's/[^"]*"//;s/"//'| head -1 | hd
00000000 ee 89 af 20 0a |... .|
00000005
$ unicode $(grep 'format-prefix = ' doc/config.cmake | sed 's/[^"]*"//;s/"//'| head -1 )
U+E26F - No such unicode character name in database
UTF-8: ee 89 af UTF-16BE: e26f Decimal: &#57967; Octal: \0161157
 ()
Uppercase: E26F
Category: Co (Other, Private Use)
Unicode block: E000..F8FF; Private Use Area
Bidi: L (Left-to-Right)

Now, maybe it's me missing something obvious here... Maybe a font? in
that case why would cairo complain that way?

For what it's worth, i have fonts-font-awesome installed, which should
provide proper fallbacks for those fonts. I get the above even when
adding the font in the font list config. Obviously, this makes the whole
bar look rather bland... :)

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. :)

Thanks for the package!

A.

--
We won't have a society if we destroy the environment.
- Margaret Mead

[Antoine Beaupré]

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

[Samuel Henrique]

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 <samueloph>

[Jason Pleau]

Hi

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.

[Samuel Henrique]

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.

[Jason Pleau]

Hi, sorry for the delay.

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 <samueloph>

[Samuel Henrique]

Control: owner -1 !

On Mon, 27 Jan 2020 at 13:41, Jason Pleau <ja...@jpleau.ca> 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.

[Antoine Beaupré]

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

[Samuel Henrique]

Hello Antoine,

On Mon, 2 Mar 2020 at 20:13, Antoine Beaupré <ana...@debian.org> 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.