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=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:  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
Reply to: