Bug#863031: RM: nikola/7.6.4-1
I confirm that the current situation is undesirable to us. There were attempts by other Debian devs to fix this (last in January), but nothing changed. Having to say that the package is unsupported every once in a while gets tiring quickly. Since there aren't that many users, and a manual install with pip is easy to do, dropping this package won't be much of a problem in my opinion. (Of course, if there is a substantial possibility of getting something more modern in Debian repos, that would be even better.) -- Chris Warrick <https://chriswarrick.com/> On 20 May 2017 15:06, "martin f krafft" <madd...@debian.org> wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: rm > > The current version in stable is almost 2 years old. Bug#801796 has > been tracking the requests for new versions to be packaged. However, > the maintainer hasn't engaged. Upstream co-maintainer Chris Warrick > has made it clear in #801796 that they'd rather not have nikola in > Debian, than an ancient version that annoys people and causes them > spurious bug reports. > > Given how nobody has put in any work on nikola in almost 2 years, > I think we should have the decency to remove the package from > stretch and sid before the release. > > nikola has no reverse dependencies, so… > > -- System Information: > Debian Release: 9.0 > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 > (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_NZ, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > > -- > .''`. martin f. krafft <madduck@d.o> @martinkrafft > : :' : proud Debian developer > `. `'` http://people.debian.org/~madduck > `- Debian - when you have better things to do than fixing systems >
Bug#801796: nikola: New upstream release: 7.7.3
On 22 January 2017 at 13:53, Christoph Biedl <debian.a...@manchmal.in-ulm.de> wrote: > Christoph Biedl wrote... > >> Good to hear. Ping me if I should test a few things before you NMU - and >> I shouldn't have to remind you there's not too much time left to get a >> fresh nikola into stretch. > > With no additional input and just some three days left to resolve the > issue, I wasted several hours trying to provide a solution on my own, > basically by reverting the changes in resize_image mostly. The > .gitignore covering *.patch took an extra hour, some glitches in the > documentation (it's appearently ".. image", not "..image") disturbed me > as well. Now I'm caught by some python stack traces I fail to > understand. Also there is a need for configuration upgrade instructions > I did not find and certainly lack the competence to create. > > Therefore, I hereby I give up. Trying to salvage nikola for stretch, and > using nikola at all. It's not funny to see each static blog compiler I > try goes boom instantly. It's been nanoblogger, then chronicle, now > nikola. Let's see how hugo does. Nikola isn’t to blame here. We write our software with an assumption that hard dependencies will be always present. If you are trying to work around that, you’re going to make things harder for yourself. And Nikola is not alone in this: all software is written with the assumption that some hard dependencies must be installed for it to work, and if you don’t install them, it will crash. This entire debacle is caused by Debian policy — and do you think you would IMPROVE things by ripping out features at random? How would you re-implement the missing parts we use piexif for? Would Debian’s package have different output than upstream code? That isn’t better than running around with an ancient version. We’ve already fought over this when Debian made an equally arbitrary decision to remove our bootstrap3 themes. Feel free to delete Nikola from stretch. And if you believe you do not have the resources to do it in testing/sid in the future, it’s better to have no package than a horribly outdated or broken/incompatible one — just make sure to let the users of this package know that they should remove it and use a different install method if that’s what you’re going for. -- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16
Bug#801796: nikola: New upstream release: 7.7.3
Control: retitle -1 nikola: New upstream release: 7.8.1 Nikola v7.8.1 has been out for 4 weeks. The current Debian package is still v7.6.4, which was released on 2015-08-22 (over 1 year and 2 months ago). The Debian package is harmful to Nikola. We get bug reports because of it, which are about either incompatibilities between versions (plugins assuming newer Nikola versions), or things we’ve fixed in the past 14 months. Debian users trust that their repositories have a *good* package, but this is not the case with Nikola. Please get your act together and update this package. And if you can’t take care of a package, why bother maintaining it and having it altogether? Updating Nikola between versions is generally painless; we might add dependencies rarely, but we do our best to keep the base requirements list unchanged. Yours, Chris Warrick Nikola co-maintainer
Bug#833067: [pkg-uWSGI-devel] Bug#833067: uwsgi: does not use systemd for services
On 31 July 2016 at 15:57, Jonas Smedegaard <d...@jones.dk> wrote: > Hi Chris, > > Quoting Chris Warrick (2016-07-31 14:34:04) >> the uwsgi (and uwsgi-emperor) packages do not contain systemd service >> files, instead opting for old LSB service files. Other distros >> (Fedora, CentOS with EPEL, Arch Linux) already use systemd units. The >> uwsgi developers provide a systemd service file in the documentation >> [0]. Is it possible to update the Debian packages to ship those files >> instead of /etc/init.d/uwsgi* as well? > > I am not comfortable writing/patching/debugging systemd files yet > myself. > > I would very much welcome someone joining the team who would take the > responsibility of caring for those files, ensuring that the behaviour > across init systems is consistent (e.g. write Debian-specific systemd > files behaving same as the Debian-specific sysV files, or help adapt the > sysV files to match whatever possibly more sensible behaviour of > upstream shipped systemd files). > > Would you perhaps be interested in joining our team to care for that? Sorry, but I don’t have time to do OS development, I despise SysV init and I don’t use Debian often anyways. I’m afraid you will have to find someone else, or accept the fact that there might be some minor incompatibilities. That said, looking at /etc/init.d/uwsgi-emperor, it could be replaced by uwsgi’s proposed systemd service file pretty easily. (I have no idea about /etc/init.d/uwsgi) -- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16
Bug#833067: uwsgi: does not use systemd for services
Subject: uwsgi: add systemd service files Package: uwsgi Version: 2.0.7-1 Severity: normal Dear Maintainer, the uwsgi (and uwsgi-emperor) packages do not contain systemd service files, instead opting for old LSB service files. Other distros (Fedora, CentOS with EPEL, Arch Linux) already use systemd units. The uwsgi developers provide a systemd service file in the documentation [0]. Is it possible to update the Debian packages to ship those files instead of /etc/init.d/uwsgi* as well? [0]: http://uwsgi-docs.readthedocs.io/en/latest/Systemd.html -- System Information: Debian Release: 8.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages uwsgi depends on: ii initscripts 2.88dsf-59 ii lsb-base 4.1+Debian13+nmu1 ii uwsgi-core 2.0.7-1 uwsgi recommends no packages. uwsgi suggests no packages. -- no debconf information
Bug#791843: Bootstrap 2 theme was deleted…
This bug might be caused by the fact that Nikola deleted the Bootstrap 2 theme, and this Debian package still includes it and thinks it’s in the theme inheritance chain, which it isn’t — and that’s where jquery.min.js would be, which is why it doesn’t get picked up. -- Chris Warrick <https://chriswarrick.com/> PGP: 5EAAEA16
Bug#789072: nikola: v7.5.1 is out
On 8 July 2015 at 13:48, Agustin Henze t...@sluc.org.ar wrote: On 06/17/2015 11:49 AM, Chris Warrick wrote: Package: nikola Version: 7.1.0-1 Severity: normal Nikola v7.5.1 is out since Saturday. This package is severely out of date — the last update was in October 2014. Hi Chris, I was updating the package to nikola 7.6.0 and it is getting a little bit hard because it has strong (==version) dependencies on packages. $ grep == requirements.txt doit==0.28.0 python-dateutil==2.4.2 Yapsy==1.11.223 I have updated yapsy and doit because I am also the maintainer so no problem here, but with date-util is not the case. I don't know if nikola needs those versions strictly but if it is not the case, could you be less restrictive with the dependencies and also use = instead of ==? -- TiN Yapsy and doit were changed to = already. What version of dateutil do you have? I’ll check if it’s compatible and we could get it lower. -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789072: nikola: v7.5.1 is out
On 8 July 2015 at 14:14, Agustin Henze t...@sluc.org.ar wrote: On 07/08/2015 08:52 AM, Chris Warrick wrote: Yapsy and doit were changed to = already. What version of dateutil do you have? I’ll check if it’s compatible and we could get it lower. Seems to work fine, I tried with a new site. I will wait for your feedback before to upload it. thanks, -- TiN Upload what? A package with old dateutil support? The problem was with tzinfo files. https://github.com/getnikola/nikola/issues/1599 https://github.com/getnikola/nikola/commit/aea500e7c9dfe7552728e10df126f285ccef3687 Can you get the new code (the one that gets a stream instead of a file name) to work with the old dateutil version? If yes, great — you might need to modify the requirements list in the distribution information (.dist-info). If not, you might need to patch your source tree to undo that commit. -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#789072: nikola: v7.5.1 is out
Package: nikola Version: 7.1.0-1 Severity: normal Nikola v7.5.1 is out since Saturday. This package is severely out of date — the last update was in October 2014. Yours, Chris Warrick on behalf of the Nikola team -- Chris Warrick https://chriswarrick.com/ PGP: 5EAAEA16 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
