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

[Patrick Ziegler]

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

[Samuel Henrique]

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

[Antoine Beaupré]

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

[Samuel Henrique]

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

[Jason Pleau]

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

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

Regards,

--
Samuel Henrique 

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

[Jason Pleau]

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

[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 

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

[Jason Pleau]

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

[Jason Pleau]

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

[Jason Pleau]

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

[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

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

[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=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

[Jason Pleau]

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

[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

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

[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

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

[Jason Pleau]

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

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

.


signature.asc
Description: PGP signature

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

[Jason Pleau]

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