Re: Bug#768073: Status of package in the NEW queue
Per Lundberg wrote on 06/09/2022 at 10:36:00+0200: > Hi, > > I think we are probably a number of people excited to see this (soon!) > finally making it into Debian proper. :) I am currently running LXD as > a snap, but it would just be so much nicer and cleaner to be able to > use the "real" packages for this. > > The package is currently in the Debian "new" queue, where it has been since > August 4: https://ftp-master.debian.org/new/lxd_5.0.0-1.html > > Are there any impediments from seeing this making its way into > unstable/experimental anytime soon, or is it just a matter of the FTP masters > not having had time to look into it yet? > > Best regards, Something stays in NEW until a ftpmaster has time to review it. From there, either it's accepted or rejected, but in both cases it gets out from NEW. Nothing can be done on our side, except asking ftpmasters to review faster, but it's something to do only in urgent cases, and a new package, even as exciting as LXD, is anything but urgent. Cheers! -- PEB signature.asc Description: PGP signature
Re: Bug#998223: Contributors for Mailman 3 in Debian / your RFH
De : Charlemagne Lasse À : Debian Mailman Team ; Amir Sarabadani ; Kunal Mehta ; Moritz Muehlenhoff ; debian-wnpp@lists.debian.org; Pierre-Elliott Bécue ; Jonas Meurer ; 998...@bugs.debian.org Date : 15 oct. 2022 09:31:10 Objet : Re: Bug#998223: Contributors for Mailman 3 in Debian / your RFH > Hi, > > Where can we find results from the new contributors? Because it looks > at the moment like Debian bookworm might become the third Debian > release (after buster + bullseye) which is unsuitable as a base system > for software project servers (redmine + mailman3 + gitolite). At > least, for the last two releases, redmine was to blame here but now it > looks like mailman3 might be the blocker. > > See also https://lists.debian.org/debian-devel-announce/2022/10/msg4.html > for the Debian bookworm timeline Hi, gitolite has been superseeded by gitolite3 a long time ago, and the latter is in bullseye, in buster and will be in bookworm. See https://tracker.debian.org/pkg/gitolite3 Redmine indeed had troubles. Mailman3 has been part of buster and bullseye, but the release of sqlalchemy 1.4 is not compatible with it and therefore there is a chance that it will not make it in bookworm. There is nothing that any contributor can do except taking the time to help mailman upstream to be fixed and work with sqlalchemy 1.4. Regards. -- Pierre-Elliott Bécue
Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite
Le dimanche 18 juin 2017 à 22:34:07+0900, Marc Dequènes a écrit : > Quack, > > Version 3.1 was released recently, it's working well (except migrations > still not perfect), and I believe it's the right time to have a package > ready (would have been too late for Stretch). Agreed, I'm on vacation but I'll be back into business by June the 25th. > So, do you plan to continue your work? Of course! > Btw I believe you should have a separate mailman3-hyperkitty package, as > you may wish to run your archiver separately IIUC. It's already the case, see #799287 Cheers! -- PEB signature.asc Description: PGP signature
Bug#866009: ITP: python-aiosmtpd -- Python3 asyncio based SMTP server
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-aiosmtpd Version : 1.0 Upstream Author : Barry Warsaw , Eric V. Smith, Andrew Kuchling, Jason Coombs * URL : https://github.com/aio-libs/aiosmtpd * License : Apache 2 Programming Lang: Python Description : Python3 asyncio based SMTP server This is a server for SMTP and related protocols, similar in utility to the standard library’s smtpd.py module, but rewritten to be based on asyncio for Python 3. This package is a new dependency for mailman3-core package that I first intended to package in sept. 2015[1]. Since then, we decided to wait until Mailman 3.1 to finalize packaging as python3.5 became the main version of python in debian and mailman3.0.x was not fully 3.5 operative. Now that 3.1 is out, it's time to finish this work, and this package seems to be the only missing dependency. This package would be maintained by me and the DPMT. Barry Warsaw offered to sponsor me on this one. Cheers. [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799281
Bug#866009: ITP: python-aiosmtpd -- Python3 asyncio based SMTP server
Le lundi 26 juin 2017 à 16:55:28+0200, Pierre-Elliott Bécue a écrit : > Package: wnpp > Severity: wishlist > Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= > > * Package name: python-aiosmtpd > Version : 1.0 > Upstream Author : Barry Warsaw , Eric V. Smith, > Andrew Kuchling, Jason Coombs > * URL : https://github.com/aio-libs/aiosmtpd > * License : Apache 2 > Programming Lang: Python > Description : Python3 asyncio based SMTP server > > This is a server for SMTP and related protocols, similar in utility to > the standard library’s smtpd.py module, but rewritten to be based on > asyncio for Python 3. > > This package is a new dependency for mailman3-core package that I first > intended to package in sept. 2015[1]. Since then, we decided to wait > until Mailman 3.1 to finalize packaging as python3.5 became the main > version of python in debian and mailman3.0.x was not fully 3.5 > operative. > > Now that 3.1 is out, it's time to finish this work, and this package > seems to be the only missing dependency. > > This package would be maintained by me and the DPMT. Barry Warsaw > offered to sponsor me on this one. > > Cheers. > > [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799281 The package builds properly. Lintian complains about a .gitignore file that hangs around, and there is a small bug upstream on some tests that lead to raises during dh_auto_test (but the tests still succeed). I'll wait for a push into pypi of a fixed version and then RFS. -- PEB
Bug#795017: ITA: pyvtk -- module for manipulating VTK files
Control: retitle -1 ITA: pyvtk -- module for manipulating VTK files I intend to adopt this package. I did simplify the d/rules and made a new upstream release. Link of my repo: https://github.com/P-EB/pyvtk Will get in touch with DPMT asap. -- PEB
Bug#799288: ITP: mailman3-hyperkitty
I still intend to package this, but the current state of its dependencies in sid prevent me to do so. -- PEB
Bug#799285: [Uptade] ITP: mailman3-postorius -- Django web user interface for accessing GNU Mailman3
Control: retitle -1 ITP: mailman3-postorius -- Django web user interface for accessing GNU Mailman3 Control: owner -1 Pierre-Elliott Bécue Waiting for a python3.5 compatible version of mailman3 core for a RFS. -- PEB
Bug#799281: ITP: mailman3-core -- Mailing list management system
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3-core Version : 3.0.0 Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj * URL : http://list.org/ * License : GPLv3 Programming Lang: Python3 Description : Mailing list management system GNU Mailman3 is a package providing mailing list management system. This would be the bare core of Mailman3, without client package, HyperKitty or Postorius, that would be packaged in different sources packages. There is currenctly mailman2 in Debian archive, and I was considering involve myself in packaging mailman3, Mailman developers seems to think that it is a pretty good idea, but they suggested me to wait 'till 3.1.0 is out. I'm currently looking for a sponsor as I'm not a Debian Developer, nor used to build brand new packages. Since 3.1 is not released yet, I've some time to learn but I'll be happy to work with people already used to packaging. This bug report is CC-ed to Debian mailman team, as I do intend to collaborate with them, I hope I'll be helpful. This bug report will come with the others for the others components of Mailman3 suite. I hope this is the good way of doing ITP
Bug#799283: ITP: mailman3-core -- Mailing list management system
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3-core Version : 1.0.0 Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj * URL : http://list.org/ * License : LGPLv3 Programming Lang: Python2 Description : Official python bindings for mailman3-core REST API This package would provide the client for REST API of mailman3-core. It would depend on mailman3-core, and provide the other minimal part in order to have mailman3 working correctly. -- There is currenctly mailman2 in Debian archive, and I was considering involve myself in packaging mailman3 suite, Mailman developers seems to think that it is a pretty good idea, but they suggested me to wait 'till mailman3-core version 3.1.0 is out. I'm currently looking for some sponsorship as I'm not a Debian Developer, nor used to build brand new packages. Since version 3.1 is not released yet, I've some time to learn but I'll be happy to work with people already used to packaging. This bug report is CC-ed to Mailman for Debian team, as I do intend to collaborate with them, I hope I'll make myself helpful. This bug report will come with the others for the others components of Mailman3 suite. I hope this is the good way of doing ITP
Bug#799283: ITP: mailman3-client -- Mailing list management system
On jeu. 17 sept. 2015 à 16:25:25, Pierre-Elliott Bécue wrote: > Package: wnpp > Severity: wishlist > Owner: "Pierre-Elliott Bécue" > > * Package name: mailman3-core > Version : 1.0.0 > Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian > Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj > * URL : http://list.org/ > * License : LGPLv3 > Programming Lang: Python2 > Description : Official python bindings for mailman3-core REST API > > This package would provide the client for REST API of mailman3-core. It > would depend on mailman3-core, and provide the other minimal part in > order to have mailman3 working correctly. > > -- > > There is currenctly mailman2 in Debian archive, and I was considering > involve myself in packaging mailman3 suite, Mailman developers seems to > think that it is a pretty good idea, but they suggested me to wait 'till > mailman3-core version 3.1.0 is out. > > I'm currently looking for some sponsorship as I'm not a Debian > Developer, nor used to build brand new packages. Since version 3.1 is > not released yet, I've some time to learn but I'll be happy to work with > people already used to packaging. > > This bug report is CC-ed to Mailman for Debian team, as I do intend to > collaborate with them, I hope I'll make myself helpful. > > This bug report will come with the others for the others components of > Mailman3 suite. I hope this is the good way of doing ITP Oops, typo spotted here, proposed Package name would be mailman3-client. Sorry for that. -- PEB
Bug#799285: ITP: mailman3-core -- Mailing list management system
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3-postorius Version : 1.0.1 Upstream Author : Anna Senarclens de Grancy, Benedict Stein, Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj * URL : http://list.org/ * License : GPLv3 Programming Lang: Python2 Description : Django web user interface for accessing GNU Mailman3 Mailman3 comes as a suite of many components. This one provides a django interface to access GNU Mailman3. It would be an administration interface, excluding archive access to mailing lists, which is a specific component. -- The first version of this django site has been developped during GSoC 2010 and 2011 by Benedict Stein and Anna Senarclens de Grancy. There is currenctly mailman2 in Debian archive, and I was considering involve myself in packaging mailman3, Mailman developers seems to think that it is a pretty good idea, but they suggested me to wait 'till core version 3.1.0 is out. I'm currently looking for some sponsorship as I'm not a Debian Developer, nor used to build brand new packages. Since 3.1 is not released yet, I've some time to learn but I'll be happy to work with people already used to packaging. This bug report is CC-ed to Debian mailman team, as I do intend to collaborate with them, I hope I'll be helpful. This bug report will come with the others for the others components of Mailman3 suite. I hope this is the good way of doing ITP
Bug#799285: ITP: mailman3-postorius -- Mailing list management system
This package would depend on django. Is there specific things I'd have to take care about when packaging? Thanks. -- PEB
Bug#799287: ITP: mailman3-hyperkitty -- Mailing list management system
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3-hyperkitty Version : 1.0.0 Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj * URL : http://list.org/ * License : GPLv3 Programming Lang: Python2 Description : Django app to access Mailman3 archives Mailman3 comes as a suite of different components to provide modularity. Hyperkitty is the web app to access archives. -- It requires a specific mailman3 plugin to send the mails to HK in order to have them archived. This one will be packaged independently. There is currenctly mailman2 in Debian archive, and I was considering involve myself in packaging mailman3, Mailman developers seems to think that it is a pretty good idea, but they suggested me to wait 'till 3.1.0 is out. I'm currently looking for some sponsorship as I'm not a Debian Developer, nor used to build brand new packages. Since 3.1 is not released yet, I've some time to learn but I'll be happy to work with people already used to packaging. This bug report is CC-ed to Debian mailman team, as I do intend to collaborate with them, I hope I'll be helpful. This bug report will come with the others for the others components of Mailman3 suite. I hope this is the good way of doing ITP As it is a django using package, I don't know if there is specific things to take care about. Please help me know.
Bug#799288: ITP: mailman3-hyperkitty-plugin -- Mailing list management system
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3-hyperkitty-plugin Version : 1.0.0 Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj * URL : http://list.org/ * License : GPLv3 Programming Lang: Python2 Description : Mailman archiver plugin for HyperKitty Mailman3 comes as a suite of components. Hyperkitty is the web app designed to show archives. This plugin comes over mailman3-core and makes it send emails to hyperkitty in order to have it archive them. -- There is currenctly mailman2 in Debian archive, and I was considering involve myself in packaging mailman3, Mailman developers seems to think that it is a pretty good idea, but they suggested me to wait 'till 3.1.0 is out. I'm currently looking for some sponsorship as I'm not a Debian Developer, nor used to build brand new packages. Since 3.1 is not released yet, I've some time to learn but I'll be happy to work with people already used to packaging. This bug report is CC-ed to Debian mailman team, as I do intend to collaborate with them, I hope I'll be helpful. This bug report will come with the others for the others components of Mailman3 suite. I hope this is the good way of doing ITP
Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: mailman3 Version : 1.0.0 Upstream Author : Pierre-Elliott Bécue * URL : none * License : GPLv3 Programming Lang: ? Description : Mailman3 mailing list manager suite This package would depend on mailman3-core, mailman3-client, mailman3-postorius, mailman3-hyperkitty and mailman3-hyperkitty-plugin to provide the full suite of Mailman3 components.
Bug#799283: ITP: mailman3-core -- Mailing list management system
On jeu. 17 sept. 2015 à 16:59:21, Geert Stappers wrote: > Control: retitle -1 ITP: mailman3-client -- Official python bindings for > mailman3-core REST API > > > On Thu, Sep 17, 2015 at 04:25:25PM +0200, Pierre-Elliott Bécue wrote: > > Package: wnpp > > Severity: wishlist > > Owner: "Pierre-Elliott Bécue" > > > > * Package name: mailman3-core > > mailman3-core is http://bugs.debian.org/799281 > so retitled this one to 'mailman3-client' > > > > Version : 1.0.0 > > Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian > > Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj > > * URL : http://list.org/ > > * License : LGPLv3 > > Programming Lang: Python2 > > Description : Official python bindings for mailman3-core REST API > > > > This package would provide the client for REST API of mailman3-core. It > > would depend on mailman3-core, and provide the other minimal part in > > order to have mailman3 working correctly. Hey, I did the retitle, but you probably did on the same time. I'll let it as you put it. Thanks for your contribution. :) -- PEB
Bug#799285: ITP: mailman3-core -- Mailing list management system
Control: retitle -1 ITP: mailman3-postorius -- Django web user interface for accessing GNU Mailman3 On jeu. 17 sept. 2015 à 17:04:02, Geert Stappers wrote: > Control: retitle -1 mailman3-postorius -- Django web user interface for > accessing GNU Mailman3 Adding ITP: to make it better understandable from https://bugs.debian.org/cgi-bin/pkgreport.cgi?package=wnpp;dist=unstable Thanks. -- PEB
Bug#799283: ITP: mailman3-client -- Official python bindings for mailman3-core REST API
On jeu. 17 sept. 2015 à 17:50:23, Geert Stappers wrote: > On Thu, Sep 17, 2015 at 05:14:33PM +0200, Pierre-Elliott Bécue wrote: > > > > Hey, > > > > I did the retitle, but you probably did on the same time. > > > > I'll let it as you put it. > > > > Original > >Bug#799281: ITP: mailman3-core -- Mailing list management system >Bug#799283: ITP: mailman3-core -- Mailing list management system >Bug#799285: ITP: mailman3-core -- Mailing list management system > > > After my retitle > >Bug#799281: ITP: mailman3-core -- Mailing list management system >Bug#799283: ITP: mailman3-client -- Official python bindings for > mailman3-core REST API >Bug#799285: ITP: mailman3-postorius -- Django web user interface for > accessing GNU Mailman3 > > Those are changes on the on bugreport titles, an change the outside. > > Thing in the inside of #799283 is that is says: > > Package name: mailman3-core > > I might be (probaby I am) wrong about titling it 'mailman3-client'. > Feel free to change in something else. > > For your information > > #799281 has Package name: mailman3-core > #799285 has Package name: mailman3-postorius > > on the inside > > > > Thanks for your contribution. :) > > Hey, it is a way to say 'Why three times "ITP: mailman3-core" ??' ;-) Yeah, I completely messed up my three first ITP. :( Sorry for that, it should not have happened. -- PEB signature.asc Description: Digital signature
Bug#799285: ITP: mailman3-postorius -- Django web user interface for accessing GNU Mailman3
On ven. 18 sept. 2015 à 08:21:32, Geert Stappers wrote: > On Thu, Sep 17, 2015 at 04:34:45PM +0200, Pierre-Elliott Bécue wrote: > > > > * Package name: mailman3-postorius > > Programming Lang: Python2 > > Description : Django web user interface for accessing GNU Mailman3 > > > > Mailman3 comes as a suite of many components. This one provides a django > > interface to access GNU Mailman3. It would be an administration > > interface, excluding archive access to mailing lists, which is a > > specific component. > > For what is worth. From > https://packages.debian.org/stretch/python-django-mumble > are these strings: > > Package: python-django-mumble (2.13-1) > > Mumble-Server config application for Django > > mumble-django is a Django web interface application > that configures a Murmur server. > > > Thing I want to say: > > Cool that mailman3 is being packaged for Debian. > > When I did read "django web user interface", > I couldn't resist to tell that "django-mumble" exists. > > I don't known how knowledge from that packaging can be used, > I just hope that sharing this information helps. Ack, and thanks for the intel, I'll have a look at python-django-mumble. Cheers -- PEB
Bug#799281: Any update to packaging Mailman3-core ?
On mer. 28 oct. 2015 à 20:19:49, shirish wrote: > Dear Pierre-Elliott Bécue, > > Any update on the packaging of Mailman-3-core ? > > Looking forward to learn more. Good afternoon, Heres some update: * I had some troubles with dependencies, that were fixed in the begining of October. * I met a lot of troubles having tests working, because they require the package to be installed. finally worked around using adt. * The packaging was working under experimental at the begining of October * The packaging is working under sid for some day * I'm currently working on a patch to move some binaries in /var/lib/mailman3/bin instead of /usr/bin, and I intend to see with upstream if they agree on merging that patch (some binaries have cool names but these names are too generic) * I'm also designing a basic configuration file and systemd unit So, it's going on, slowly. Anyway, it is planned to wait the next (minor) release before packaging, so that some issues reported since initial release will be fixed. I hope my answer satisfies your curiosity. :) -- PEB
Bug#799281: Any update to packaging Mailman3-core ?
On mer. 28 oct. 2015 à 22:53:48, shirish wrote: > at bottom :- > > On 10/28/2015 08:47 PM, Pierre-Elliott Bécue wrote: > >On mer. 28 oct. 2015 à 20:19:49, shirish wrote: > >>Dear Pierre-Elliott Bécue, > >> > >>Any update on the packaging of Mailman-3-core ? > >> > >>Looking forward to learn more. > > > >Good afternoon, > > > >Heres some update: > > > > * I had some troubles with dependencies, that were fixed in the begining of > >October. > > * I met a lot of troubles having tests working, because they require the > >package to be installed. finally worked around using adt. > > * The packaging was working under experimental at the begining of October > > * The packaging is working under sid for some day > > * I'm currently working on a patch to move some binaries in > >/var/lib/mailman3/bin instead of /usr/bin, and I intend to see with > >upstream if they agree on merging that patch (some binaries have cool > > names > >but these names are too generic) > > * I'm also designing a basic configuration file and systemd unit > > > >So, it's going on, slowly. Anyway, it is planned to wait the next (minor) > >release > >before packaging, so that some issues reported since initial release will be > >fixed. > > > >I hope my answer satisfies your curiosity. :) > > > > Thank you. So you are awaiting Mailman 3.0.1 . I am guessing you are > pointing to this > https://gitlab.com/groups/mailman/issues?milestone_id=&scope=all&sort=created_desc&state=opened&utf8=%E2%9C%93&assignee_id=&author_id=&milestone_title=3.0.1&label_name= > > So seems only 4 bugs remaining for 3.0.1 to appear and 2 of them have > patches ...but nothing much mentioned on them by either Barry or Abhilash. > It seems it will take a while. Yeah, maybe. My goal is to make RFS by the end of december, it allows me to take some time being sure I'm not doing wrong things. It'll also help me ensure to be able to deliver all the package suite at once. -- PEB
Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite
Le mardi 22 mars 2016 à 15:44:18-0400, anarcat a écrit : > Any progress here? Hey, mailman3-core, mailman3-postorius and mailman3-client are packaged. I'm working on optimizing the first one as it's the bigger one. I'm working on hyperkitty, which should be good soon. I'll have to work on contrib files (manpages, config files), but I think I might be able to finish a first glance of the suite for testing by the end of April. I'm currently seeking for reviews and advice as I'm not sure I'll think about everything. VCS for three first packages : https://github.com/P-EB/mailman3-core https://github.com/P-EB/mailman3-postorius https://github.com/P-EB/mailman3-client I'm mostly working on my gitlab, but it seems better to share on github the work. Cheers, -- PEB signature.asc Description: PGP signature
Bug#704706: ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona)
Control: owner -1 ! Control: retitle -1 ITP: python-browserid -- Python library for the BrowserID Protocol (Mozilla Persona) Hey, I intend to package. VCS is up, the package builds correctly. VCS: https://github.com/P-EB/python-browserid Build results: https://peb.pimeys.fr/packages/python-browserid/ Comments welcome, and if everything seems okay, please, I'd like to request for sponsorship on this package. -- PEB
Bug#799287: Packaging dependencies for mailman3-hyperkitty
Hey, I'm packaging mailman3 suite, and I'm currently working on HyperKitty (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799287 for the ITP). The issue I met is that some dependencies are not yet packaged in Debian. Here is a list : * robot-detection * django-paintstore * django-gravatar2 * django-browserid The latter relies on Mozilla Persona which is due to shutdown in Nov. 2016, so I'll drop it out and suggest upstream to remove this (small) dependency. django-paintstore is not developped nor supported anymore by upstream, I'll try to look to alternatives and discuss with upstream regarding what to do. robot-detection suffers the same illness, but it's tiny, it's possible to integrate it in hyperkitty, or make it optionnal. That leaves me with django-gravatar2, that seems useful, and is still developed. I heard there is some kind of "canonical" way of packaging django apps. As I'm not used to that, I'm here to ask advice. I'll create an ITP, and I'm willing to hear any suggestion you could make. Thanks, and cheers, -- PEB
Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.
Package: wnpp Severity: wishlist Owner: "Pierre-Elliott Bécue" * Package name: python-django-gravatar2 Version : 1.4.0 Upstream Author : Tristan Waddington * URL : https://github.com/twaddington/django-gravatar * License : MIT Programming Lang: Python Description : Essential Gravatar support for Django. Features helper methods and templatetags. A lightweight django-gravatar app. Includes helper methods for interacting with gravatars outside of template code. . It features the following: . * Helper methods for constructing a gravatar url and checking an email for an existing gravatar * Templatetags for generating a gravatar url or gravatar tag. This package provides gravatar features that are not yet present in django packages in Debian. It's also a dependency of HyperKitty, that I'm currently packaging. I'd be happy to co maintain it with the DPMT, and I look for a sponsor who knows about django packaging.
Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.
Le jeudi 24 mars 2016 à 12:09:00-0400, Pierre-Elliott Bécue a écrit : > Package: wnpp > Severity: wishlist > Owner: "Pierre-Elliott Bécue" > > * Package name: python-django-gravatar2 > Version : 1.4.0 > Upstream Author : Tristan Waddington > * URL : https://github.com/twaddington/django-gravatar > * License : MIT > Programming Lang: Python > Description : Essential Gravatar support for Django. Features helper > methods and templatetags. > > A lightweight django-gravatar app. Includes helper methods for interacting > with gravatars > outside of template code. > . > It features the following: > . > * Helper methods for constructing a gravatar url and checking an email for > an existing >gravatar > * Templatetags for generating a gravatar url or gravatar tag. > > This package provides gravatar features that are not yet present in django > packages in Debian. It's also a dependency of HyperKitty, that I'm currently > packaging. > > I'd be happy to co maintain it with the DPMT, and I look for a sponsor who > knows about django packaging. Package VCS can be found here: https://gitlab.pimeys.fr/PEB/python-django-gravatar2 Package results can be found there: https://peb.pimeys.fr/packages/python-django-gravatar2/ -- PEB
Bug#799287: Packaging dependencies for mailman3-hyperkitty
Le vendredi 25 mars 2016 à 13:02:55+0800, Paul Wise a écrit : > On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote: > > > Packaging dependencies for mailman3-hyperkitty > > Does HyperKitty depend on mailman3 or just enhance it by providing an > archive web interface? If the latter, I would suggest calling it > hyperkitty instead of mailman3-hyperkitty. > > > robot-detection suffers the same illness, but it's tiny, it's possible to > > integrate it in hyperkitty, or make it optionnal. > > Embedded code copies are against Debian policy, please package it > separately or get upstream to switch to something else. > > https://wiki.debian.org/EmbeddedCodeCopies > > Something like that sounds like it isn't possible to keep usefully > up-to-date in Debian stable though, since the landscape of robots on > the web will be changing continually and many will be aiming to > emulate browsers. > > https://pypi.python.org/pypi/robot-detection > > In addition, it seems to be woefully inadequate for that since the API > doesn't appear to take into account IP address ranges. > > It also depends on the robotstxt.org database, which would need to be > packaged separately and is also no longer kept up to date at this > time: > > http://www.robotstxt.org/db.html > > "This robots database is currently undergoing re-engineering. Due to > popular demand we have restored the existing data, but > addition/modification are disabled." > > As the page says, there is a better database of user-agents available > > http://www.botsvsbrowsers.com/ > http://www.botsvsbrowsers.com/category/1/index.html > > Unfortunately this is incompatible with the data format used by > robotstxt.org/robot-detection: > > http://www.robotstxt.org/db/all.txt > > So you can see from the botsvsbrowsers.com data, the User-Agent field > is often bogus or contains vulnerability attack patterns and is thus > mostly not useful at all and should probably just be ignored by all > web apps at this point. > > So I would suggest convincing upstream to remove whatever use of > robot-detection is present in mailman3 or hyperkitty. That's in progress, the only goal of this detection is to deactivate javascript dynamic load of threads. We're thinking about alternative solutions. > > That leaves me with django-gravatar2, that seems useful, and is still > > developed. I heard there is some kind of "canonical" way of packaging django > > apps. As I'm not used to that, I'm here to ask advice. > > I would suggest upstream switch from Gravatar (a centralised > proprietary service) to Libravatar (a federated Free Software service > that falls back on Gravatar): > > https://www.libravatar.org/ I understand your point, and I'll think about it, but my goal is to make upstream remove obsolete dependencies. django-libravatar seems to be the only project that bundles support for that, and it's not maintained, whereas django-gravatar2 is still maintained. So, for now, I think that I'd rather have a first mailman3 suite in debian, and then, think about how to make things better. :) > Re canonical django packaging, you may be talking about this: > > https://wiki.debian.org/DjangoPackagingDraft > > There are also lots of python-django-* packages in Debian that you > could look at. Thanks! -- PEB
Bug#819183: ITP: python-django-gravatar2 -- Essential Gravatar support for Django. Features helper methods and templatetags.
Le vendredi 25 mars 2016 à 13:11:33+0800, Paul Wise a écrit : > On Fri, Mar 25, 2016 at 12:09 AM, Pierre-Elliott Bécue wrote: > > > Description : Essential Gravatar support for Django. Features helper > > methods and templatetags. > > Could you ask upstream to switch to Libravatar instead (it has > backwards compat for Gravatar). Probably they will want to rename the > software after that. > > https://www.libravatar.org/ Hey, I'll ask if they coul add support for libravatar, either by forking, or by implementing new functions/tags, but I've no guarantee they'll say yes, and as a first step, packaging django-gravatar2 seems relevant to me. :) Cheers, and thanks for the idea! -- PEB
Bug#799287: Packaging dependencies for mailman3-hyperkitty
Le 26 mars 2016 04:57:34 GMT+01:00, Paul Wise a écrit : >On Fri, 2016-03-25 at 19:35 +0100, Pierre-Elliott Bécue wrote: > >> That's in progress, the only goal of this detection is to deactivate >> javascript dynamic load of threads. We're thinking about alternative >> solutions. > >I don't understand why you would deactivate JavaScript dynamic load for >bots? Typically they don't support JavaScript (except Google) and you >should have a fallback for people who turn off JavaScript anyway. > >I hope mailman3/HyperKitty web interfaces use progressive enhancement: > >http://en.wikipedia.org/wiki/Progressive_enhancement > >> I understand your point, and I'll think about it, but my goal is to >make >> upstream remove obsolete dependencies. django-libravatar seems to be >the >> only project that bundles support for that, and it's not maintained, >whereas >> django-gravatar2 is still maintained. > >I guess you are talking about this project, it hasn't seen any issues >filed so probably just works as-is without needing any changes? > >https://github.com/fnp/django-libravatar > >> So, for now, I think that I'd rather have a first mailman3 suite in >debian, >> and then, think about how to make things better. :) > >I see. > >-- >bye, >pabs > >https://wiki.debian.org/PaulWise Can't tell exactly regarding javascript question. Sorry. But I'll forward your comments, thanks for taking the time to make them. :) -- PEB
Bug#799288: Acknowledgement (ITP: mailman3-hyperkitty-plugin -- Mailing list management system)
Control: retitle -1 ITP: mailman-hyperkitty -- Plugin for interaction between mailman core server and hyperkitty archiver. In new. -- PEB
Bug#799292: ITP: mailman-suite -- Mailman3 mailing list manager suite
Control: retitle -1 ITP: mailman-suite -- Mailman3 mailing list manager suite Soon. -- PEB
Bug#877878: ITP: mailman-suite -- Django project integrating Mailman3 Postorius and HyperKitty
retitle -1 ITP: mailman-suite -- Django project integrating Mailman3 Postorius and HyperKitty -- PEB
Bug#773402: ITP: libgaminggear -- Provides functionality for gaming input devices
owner 773402 Pierre-Elliott Bécue retitle 773402 ITP: libgaminggear -- Provides functionality for gaming input devices thanks I'm in. * Package name: libgaminggear Version : 0.15.1 Upstream Author : Stefan Achatz * URL : https://sourceforge.net/projects/libgaminggear/ * License : GPL2 Programming Lang: C Description : Provides functionality for gaming input devices libgaminggear is a support library for userspace device input drivers to facilitate implementation of advanced features commonly found in gaming peripherals, such as macros. This library needs to be packaged in order to package roccat-tools. -- PEB signature.asc Description: PGP signature
Bug#718032: ITP: roccat-tools -- Drivers for roccat devices
owner 718032 Pierre-Elliott Bécue retitle 718032 ITP: roccat-tools -- Drivers for roccat devices thanks I'm in. * Package name: roccat-tools Version : 5.7.0 Upstream Author : Stefan Achatz * URL : https://sourceforge.net/projects/libgaminggear/ * License : GPL2 Programming Lang: C Description : Software and information to get Roccat hardware working This package will provide information and software to get hardware from the manufacturer Roccat to work under linux. I hope to have it done by the end of December. Cheers, -- PEB signature.asc Description: PGP signature
Bug#886717: ITP: coreapi -- Python client library for Core API
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: coreapi Version : 2.3.3 Upstream Author : Tom Christie * URL : https://github.com/core-api/python-client * License : BSD Programming Lang: Python Description : Python client library for Core API Core API is a format-independent Document Object Model for representing Web APIs. It can be used to represent either Schema or Hypermedia responses, and allows one to interact with an API at the layer of an application interface, rather than a network interface. This package would provide a python client for such APIs. It's an optional dependency of djangorestframework. This package would be maintained under the DPMT flag. -- PEB
Bug#886783: ITP: coreschema -- Python utilities to describe an abstract data schema to coreapi
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: coreschema Version : 0.0.4 Upstream Author : Tom Christie * URL : https://github.com/core-api/python-coreschema * License : BSD Programming Lang: Python Description : Python utilities to describe an abstract data schema to coreapi Core API is a format-independent Document Object Model for representing Web APIs. It can be used to represent either Schema or Hypermedia responses, and allows one to interact with an API at the layer of an application interface, rather than a network interface. This package, which is required by coreapi, provides an abstract Python library to describe classic data (Integers, Strings et al.). This package would be maintained under DPMT umbrella. -- PEB
Bug#886786: ITP: python-jsonhyperschema-codec -- A JSON Hyperschema codec for Core API.
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-jsonhyperschema-codec Version : 1.0.2 Upstream Author : Tom Christie * URL : https://github.com/core-api/python-jsonhyperschema-codec * License : BSD Programming Lang: Python Description : A JSON Hyperschema codec for Core API. Core API is a format-independent Document Object Model for representing Web APIs. It can be used to represent either Schema or Hypermedia responses, and allows one to interact with an API at the layer of an application interface, rather than a network interface. This package provides a third-party codec to coreapi in order to allow it to support jsonhyperschema. -- PEB
Bug#886788: ITP: python-hal-codec -- A HAL codec for Core API
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-hal-codec Version : 1.0.2 Upstream Author : Tom Christie * URL : https://github.com/core-api/python-hal-codec * License : BSD Programming Lang: Python Description : A HAL codec for Core API Core API is a format-independent Document Object Model for representing Web APIs. It can be used to represent either Schema or Hypermedia responses, and allows one to interact with an API at the layer of an application interface, rather than a network interface. This package provides a third-party codec to handle HAL Hypermedia format. This package would be maintained unter the DPMT roof. -- PEB
Bug#886789: ITP: python-openapi-codec -- An OpenAPI codec for Core API
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-openapi-codec Version : 1.3.2 Upstream Author : Tom Christie * URL : https://github.com/core-api/python-openapi-codec * License : BSD Programming Lang: Python Description : An OpenAPI codec for Core API Core API is a format-independent Document Object Model for representing Web APIs. It can be used to represent either Schema or Hypermedia responses, and allows one to interact with an API at the layer of an application interface, rather than a network interface. This package provides a third-party codec for core API to support OpenAPI format. This package would be maintained under the DPMT sky. -- PEB
Bug#886800: ITP: python-itypes -- Python basic immutable containers types library.
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: itypes Version : 1.1.0 Upstream Author : Tom Christie * URL : https://github.com/tomchristie/itypes * License : BSD Programming Lang: Python Description : Python basic immutable containers types library. This package provides basic immutable container types for Python. Upstream source code is designed for simplicity over performance. The classic use case of these is in circumstances where it may result in more comprehensible code, or when one wants to create custom types with restricted, immutable interfaces. This package is a dependency of coreapi, and will be maintained under DPMT banner. -- PEB
Bug#886800: ITP: python-itypes -- Python basic immutable containers types library.
Le mercredi 10 janvier 2018 à 00:37:18+0100, Pierre-Elliott Bécue a écrit : > Package: wnpp > Severity: wishlist > Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= > > * Package name: itypes > Version : 1.1.0 > Upstream Author : Tom Christie > * URL : https://github.com/tomchristie/itypes > * License : BSD > Programming Lang: Python > Description : Python basic immutable containers types library. > > This package provides basic immutable container types for Python. > > Upstream source code is designed for simplicity over performance. > > The classic use case of these is in circumstances where it may result in more > comprehensible code, or when one wants to create custom types with restricted, > immutable interfaces. > > This package is a dependency of coreapi, and will be maintained under DPMT > banner. https://anonscm.debian.org/git/python-modules/packages/itypes.git -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 signature.asc Description: PGP signature
Bug#868845: RFA: pytest-httpbin -- py.test plugin to provide a local httpbin
Dear Daniel, I updated the package, and put new upstream release (0.3.0) in the VCS. I'm eager to comaintain the package with you (it'll drop your workload, but I'd rather work with someone who already knows the package for some time at least). I'm DM, so I have no upload rights. Please have a look and send it on the debian's repo if you're fine with my changes. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 signature.asc Description: PGP signature
Bug#886800: ITP: itypes -- Python basic immutable containers types library.
Control: retitle -1 ITP: itypes -- Python basic immutable containers types library. Retitling as I changed the source package name. -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 signature.asc Description: PGP signature
Bug#799281: Any update to packaging Mailman3-core ?
Le dimanche 07 février 2016 à 13:23:15+0100, Andreas Hubel a écrit : > Dear Pierre-Elliott Bécue, > > On Wed, 28 Oct 2015 18:29:53 +0100 Pierre-Elliott wrote: > > My goal is to make RFS by the end of december, it allows me to take some > > time being sure I'm not doing wrong things. It'll also help me ensure to be > > able to deliver all the package suite at once. > > Any updates? Good morning, Yes! I successfully built something that made me happy, but so far I asked for some reviewing, and I got only one or two answers. I took the advice into account, I'll probably retry to ask some reviews soon, then I'll go in packaging all the things. My main issue for now is about configuring correctly mailman3 to have a properly running server on install, even if the administrator will need to reconfigure some things. -- PEB signature.asc Description: Digital signature
Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!
Le lundi 14 décembre 2015 à 17:01:57+0100, Pierre-Elliott Bécue a écrit : > Le lundi 23 novembre 2015 à 02:56:27+0100, Pierre-Elliott Bécue a écrit : > > Le vendredi 11 septembre 2015 à 00:49:44+0200, Pierre-Elliott Bécue a écrit > > : > > > [packaging mailman3] > > > > Hey, > > > > Here is an update. > > > > For now on, I focused on mailman3-core package in order to get good > > practices working. > > > > One can find my work here : https://github.com/P-EB/mailman3-core > > > > I'm working on having working systemd/sysv services and after that it'll be > > a good idea to try installing the package and see how it goes. > > > > I also have to design a good config file for debian, (see > > debian/contrib/mailman.cfg in master branch). Any suggestion is welcome! > > > > Cheers > > Small bump here, I'd appreciate if somebody finds the time to tell me two > things: > > * Is my config file enough for a start ? > * Is my systemd service good to have mailman started properly ? > > I'd rather be sure it's okay before writing a sysv service. > > You can find contrib files in debian/contrib. Hello! Before requesting for sponsorship, and packaging officially the other components of mailman3, I'd like some "testers" for the core package I built, in order to be sure that it works, and that I will not introduce some stupid caveats on the packaging of the other components. .deb can be found here: http://peb.pimeys.fr/mailman/mailman3-core/ git repo can be found there: https://gitlab.pimeys.fr/PEB/mailman3-core and there: https://github.com/P-EB/mailman3-core Any volunteer welcome! Please, I need your help, I cannot review my work alone! :) -- PEB
Bug#799283: ITP: mailman3-client -- Mailing list management system
Le jeudi 17 septembre 2015 à 16:30:04+0200, Pierre-Elliott Bécue a écrit : > On jeu. 17 sept. 2015 à 16:25:25, Pierre-Elliott Bécue wrote: > > Package: wnpp > > Severity: wishlist > > Owner: "Pierre-Elliott Bécue" > > > > * Package name: mailman3-client > > Version : 1.0.0 > > Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian > > Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj > > * URL : http://list.org/ > > * License : LGPLv3 > > Programming Lang: Python2 > > Description : Official python bindings for mailman3-core REST API > > > > This package would provide the client for REST API of mailman3-core. It > > would depend on mailman3-core, and provide the other minimal part in > > order to have mailman3 working correctly. > > > > -- > > > > There is currenctly mailman2 in Debian archive, and I was considering > > involve myself in packaging mailman3 suite, Mailman developers seems to > > think that it is a pretty good idea, but they suggested me to wait 'till > > mailman3-core version 3.1.0 is out. > > > > I'm currently looking for some sponsorship as I'm not a Debian > > Developer, nor used to build brand new packages. Since version 3.1 is > > not released yet, I've some time to learn but I'll be happy to work with > > people already used to packaging. > > > > This bug report is CC-ed to Mailman for Debian team, as I do intend to > > collaborate with them, I hope I'll make myself helpful. > > > > This bug report will come with the others for the others components of > > Mailman3 suite. I hope this is the good way of doing ITP > > Oops, typo spotted here, proposed Package name would be mailman3-client. > > Sorry for that. Github/my personal gitlab repo for this package : * https://gitlab.pimeys.fr/PEB/mailman3-client * https://github.com/P-EB/mailman3-client Builds and passes. Will RFS as soon as others parts build and pass. -- PEB
Bug#977768: ITP: pytest-regressions -- py.test fixtures to write regression tests
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue * Package name: pytest-regressions Version : 2.1.1 Upstream Author : Bruno Oliveira * URL : https://github.com/ESSS/pytest-regressions * License : MIT Programming Lang: Python Description : py.test fixtures to write regression tests This plugin makes it simple to test general data, images, files, and numeric tables by saving expected data in a data directory (using pytest-datadir) that can be used to verify that future runs produce the same data. It is a dependency of sphinx-tabs, and I'll maintain it in the Python Team.
Bug#977769: ITP: pytest-datadir -- py.test plugin for manipulating test data directories and files
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue * Package name: pytest-datadir Version : 1.3.1 Upstream Author : Gabriel Reis * URL : https://github.com/gabrielcnr/pytest-datadir * License : MIT Programming Lang: Python Description : py.test plugin for manipulating test data directories and files pytest-datadir will look up for a directory with the name of the current module or the global 'data' folder, and allow one to access the content of these files using injected variables datadir or shared_datadir. The files in the data dirs are copied to a temporary path before tests being run. Henceforth, a modification won't happen on the original files. This package is a dependency of pytest-regressions, which is needed as a dep of sphinx-tabs. I'll maintain it in the Python Team.
Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!
Le lundi 07 novembre 2016 à 21:42:21+0100, Jan Luca Naumann a écrit : > Dear Pierre-Elliott Bécue, > > what is the current status of your packaging intend. Since I did not > the WNPP-list very well I started another ITP (that I closed of course > now) and maybe we can work together and/or I can take over some of the > work. > > Best regards, Dear Jan, I'd be happy to work with you. Mostly, all parts of mailman are "pre-packaged" on my server. I met issues with HyperKitty regarding dependencies, currently, these are not fully solved, as the devs had to move from django-browserid (implementation of persona protocol, by Mozilla) to another dependency offering implementation of a still used protocol (Mozilla is dropping persona). The second "issue" is mailman itself. It's using python3.4, but default version of python3 in debian is 3.5 for something like 10 months. I'm waiting mailman version 3.1, as Barry Warsaw told me it'd use python3.5. If you wish I can give you the developper accesses on my github repositories which contain the current packages, except hyperkitty (because of what I mentioned before). Cheers, -- PEB signature.asc Description: PGP signature
Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!
Le vendredi 11 novembre 2016 à 14:39:18+0100, Jan Luca Naumann a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hey Pierre-Elliott, > > my idea is that we package the current development versions and upload > them to Debian experimental since the development time of 3.1 will > last some more time according to the Mailman developers... > > If you have no problem I could submit some changes to your repository > either as pull requests or as direct pushs? As said, there is two issues. First, HyperKitty deps are missing, second, mailman relies on python3.4. If you have some patches to offer let's go for it, what is your github login please? -- PEB
Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite
Le 17 novembre 2016 22:34:09 GMT+01:00, "Kẏra " a écrit : >On Tue, 22 Mar 2016 20:50:33 +0100 Pierre-Elliott >=?iso-8859-1?Q?B=E9cue?= < >be...@crans.org> wrote: >> Le mardi 22 mars 2016 à 15:44:18-0400, anarcat a écrit : >> > Any progress here? >> >> Hey, >> >> mailman3-core, mailman3-postorius and mailman3-client are packaged. >I'm >> working on optimizing the first one as it's the bigger one. >> >> I'm working on hyperkitty, which should be good soon. >> >> I'll have to work on contrib files (manpages, config files), but I >think I >> might be able to finish a first glance of the suite for testing by >the end >> of April. >> > >Thanks for doing this! It's been six months since April now. Was the >testing successful? Good Evening. Unfortunately Hyperkitty has dependencies not yet packaged in Debian. For now I'm stuck there. There is currently refactoring in HyperKitty so I'm not rushing the packaging. Cheers. -- PEB
Bug#799281: [Mailman-Developers] Let's try to package mailman3 in Debian!
Le vendredi 18 novembre 2016 à 16:39:46+0100, Jan Luca Naumann a écrit : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Control: subscribe -1 j.naum...@fu-berlin.de > > Hey, > > my point was to start packaging the Mailman 3.1 development version > already since this version switches to python3.5 and many bug fixes > are applied there (I currently administrate a 3.0.3 installation, > there are many things not working properly). For the new > django-allauth dependency I have created a new ITP bug (you should be > in CC of the bug). > > My GitHub account is JanLuca. Dear Jan Luca, I pushed my HyperKitty stalled work on GitHub and gave you collaborator accesses. I suggest we continue discussing these packaging via IRC or by mail, removing the bug tracking of the contacts. Cheers, -- PEB signature.asc Description: PGP signature
Bug#934415: O: cfingerd -- configurable finger daemon
Package: wnpp The current maintainer of cfingerd, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: cfingerd Binary: cfingerd Version: 1.4.3-3.2 Maintainer: Martin Schulze Build-Depends: debhelper (>= 7) Architecture: any Standards-Version: 3.8.4 Format: 1.0 Files: 5ae9a79274d72da84dc49c5404787a76 1606 cfingerd_1.4.3-3.2.dsc fe9365f811624248aa3df52c4a832fc7 99898 cfingerd_1.4.3.orig.tar.gz 71066910245f8ee7218ba72aa7f41fd6 21233 cfingerd_1.4.3-3.2.diff.gz Checksums-Sha256: 5dcbe8ad0ea01167b5b5ea14210deb984de7cf5aee281ee02448eae9d3d0464a 1606 cfingerd_1.4.3-3.2.dsc 61b5efdbbe881fe35c39ca243fc11cf52d219a4f61104f1052a900fc7acb0fb0 99898 cfingerd_1.4.3.orig.tar.gz 8d0841e25ea199354c75048915ad5b75fa2b129de97686a684b08b10fca36964 21233 cfingerd_1.4.3-3.2.diff.gz Package-List: cfingerd deb net extra arch=any Directory: pool/main/c/cfingerd Priority: source Section: net Package: cfingerd Source: cfingerd (1.4.3-3.2) Version: 1.4.3-3.2+b1 Installed-Size: 164 Maintainer: Martin Schulze Architecture: amd64 Provides: finger-server Depends: libc6 (>= 2.14), update-inetd, netbase (>= 2.00) Conflicts: finger-server Description-en: configurable finger daemon This is a free replacement for standard finger daemons such as GNU fingerd and MIT fingerd. Cfingerd can enable/disable finger services to individual users, rather than to all users on a given host. It is able to respond to a finger request to a specified user by running a shell script (e.g., finger doorbell@mysite.mydomain might cause a sound file to be sent) rather than just a plain text file. Description-md5: c59ae5f8fe9f252bf9fbf651bcf214b8 Homepage: http://www.infodrom.org/projects/cfingerd/ Tag: interface::daemon, network::server, network::service, protocol::finger, role::program, use::scanning, works-with::people Section: net Priority: optional Filename: pool/main/c/cfingerd/cfingerd_1.4.3-3.2+b1_amd64.deb Size: 74138 MD5sum: 7d1d15e038fd6252c0fa3016cca56c25 SHA256: 7792969edbfca332a78e173c00f5907c1453e50cc5d65d91786ab86fc80a3511 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934420: O: dhcping -- DHCP Daemon Ping Program
Package: wnpp The current maintainer of dhcping, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: dhcping Binary: dhcping Version: 1.2-4.2 Maintainer: Martin Schulze Build-Depends: autotools-dev Architecture: any Standards-Version: 3.6.2 Format: 1.0 Files: 6372f650ce66ce7a34ce9be7a762dd5c 1617 dhcping_1.2-4.2.dsc c4b22bbf3446c8567e371c40aa552d5d 75485 dhcping_1.2.orig.tar.gz c77992eb6d1526c0fea4cce2fb019f69 31006 dhcping_1.2-4.2.diff.gz Checksums-Sha256: 66f5f8efe5e00aba19bbfdd2cb236137f05b17e44d819dbaa866fb32f5f7adfd 1617 dhcping_1.2-4.2.dsc 32ef86959b0bdce4b33d4b2b216eee7148f7de7037ced81b2116210bc7d3646a 75485 dhcping_1.2.orig.tar.gz f1263b3b9309506e7d74115e7e68b7eaa7d144dd4f3dc3347abf6cd41873f711 31006 dhcping_1.2-4.2.diff.gz Package-List: dhcping deb admin optional arch=any Directory: pool/main/d/dhcping Priority: source Section: admin Package: dhcping Version: 1.2-4.2 Installed-Size: 42 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.14) Description-en: DHCP Daemon Ping Program This small tool provides an opportunity for a system administrator to perform a DHCP request to find out if a DHCP server is still running. Description-md5: c1656353f4bd68e86cd8d21688eaf5ac Tag: admin::monitoring, interface::commandline, network::scanner, protocol::dhcp, protocol::ip, role::program, scope::utility, use::scanning Section: admin Priority: optional Filename: pool/main/d/dhcping/dhcping_1.2-4.2_amd64.deb Size: 12960 MD5sum: fc8bcbad333a9646d39fb84c12ca1f3e SHA256: 2c84d3bc90947a3d92fefae5de7e435c009eef126530649a60235ec712a5d271 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934424: O: mailto -- WWW Forms to Mail Gateway
Package: wnpp The current maintainer of mailto, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: mailto Binary: mailto Version: 1.3.2-3 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.6.1 Format: 1.0 Files: 0a74d1d23c2683eee01a0e75c0463a7c 893 mailto_1.3.2-3.dsc 87f2ac30b5133bcfca1ffd69ce8ab5e7 15751 mailto_1.3.2.orig.tar.gz 06a551bcbae91d672feedcead1529071 14530 mailto_1.3.2-3.diff.gz Checksums-Sha256: 33d47fea5448f397e94f51fc87d99a890d674e1e8a12748ca36e43c19b41d2c8 893 mailto_1.3.2-3.dsc 74050d4dae4b3f32ba9f5069251394887b6f044f8c68ef49a0e350876d0d1c99 15751 mailto_1.3.2.orig.tar.gz c5852b53ed0bf4203b816f72736b6a2abd827a8a0da6b0be14afefbfdbdae72c 14530 mailto_1.3.2-3.diff.gz Directory: pool/main/m/mailto Priority: source Section: web Package: mailto Source: mailto (1.3.2-3) Version: 1.3.2-3+b2 Installed-Size: 43 Maintainer: Martin Schulze Architecture: amd64 Depends: apache | httpd, exim4 | mail-transport-agent, libc6 (>= 2.2.5) Description-en: WWW Forms to Mail Gateway This package provides a CGI program that converts data submitted via a web formular to simple mail which is sent to a given address. Description-md5: 06ad4a2a040e61ebb41f90be6ba01cd7 Tag: implemented-in::c, interface::web, protocol::http, protocol::smtp, role::program, scope::utility, web::cgi, works-with::mail Section: web Priority: optional Filename: pool/main/m/mailto/mailto_1.3.2-3+b2_amd64.deb Size: 16802 MD5sum: eafadb8897d5e6cf8c9933597d19f3a6 SHA256: ff7bbb70a111921737faa39229c2202cc845662eab666120c3a3ae4931e5bf44 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934417: O: cvs-mailcommit -- Send CVS commitments via mail
Package: wnpp The current maintainer of cvs-mailcommit, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: cvs-mailcommit Binary: cvs-mailcommit Version: 1.19-2.1 Maintainer: Martin Schulze Architecture: all Standards-Version: 3.6.1.0 Format: 3.0 (quilt) Files: 46c2bfafa9905e66871b30fab6718be2 1829 cvs-mailcommit_1.19-2.1.dsc 72f6e697a3b3cbd398c9840bce8675bb 11241 cvs-mailcommit_1.19.orig.tar.gz 04f9ffb4e072da793c2ad3d6c512c228 2748 cvs-mailcommit_1.19-2.1.debian.tar.xz Checksums-Sha256: d6cc9477d6f5f2750ed080d5ea6a44c4d316b6c597d5d81d3f3774c72428aefc 1829 cvs-mailcommit_1.19-2.1.dsc 4e882554262dc09ede8082dd1b6371b15c4b0ecb4a57f529bd81b4b30c62ed8b 11241 cvs-mailcommit_1.19.orig.tar.gz 11db56cc79a7714f2c56610f804615f6b6c5f82b00ca7a1d5a80db54a1225fe1 2748 cvs-mailcommit_1.19-2.1.debian.tar.xz Dgit: 9b29aab9a43d61e65e4e361f5057882654b86dcb debian archive/debian/1.19-2.1 https://git.dgit.debian.org/cvs-mailcommit Package-List: cvs-mailcommit deb utils optional arch=all Directory: pool/main/c/cvs-mailcommit Priority: source Section: vcs Package: cvs-mailcommit Version: 1.19-2.1 Installed-Size: 29 Maintainer: Martin Schulze Architecture: all Depends: postfix | mail-transport-agent, rcs Description-en: Send CVS commitments via mail The cvs-mailcommit program is hooked into the CVS system via the loginfo file and helps people keep track of CVS repositories by distributing changes in a repository via mail. This package is written in Perl. Description-md5: fa14c6bd9547d070cf2fdbc89ca2118a Tag: admin::logging, devel::rcs, implemented-in::perl, interface::commandline, role::program, scope::utility, works-with::mail Section: vcs Priority: optional Filename: pool/main/c/cvs-mailcommit/cvs-mailcommit_1.19-2.1_all.deb Size: 2 MD5sum: 37344d900e9b670104388f2ea1a6277d SHA256: f14879ab4fedecb5be79631e8deb7a71b1055cb0448143b672b2dfaf523a8100 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934419: O: dhcpdump -- Parse DHCP packets from tcpdump
Package: wnpp The current maintainer of dhcpdump, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: dhcpdump Binary: dhcpdump Version: 1.8-2.2 Maintainer: Joey Schulze Build-Depends: libpcap0.8-dev Architecture: any Standards-Version: 3.8.0.1 Format: 1.0 Files: ea5578a122434bd79247482d037d3699 1649 dhcpdump_1.8-2.2.dsc 099c786997c424f196414f9575f1fb90 10740 dhcpdump_1.8.orig.tar.gz 70fecd651c239729b4f11a11a0b5a055 4994 dhcpdump_1.8-2.2.diff.gz Checksums-Sha256: e5ef652c0b3ae441309814d7630578f6a86cba58ab3eaabb68bca697f106bba8 1649 dhcpdump_1.8-2.2.dsc 6d5eb9418162fb738bc56e4c1682ce7f7392dd96e568cc996e44c28de7f77190 10740 dhcpdump_1.8.orig.tar.gz d30b1ff63e746e2b223447700c0ab4392a11695593b2eebd8d95a66acfd9affa 4994 dhcpdump_1.8-2.2.diff.gz Package-List: dhcpdump deb admin optional arch=any Directory: pool/main/d/dhcpdump Priority: source Section: admin Package: dhcpdump Version: 1.8-2.2 Installed-Size: 50 Maintainer: Joey Schulze Architecture: amd64 Depends: libc6 (>= 2.3.4), libpcap0.8 (>= 0.9.8), tcpdump Description-en: Parse DHCP packets from tcpdump This package provides a tool for visualization of DHCP packets as recorded and output by tcpdump to analyze DHCP server responses. Description-md5: b4ad9f140ebb9a313823d1234c692b63 Tag: interface::commandline, network::scanner, protocol::dhcp, protocol::ip, role::program, scope::utility, use::viewing Section: admin Priority: optional Filename: pool/main/d/dhcpdump/dhcpdump_1.8-2.2_amd64.deb Size: 14744 MD5sum: 4a41a6badd6523993d4a062681865f6e SHA256: 071e64798c6a71d3b65a95db77f12c1472847e3de0dc325a2047596aa9cb8015 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934423: O: gui-apt-key -- Graphical Key Manager for APT
Package: wnpp The current maintainer of gui-apt-key, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: gui-apt-key Binary: gui-apt-key Version: 0.4-2.2 Maintainer: Martin Schulze Build-Depends: gettext Architecture: all Standards-Version: 3.7.2.0 Format: 1.0 Files: ed1e11649385c25e8dcd78e97cdf6fd2 1617 gui-apt-key_0.4-2.2.dsc aed27ea9de94096f4615ddd0a056ccde 31325 gui-apt-key_0.4.orig.tar.gz 9f1dac6ce676428d1d4b140a1313a323 13106 gui-apt-key_0.4-2.2.diff.gz Checksums-Sha256: 2ae228e519f43b5465ada55ffee6c6028b310e7f791819787cff606af8b3c6c7 1617 gui-apt-key_0.4-2.2.dsc ca028b44e8e4dd243625a1d3e13b22cefc9fb0541bcd09bf9bef43dcf13db787 31325 gui-apt-key_0.4.orig.tar.gz a046473a76ee4fd8f6e9f9de9aca8ed2a163fb41320b7a02848f7098b9bd875e 13106 gui-apt-key_0.4-2.2.diff.gz Package-List: gui-apt-key deb admin optional arch=all Directory: pool/main/g/gui-apt-key Priority: source Section: admin Package: gui-apt-key Version: 0.4-2.2 Installed-Size: 197 Maintainer: Martin Schulze Architecture: all Depends: libgtk2-perl, liblocale-gettext-perl Description-en: Graphical Key Manager for APT The graphical frontend to the apt-key utility (gak) provides an easy to use interface to maintain digital keys for APT. They are required to authenticate Debian archives and prevent malicious packages to creep in. Description-md5: 39b95e409a2b43b8220b548baed3b946 Homepage: http://www.infodrom.org/projects/gui-apt-key/ Tag: admin::package-management, interface::commandline, interface::graphical, interface::x11, role::program, scope::utility, security::authentication, suite::debian, suite::gnome, uitoolkit::gtk, use::checking, use::searching, x11::application Section: admin Priority: optional Filename: pool/main/g/gui-apt-key/gui-apt-key_0.4-2.2_all.deb Size: 27622 MD5sum: bae2d707ff139f8f78d916e87d498197 SHA256: 3e1dc12cb25b31af08fc9249d78efbf069361b19fff1e7e4f09bc9b6c761 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934422: O: gerstensaft -- Frontend for Simple Asynchronous File Transfer
Package: wnpp The current maintainer of gerstensaft, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: gerstensaft Binary: gerstensaft Version: 0.3-4.2 Maintainer: Martin Schulze Build-Depends: libgtk2.0-dev, gettext Architecture: any Standards-Version: 3.5.0 Format: 1.0 Files: 3f460784fafb207d0be88750a961003c 1735 gerstensaft_0.3-4.2.dsc 199a0118bf48498cb14ed2275a9e2b29 46948 gerstensaft_0.3.orig.tar.gz 0ab09e7594dd6623b3cbc3c40aacd792 9298 gerstensaft_0.3-4.2.diff.gz Checksums-Sha256: 254b6bbe84b86c42851fa15b8d2debb17db188d32717e02d65ab1babc2397a51 1735 gerstensaft_0.3-4.2.dsc b1949666326f71ba28c7a3540602e0d548877af9892835c5affb62060b5c5a12 46948 gerstensaft_0.3.orig.tar.gz 066047ceb97e13664fb995335f6c16cae85eecbabcb34e40c68e48554baf60e1 9298 gerstensaft_0.3-4.2.diff.gz Homepage: http://www.infodrom.org/projects/gerstensaft/ Package-List: gerstensaft deb net extra arch=any Directory: pool/main/g/gerstensaft Priority: source Section: net Package: gerstensaft Version: 0.3-4.2 Installed-Size: 170 Maintainer: Martin Schulze Architecture: amd64 Depends: libatk1.0-0 (>= 1.12.4), libc6 (>= 2.14), libcairo2 (>= 1.2.4), libfontconfig1 (>= 2.12), libfreetype6 (>= 2.2.1), libgdk-pixbuf2.0-0 (>= 2.22.0), libglib2.0-0 (>= 2.16.0), libgtk2.0-0 (>= 2.8.0), libpango-1.0-0 (>= 1.14.0), libpangocairo-1.0-0 (>= 1.14.0), libpangoft2-1.0-0 (>= 1.14.0), sendfile Description-en: Frontend for Simple Asynchronous File Transfer Gerstensaft is an easy to use graphical oriented frontend for sendfile(1). It features sending files and directories and provides a history for addresses. Description-md5: 3bc745a748e6c3d442dd711b77fd06b6 Homepage: http://www.infodrom.org/projects/gerstensaft/ Tag: interface::graphical, interface::x11, network::client, role::program, uitoolkit::gtk, use::downloading, x11::application Section: net Priority: optional Filename: pool/main/g/gerstensaft/gerstensaft_0.3-4.2_amd64.deb Size: 41156 MD5sum: 880da44e55f62847bef02f38b4b07197 SHA256: 04efea1bd2327d2341c4b39a4a1e28837b81563549e055246525d5b20d0b85b7 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934418: O: dbview -- View dBase III files
Package: wnpp The current maintainer of dbview, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: dbview Binary: dbview Version: 1.0.4-1 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.5.2 Format: 1.0 Files: dd1800fad94c06e3242a2eeb812408e3 518 dbview_1.0.4-1.dsc f77c9a85ca18dd1c80f72fcbc17c78ea 9857 dbview_1.0.4.orig.tar.gz aeb98b27fdea8ff582bd058b23ae6cf2 4195 dbview_1.0.4-1.diff.gz Checksums-Sha256: f4606d5cf5c1f6385f7a756ddbfa7913668a2eeeb82b1c20f2ebb4c8b688d386 518 dbview_1.0.4-1.dsc 8d4a3fb90bc1e7be4c64b3d9b7c735c718c34c2c29cddcc6da4d76fed0d495a6 4195 dbview_1.0.4-1.diff.gz bca41716e1ec0ce8833bcacfa17063f338b25f249f92ddb954c7d935e008cee7 9857 dbview_1.0.4.orig.tar.gz Directory: pool/main/d/dbview Priority: source Section: misc Package: dbview Source: dbview (1.0.4-1) Version: 1.0.4-1+b2 Installed-Size: 34 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.3) Description-en: View dBase III files Dbview is a little tool that will display dBase III and IV files. You can also use it to convert your old .dbf files for further use with Unix. . It wasn't the intention to write a freaking viewer and reinvent the wheel again. Instead dbview is intend to be used in conjunction with your favourite unix text utilities like cut, recode and more. Description-md5: d61e727fcd6480d1917168bcd1d03d18 Tag: interface::commandline, role::program, scope::utility, use::converting, use::viewing, works-with::db Section: misc Priority: optional Filename: pool/main/d/dbview/dbview_1.0.4-1+b2_amd64.deb Size: 11812 MD5sum: 24d9a2f6d684fd76de5a80a189f18822 SHA256: b13d007db3d76370954c59e11fa47d9be831a3a7bafdb3f891446990768491d1 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934416: O: cgilib -- Simple CGI Library
Package: wnpp The current maintainer of cgilib, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: cgilib Binary: cgilib Version: 0.6-1.1 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.7.3 Format: 1.0 Files: d955406c625e69a45e2a6e2b1a53e876 1574 cgilib_0.6-1.1.dsc 392f00a4ce90426606efcb6ce705fd75 25268 cgilib_0.6.orig.tar.gz b21373e74566c05f3751e00179a969c5 5187 cgilib_0.6-1.1.diff.gz Checksums-Sha256: ff7d1bd968dc2d2b4499da8d7aa7cf5835102e045a0d7eb3a20f4ec8f9ba3ab4 1574 cgilib_0.6-1.1.dsc b825a7ff413c02a758af1e54641d41f24099b9c54c4530b5e6edebe21d9640dd 25268 cgilib_0.6.orig.tar.gz 14936611c7fbab1e25d93bb6c7a9772518670ebc8d39b2324628620dee5a808b 5187 cgilib_0.6-1.1.diff.gz Package-List: cgilib deb web optional arch=any Directory: pool/main/c/cgilib Priority: source Section: web Package: cgilib Version: 0.6-1.1 Installed-Size: 91 Maintainer: Martin Schulze Architecture: amd64 Suggests: httpd Conflicts: libcgi-dev Description-en: Simple CGI Library This library provides a simple programming API to the Common Gateway Interface (CGI). It features HTTP Redirect, provides read access to FORM variables, sets HTTP Cookies and reads them. Description-md5: e6858716f1a5fe470806506faabdaf40 Tag: devel::lang:c, devel::library, implemented-in::c, protocol::http, role::app-data, role::devel-lib, role::program, web::cgi Section: web Priority: optional Filename: pool/main/c/cgilib/cgilib_0.6-1.1_amd64.deb Size: 35590 MD5sum: c501dc1081d27e713671316507213169 SHA256: c649b751e3738f1456aa3b0e348dc7d34b780c6625d8ee6f389d9400468f78cc -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934421: O: dtaus -- Paperless money transfer with German banks on floppies
Package: wnpp The current maintainer of dtaus, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: dtaus Binary: dtaus Version: 0.9-1.1 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.5.2 Format: 1.0 Files: 4d8e9f1314b24dfccaded528edc47fa0 1563 dtaus_0.9-1.1.dsc 0703e37f8ed303ceb2e78ece5650bf05 32294 dtaus_0.9.orig.tar.gz 9f4e721f65e9f820a9ce5c20a713a742 4826 dtaus_0.9-1.1.diff.gz Checksums-Sha256: 98fc17d6358cb06db49ae7bed06c114afc90f65a155f5e9527e427c6d0a6d683 1563 dtaus_0.9-1.1.dsc f056eb9abbf300db8828dc5472f54d6cbe496309d9185aba53efdcc8 32294 dtaus_0.9.orig.tar.gz b873262a947ce63444ca56f3517a1a1465e1d2e6461ee5fd503d789a10e6857c 4826 dtaus_0.9-1.1.diff.gz Package-List: dtaus deb misc extra arch=any Directory: pool/main/d/dtaus Priority: source Section: misc Package: dtaus Version: 0.9-1.1 Installed-Size: 66 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.14) Description-en: Paperless money transfer with German banks on floppies This package contains a library that can read and write German DTAUS files. DTAUS is an acronym for DatenTraegerAUStausch. It is used by German credit institutes in order to transfer commands for money exchanges between accounts. This format is used both between banks and between banks and their customers. One mainly wants to use it to be able to do automatic "Bankeinzuege". . This package probably will only be useful in Germany. Description-md5: d7b43a6feac22917426cb7b11eb7fe2a Tag: culture::german, field::finance, hardware::storage, interface::commandline, role::program, scope::application Section: misc Priority: optional Filename: pool/main/d/dtaus/dtaus_0.9-1.1_amd64.deb Size: 31734 MD5sum: ace3b0529b4599f238d7189ded1493df SHA256: 9d04c92472eb460276a00e95a791d97e15f9e8c00ab29b7a300b5d52a5e7a4e9 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934426: O: uucpsend -- Alternative Frontend for UUCP Batching with INN
Package: wnpp The current maintainer of uucpsend, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: uucpsend Binary: uucpsend Version: 1.1-4.1 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.5.2 Format: 1.0 Files: beda04e50c23c5eecf30c45ab4f720b9 1729 uucpsend_1.1-4.1.dsc e671a49633953fe8ec9d1dba2a627df9 16227 uucpsend_1.1.orig.tar.gz a2b1ea2e248163a1bb17b0d28f798e34 4355 uucpsend_1.1-4.1.diff.gz Checksums-Sha256: ecf1e9801644f1550a12c520e55e2d8dd02cd29f1fc8def7c824e8272b3b865e 1729 uucpsend_1.1-4.1.dsc 3447ff358e21c9927f4a35409218bf6f77c6caaceeed298bc15a8cb6dec065bc 16227 uucpsend_1.1.orig.tar.gz 42521420c9701a0a9a6f51df6c76e830288d97e22eadff6e521d091c9fdea5b0 4355 uucpsend_1.1-4.1.diff.gz Dgit: 7f6b9ebeb301563e43cb3b860849e95143f058d1 debian archive/debian/1.1-4.1 https://git.dgit.debian.org/uucpsend Package-List: uucpsend deb news extra arch=any Directory: pool/main/u/uucpsend Priority: source Section: news Package: uucpsend Version: 1.1-4.1 Installed-Size: 47 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.14), inn, uucp Conflicts: inn2 Description-en: Alternative Frontend for UUCP Batching with INN This package provides some neat features to do UUCP batching. Partially it is logically based on send-uucp and nntpsend which were included in early versions of INN. . It is tested with INN 1 and may require tweaking with INN 2. Description-md5: 152e50d2b51bcafe0cde226576cb6ba5 Tag: protocol::nntp, role::plugin, role::program, use::transmission, works-with::file Section: news Priority: optional Filename: pool/main/u/uucpsend/uucpsend_1.1-4.1_amd64.deb Size: 14666 MD5sum: e9f2c653ed785d225912e3a26290a653 SHA256: 9641b2ea948edf453bd193b2e2906ac9a268ce2363462161f43788a754c4e8c4 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934428: O: xxgdb -- An X front-end to the GNU debugger gdb
Package: wnpp The current maintainer of xxgdb, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: xxgdb Binary: xxgdb Version: 1.12-17 Maintainer: Joey Schulze Build-Depends: debhelper (>= 7.1), dpatch, libxaw7-dev, libx11-dev, libxt-dev, x11proto-core-dev, xutils-dev Architecture: any Standards-Version: 3.8.4 Format: 1.0 Files: e77ce7b93b0312781e72c1f5b65422f7 992 xxgdb_1.12-17.dsc 26f50e1b64d04cf80cba2132c910b693 115786 xxgdb_1.12.orig.tar.gz d1fb0137bb0c1d2c67203027ef785e3a 18219 xxgdb_1.12-17.diff.gz Checksums-Sha256: 4fe37f299793f68945928d2d73570c65aa28950230d571fafc4b184106502813 992 xxgdb_1.12-17.dsc 2a3413c1285af74042b4d66370d701f4c68eb207fc3d90463e544c9ed2fb8a4b 115786 xxgdb_1.12.orig.tar.gz 74cab6f9eb670ea2c3b87a2802ad1a1e563058498b73bb98414826da80d1e934 18219 xxgdb_1.12-17.diff.gz Directory: pool/main/x/xxgdb Priority: source Section: devel Package: xxgdb Source: xxgdb (1.12-17) Version: 1.12-17+b2 Installed-Size: 170 Maintainer: Joey Schulze Architecture: amd64 Depends: gdb, libc6 (>= 2.14), libx11-6, libxaw7, libxt6 Description-en: An X front-end to the GNU debugger gdb xxgdb is a simple but powerful graphical interface to the GNU debugger gdb. A more powerful (but slower and much bigger) interface is available in the ddd package. Description-md5: 3bfda36542e8c682af6e97d0745b2385 Tag: devel::debugger, interface::graphical, interface::x11, role::program, scope::utility, uitoolkit::athena, use::checking, x11::application Section: devel Priority: optional Filename: pool/main/x/xxgdb/xxgdb_1.12-17+b2_amd64.deb Size: 62758 MD5sum: 0745f8c24060d761152945d59d404175 SHA256: 843f0f5dfeb0d1616447c4f91dee7131a67f8e37180156ec12e9f08e4fc563c8 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934433: O: rbootd -- Remote Boot Daemon
Package: wnpp The current maintainer of rbootd, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: rbootd Binary: rbootd Version: 2.0-10 Maintainer: Martin Schulze Build-Depends: libpcap-dev Architecture: any Standards-Version: 3.7.3 Format: 1.0 Files: 429a05a8dd8d1fbb67e3f7ecba2fda47 542 rbootd_2.0-10.dsc bce823c223048e43dc42e4c88b6a31b6 27235 rbootd_2.0.orig.tar.gz cfa43238ce43259a1d03d1cf99180a31 9541 rbootd_2.0-10.diff.gz Checksums-Sha256: dbcd996647c72bc03b3d55b84ca5bac9836ad35f29522d3a23c04f2b8dac7757 542 rbootd_2.0-10.dsc 9df329b0e821b91d2513f251d6969b0cff3b75a3c4c0002a4530f966fdaaa8ba 9541 rbootd_2.0-10.diff.gz 2f5338d1e619e4ba3bcc2d93f942f785a6f75c71a3b35c04d8fbcb84fd868a18 27235 rbootd_2.0.orig.tar.gz Directory: pool/main/r/rbootd Priority: source Section: net Package: rbootd Source: rbootd (2.0-10) Version: 2.0-10+b2 Installed-Size: 55 Maintainer: Martin Schulze Architecture: amd64 Depends: netbase (>= 3.00), libc6 (>= 2.14), libpcap0.8 (>= 0.9.8) Suggests: bootparamd, nfs-server Description-en: Remote Boot Daemon The rbootd daemon is used for booting some HP workstations over the network (such as the 9000/300 and 9000/400 series). It can also boot PA RISC workstations. It handles the first stage of the boot sequence and can be used to start booting Linux, NetBSD or HPUX. Description-md5: 0db2270ca1150fda750ff80d3e1fcf83 Tag: admin::boot, interface::daemon, network::server, network::service, role::program Section: net Priority: optional Filename: pool/main/r/rbootd/rbootd_2.0-10+b2_amd64.deb Size: 19274 MD5sum: 93f1cf42f598974c47d6ed8ddb299854 SHA256: 9a0017e320f9595b014d0c833fa5687f7b0b20ac28590501e1b42e188471f77a -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934437: O: newmail -- Notificator for incoming mail
Package: wnpp The current maintainer of newmail, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: newmail Binary: newmail Version: 0.5-2 Maintainer: Martin Schulze Architecture: any Standards-Version: 3.7.3 Format: 1.0 Files: 79e8edd38ad88ce0e91cc00d0cdf043c 883 newmail_0.5-2.dsc 062ec245f595a8dc803a968892bff0ff 17110 newmail_0.5.orig.tar.gz 8dfb091d8a92fbcbc97f41ca867b6b5c 4003 newmail_0.5-2.diff.gz Checksums-Sha256: c027702c43b77dfc6d07610e6c36647defac08a7aa2b0130d6bc2ba6b9c90123 883 newmail_0.5-2.dsc 6d99310137c75bd73df12c8d7e9420d619d1d4751d9d7edc48f275a4bf79bad0 17110 newmail_0.5.orig.tar.gz c6e3f5022ba8053cfbf7e8b3aba249f3f1977f14cc84605e9bc7b560ce172173 4003 newmail_0.5-2.diff.gz Directory: pool/main/n/newmail Priority: source Section: mail Package: newmail Source: newmail (0.5-2) Version: 0.5-2+b2 Installed-Size: 38 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.14) Description-en: Notificator for incoming mail The newmail program usually puts itself in the background and watches mailbox files in order to report when new mail has been arrived. The originator and subject will then be reported on the terminal it was started. The output can also be integrated in graphical programs. . This package is inspired by the newmail program from the Elm mail system. Description-md5: 49b0168ce625e668ce3031036ad2f541 Homepage: http://www.infodrom.org/projects/newmail/ Tag: interface::commandline, mail::notification, role::program, scope::utility, works-with::mail Section: mail Priority: optional Filename: pool/main/n/newmail/newmail_0.5-2+b2_amd64.deb Size: 13068 MD5sum: b3db1531b33158221b513bfe SHA256: 6e0b2ece40639f3a907df6454423f640ff49f60f2796a1f894c6bdde519da3a8 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#934436: O: sendfile -- Simple Asynchronous File Transfer
Package: wnpp The current maintainer of sendfile, Martin Schulze , is apparently not active anymore. Therefore, I orphan this package now. Maintaining a package requires time and skills. Please only adopt this package if you will have enough time and attention to work on it. If you want to be the new maintainer, please see https://www.debian.org/devel/wnpp/#howto-o for detailed instructions how to adopt a package properly. Some information about this package: Package: sendfile Binary: sendfile Version: 2.1b.20080616-5.3 Maintainer: Martin Schulze Build-Depends: libreadline-dev, autotools-dev Architecture: any Standards-Version: 3.5.2.0 Format: 1.0 Files: 0e6039fefd3054d672e222612c0e5b7e 1700 sendfile_2.1b.20080616-5.3.dsc 671cd95971c53066a9d0fa66ac04e813 343153 sendfile_2.1b.20080616.orig.tar.gz e15da70433f9a4dfecfdf2ea75fea09c 25366 sendfile_2.1b.20080616-5.3.diff.gz Checksums-Sha256: e0dcd524988bf2df2cbad7fa2f473fe2101822301bfc20e8d03f0105ef852a66 1700 sendfile_2.1b.20080616-5.3.dsc d13b643d50ec0b03f636b0f89bf95f4c9ea561ccf2091d8417af90f59bcd93fc 343153 sendfile_2.1b.20080616.orig.tar.gz 455b6167c265127d840dfe8db704203741de723137223ea0404be7c6344f0298 25366 sendfile_2.1b.20080616-5.3.diff.gz Package-List: sendfile deb net optional arch=any Directory: pool/main/s/sendfile Priority: source Section: net Package: sendfile Source: sendfile (2.1b.20080616-5.3) Version: 2.1b.20080616-5.3+b3 Installed-Size: 552 Maintainer: Martin Schulze Architecture: amd64 Depends: libc6 (>= 2.14), libreadline7 (>= 6.0), openbsd-inetd | inet-superserver, perl | perl5, update-inetd, libdpkg-perl Suggests: pgp-i Description-en: Simple Asynchronous File Transfer Sendfile is an asynchronous file transfer service for the Internet, like the sendfile facility in Bitnet: Any user A can send files to another user B without B being active in any way. . The existing standard file transfer (ftp) is a synchronous service: The user must have access to an account on the sending and on the receiving site, too. . Sendfile for Unix, which is an implementation of the SAFT protocol (Simple Asynchronous File Transfer) now offers you a true asynchronous file transfer service for the Internet. Virtually any form of file can be sent, including encrypted ones. The SAFT protocol will be submitted as an RFC in the near future. Description-md5: 544c219ea9ea2e5464e79b350c4ef1a4 Homepage: http://fex.rus.uni-stuttgart.de/saft/ Tag: interface::commandline, network::client, role::program, uitoolkit::ncurses, use::transmission, works-with::file Section: net Priority: optional Filename: pool/main/s/sendfile/sendfile_2.1b.20080616-5.3+b3_amd64.deb Size: 189186 MD5sum: e9c1505e3ef78bc592ec4254936834bc SHA256: 8e601baca13db8718f5ed4d9ed5552d4b4b6ae947d98ae4a0ffcee45ecb9f902 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#756017: Partial packaging
Le mardi 08 septembre 2015 à 22:25:11-0700, Diane Trout a écrit : > I have a packaging tree that I'm using at: > https://github.com/detrout/python-bokeh > > It can't be released to Debian until we find a solution for building BokehJS. > (And that it also needs a jquery 2.1.1). > > But at least its a start. Dear Diane, It seems that bokeh 1.3.4 ships a version of BokehJS that is non-minified and ready-to-use. Wouldn't that be a correct solution for an initial packaging, even though one could wish to finish the proper javascript package in a second time? With best regards, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#892907: ITP: python-pytest-vcr -- pytest plugin for managing python-vcr cassettes
Le mercredi 14 mars 2018 à 22:28:14+1100, Craig Small a écrit : > Package: wnpp > Severity: wishlist > Owner: Craig Small > > * Package name: python-pytest-vcr > Version : 0.3.0 > Upstream Author : Tomasz Kontusz > * URL : https://pypi.python.org/pypi/pytest-vcr > * License : MIT > Programming Lang: Python > Description : pytest plugin for managing python-vcr cassettes > > Allows pytest-runner tests to use a simple decoration for their > python-vcr tests. Requires python-pytest and python-vcr which > are both already packaged. > > This is required for testing the Mastodon python module which > I am also going to ITP. > > While I can maintain it, I excpect this will form under the DPMT > and use their salsa project. Hi Craig, I created a salsa repo and packaged the thing. Do you wish me to add you to uploaders? With best regards, -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#793354: ITP: pytest-services -- collection of fixtures and utility functions for py.test
Control: owner -1
Control: retitle -1 ITP: pytest-services -- collection of fixtures and utility
functions for py.test
Le jeudi 23 juillet 2015 à 08:40:11+0200, Daniel Stender a écrit :
> Package: wnpp
> Severity: wishlist
> Owner: Daniel Stender
>
> * Package name: pytest-services
> Version : 1.1.3
> Upstream Author : Anatoly Bubenkov
> * URL : https://github.com/pytest-dev/pytest-services
> * License : Expat
> Programming Lang: Python
> Description : collection of fixtures and utility functions for py.test
>
> Another item from the pytest-dev team to enrich the py.test plugin collection
> in
> Debian. This a collection of basic infrastructure and service fixtures and
> utilites functions for writing test suites for py.test, please see the Github
> page for details. The resulting binaries are going to be
> python{,3}-pytest-services.
Cheers.
--
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
signature.asc
Description: PGP signature
Bug#905065: ITP: golang-github-canonicalltd-raft-membership -- Extension of the Hashicorp raft package to easily join and leave a cluster
Le mardi 31 juillet 2018 à 11:24:36+0800, Clement Hermann a écrit : > Package: wnpp > Severity: wishlist > Owner: Clement Hermann > > * Package name: golang-github-canonicalltd-raft-membership > Version : 0.0~git20180413.3846634-1 > Upstream Author : Canonical Ltd > * URL : https://github.com/CanonicalLtd/raft-membership > * License : Apache-2.0 > Programming Lang: Go > Description : Extension of the Hashicorp raft package to easily join > and leave a cluster > > github-canonicalltd-raft-membership provides the raftmembership package, > which contains an > extension of the raft Go package (https://github.com/hashicorp/raft) from > Hashicorp to easily make a node join or leave a cluster. > > This is a dependency of LXD 3 (ITP: #768973) and will be maintained under the > Go team umbrella. Hi, raft-test being in Debian[1], and the salsa repository for raft-membership looking close to ready[2], do you require anything else to upload this package? Cheers! [1] https://tracker.debian.org/pkg/golang-github-canonicalltd-raft-test [2] https://salsa.debian.org/go-team/packages/golang-github-canonicalltd-raft-membership -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them.
Bug#917651: ITP: python-markdown2 -- A fast and complete Python implementation of Markdown
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: python-markdown2 Version : 2.3.7 Upstream Author : Nicholas Serra , Trent Mick * URL : https://github.com/trentm/python-markdown2 * License : MIT Programming Lang: Python Description : A fast and complete Python implementation of Markdown Markdown is a text-to-HTML filter; it translates an easy-to-read / easy-to-write structured text format into HTML. Markdown’s text format is most similar to that of plain text email, and supports features such as headers, emphasis, code blocks, blockquotes, and links. This is a fast and complete Python3 implementation of the Markdown spec. This package is a dependency of fava[1], and will be maintained in DPMT. Cheers, -- PEB [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917532
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Le vendredi 28 décembre 2018 à 11:34:57+0100, Stefano Zacchiroli a écrit : > Looks like a fava dependency is missing in Debian: [python3-]markdown2, > https://pypi.org/project/markdown2/ (There's python3-markdown in the > archive, but that's a different one: https://pypi.org/project/Markdown/) > > Volunteers to package markdown2 are welcome; I'm not going to package it > myself. > > Cheers. It's in new now. :) -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Le samedi 29 décembre 2018 à 21:26:50+0100, Stefano Zacchiroli a écrit : > On Sat, Dec 29, 2018 at 09:11:23PM +0100, Pierre-Elliott Bécue wrote: > > It's in new now. :) > > Thanks! :-) You're very welcome. Let's go back to fava. As any flask app, it could be served as a true website, but I'm not sure it's the actual goal of the software (there seem to be no auth and no security). I think a webserver config + WSGI handling is quite overkill. Do you agree? -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#917532: RFP: fava -- web interface for the Beancount accounting tool
Le dimanche 30 décembre 2018 à 01:24:23+0100, Pierre-Elliott Bécue a écrit : > Le samedi 29 décembre 2018 à 21:26:50+0100, Stefano Zacchiroli a écrit : > > On Sat, Dec 29, 2018 at 09:11:23PM +0100, Pierre-Elliott Bécue wrote: > > > It's in new now. :) > > > > Thanks! :-) > > You're very welcome. > > Let's go back to fava. > > As any flask app, it could be served as a true website, but I'm not sure > it's the actual goal of the software (there seem to be no auth and no > security). > > I think a webserver config + WSGI handling is quite overkill. Do you agree? I uploaded a batch of fixes on the skeleton you had set up on salsa. Cheers! -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#961348: ITP: sphinx-tabs -- Tabbed views for Sphinx
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue * Package name: sphinx-tabs Version : 1.1.13 Upstream Author : Alex Collins * URL : https://github.com/djungelorm/sphinx-tabs * License : MIT Programming Lang: Python Description : Tabbed views for Sphinx Sphinx Tabs is a Sphinx extension that allows one to create tabbed content in a Sphinx documentation built in HTML. The current features are: - Simple tabs - Groupped tabs (synchronize the tabs between multiple areas of the page) - Code tabs This package is a documentation requirement for python-coverage 5, and provides features not built in the current sphinx releases. It would be maintained in DPMT.
Bug#961349: ITP: sphinx-rst-builder -- A Sphinx builder for rST (reStructuredText) files
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue * Package name: sphinx-rst-builder Version : 0.0.3 Upstream Author : David Fritzsche * URL : https://github.com/davidfritzsche/sphinx-rst-builder * License : BSD-2-Clause Programming Lang: Python Description : A Sphinx builder for reST (reStructuredText) files Sphinx extension to build reST (reStructuredText) files. This extension is in particular useful to use in combination with the autodoc extension to automatically generate documentation for use by any rst parser (such as the GitHub wiki). In itself, the extension is fairly straightforward – it takes the parsed reST file from Sphinx and outputs it as reST. This library is needed to build python-coverage 5.1's doc and would be maintained under the DPMT
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le jeudi 17 septembre 2015 à 16:19:09+0200, Pierre-Elliott Bécue a écrit : > Package: wnpp > Severity: wishlist > Owner: "Pierre-Elliott Bécue" > > * Package name: mailman3-core > Version : 3.0.0 > Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian > Fuchs, Terri Oda, Stephen J. Turnbull, Abhilash Raj > * URL : http://list.org/ > * License : GPLv3 > Programming Lang: Python3 > Description : Mailing list management system > > GNU Mailman3 is a package providing mailing list management system. > This would be the bare core of Mailman3, without client package, > HyperKitty or Postorius, that would be packaged in different sources > packages. > > There is currenctly mailman2 in Debian archive, and I was considering > involve myself in packaging mailman3, Mailman developers seems to think > that it is a pretty good idea, but they suggested me to wait 'till 3.1.0 > is out. > > I'm currently looking for a sponsor as I'm not a Debian Developer, nor > used to build brand new packages. Since 3.1 is not released yet, I've > some time to learn but I'll be happy to work with people already used to > packaging. > > This bug report is CC-ed to Debian mailman team, as I do intend to > collaborate with them, I hope I'll be helpful. > > This bug report will come with the others for the others components of > Mailman3 suite. I hope this is the good way of doing ITP Somme followup. mailman3 core server v3.1 has been released in may. I've been packaging it and it's fully compatible with python3.5 (and supposedly also with python3.6). I asked barry (CC-ed) to review and sponsor. Though he'll require some time to do it. In the meantime, I also asked to join pkg-mailman team, so that I can put the git repo of the package on a debian's server. Anyone interested in can have a look at the package repo on https://github.com/P-EB/mailman3-core.git The current .deb can be found here: https://peb.pimeys.fr/packages/mailman/mailman3-core/ alongside with the build logs. I hope to have mailman 3.1 in debian soon. Cheers. -- PEB signature.asc Description: PGP signature
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le 17 août 2017 08:01:57 GMT+02:00, "shirish शिरीष" a écrit : >at bottom :- > >On 12/08/2017, Pierre-Elliott Bécue wrote: > > > >> Somme followup. >> >> mailman3 core server v3.1 has been released in may. I've been >packaging it >> and it's fully compatible with python3.5 (and supposedly also with >> python3.6). >> >> I asked barry (CC-ed) to review and sponsor. Though he'll require >some time >> to do it. >> >> In the meantime, I also asked to join pkg-mailman team, so that I can >put >> the git repo of the package on a debian's server. >> >> Anyone interested in can have a look at the package repo on >> https://github.com/P-EB/mailman3-core.git >> >> The current .deb can be found here: >> https://peb.pimeys.fr/packages/mailman/mailman3-core/ alongside with >the >> build logs. >> >> I hope to have mailman 3.1 in debian soon. >> >> Cheers. >> >> -- >> PEB >> > >I think you forgot to CC barry in your update. His mail id is nowhere >to be seen. > >Anyways, would be nice to see mailman 3.1 in Debian soonish. > >Looking forward to seeing it. I bounced to him after sending the email and realizing that I forgot to Cc him. :) Cheers, -- PEB
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le 7 septembre 2017 12:27:27 GMT+02:00, Jonas Meurer a écrit : >Hi Pierre-Ellioth, > >On Thu, 17 Aug 2017 10:15:46 +0200 Pierre-Elliott Bécue wrote: >> >I think you forgot to CC barry in your update. His mail id is >nowhere >> >to be seen. >> > >> >Anyways, would be nice to see mailman 3.1 in Debian soonish. >> > >> >Looking forward to seeing it. >> >> I bounced to him after sending the email and realizing that I forgot >to Cc him. :) > >Are there any news regarding mailman 3.1 Debian packages? I see that >you >have preliminary packages for most parts of mailman3 at [1], but none >of >them was uploaded to Debian yet, right? > >Did you hear anything from Barry recently regarding uploading the >packages? > >I also gave the 'mailman3-core' package a quick try and realized that >it >still has some rough edges. First issues I spotted were: > >* According to 'mailman info', mailman3-core uses '/root/var/' as >prefix > for its paths. That seems to be wrong. In particular config and DB > paths are wrong: > > # mailman info > [...] > config file: /root/var/etc/mailman.cfg > db url: sqlite:root/var/data/mailman.db > >* Also, the expected var dir at '/var/lib/mailman3' and the log file at > '/var/log/mailman3.log' don't exist after package installation. > > >If you give me a quick heads-up, I might find time to take a deeper >look >into your packages and help a bit. > >Cheers, > jonas Dear Jonas, I have some news. Mattia (mapreri on IRC) gave me a first review of my package with plenty small fixes to apply. I didn't have time until now because of some deadlines in my PhD work. I'll jump back in at the end of the week. Barry was in the middle of a rush AFAIR, and for now I got little news. Cheers, -- PEB
Bug#875427: ITP: mailman3-django -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty
Package: wnpp Severity: wishlist Owner: =?utf-8?q?Pierre-Elliott_B=C3=A9cue?= * Package name: mailman3-django Version : 1.1.0 Upstream Author : Aurélien Bompard * URL : http://list.org/ * License : GPLv3 Programming Lang: Python Description : A common django base of tools for Mailman3's frontends Postorius and HyperKitty This package contains libraries and templates for Django-based interfaces interacting with Mailman. In particular, it provides a common base for Postorius and HyperKitty to work. -- This package is a necessary dependency to close bugs #799287 and #799285. I'm working on these packages with Mattia Rizzolo (mattia), Barry Warsaw (barry), and quite recently, Jonas Meurer (mejo) offered his help. -- PEB
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le mercredi 20 septembre 2017 à 18:53:50+0200, Jonas Meurer a écrit : > Hey PEB, hey Barry, > > > Am 07.09.2017 um 12:55 schrieb Jonas Meurer: > > Am 07.09.2017 um 12:37 schrieb Pierre-Elliott Bécue: > >> I have some news. > >> > >> Mattia (mapreri on IRC) gave me a first review of my package>> with plenty > >> small fixes to apply. I didn't have time until > >> now because of some deadlines in my PhD work. > > Hope that your PhD work is going well. > > >> I'll jump back in at the end of the week. > >> > >> Barry was in the middle of a rush AFAIR, and for now I got little news. > > > > that's great to hear. I'll wait for your fixes and give the packages > > another try afterwards. Just drop me a note and I'll do further review. > > I found some time to work on mailman3-core and mailmanclient packages > during the last days. You find the latest packaging status in the repos at > > https://github.com/P-EB/mailman3-core > https://anonscm.debian.org/cgit/python-modules/packages/mailmanclient.git/ > > In my eyes the mailman3-core and mailmanclient packages are in shape for > getting uploaded by now (hyperkitty & postorius still need some love). > > @barry: I could do the uploads but as you're PEB's sponsor so far you > might want to do that yourself. Maybe you also want to review the latest > changes to the packages? That would be awesome. > > In any case, let me know what procedure you prefer. I'll wait for PEB's > and your feedback before any further steps. Hey, I dived in your changes. For d/README.source, I changed the build method to put sbuild, as I never worked out a proper solution to build with gbp, and as sbuild fits properly for my needs. You can edit the file again if you wish, but in that case I'd need some hints on what is going wrong on my server. ^^ Your changes induced some lintian warnings, I can take the time to fix them, but maybe you'd be more efficient to do so. C/P of the lintian warnings: W: mailman3-core-doc: privacy-breach-generic usr/share/doc/mailman3-core-doc/html/README.html (https://gitlab.com/mailman/mailman/badges/master/build.svg) N: N:This package creates a potential privacy breach by fetching data from an N:external website at runtime. Please remove these scripts or external N:HTML resources. N: N:Please replace any scripts, images, or other remote resources with N:non-remote resources. It is preferable to replace them with text and N:links but local copies of the remote resources are also acceptable as N:long as they don't also make calls to remote services. Please ensure N:that the remote resources are suitable for Debian main before making N:local copies of them. N: N:Severity: important, Certainty: wild-guess N: N:Check: files, Type: binary, udeb N: W: mailman3-core-doc: privacy-breach-generic usr/share/doc/mailman3-core-doc/html/README.html (https://readthedocs.org/projects/mailman/badge) W: mailman3-core-doc: privacy-breach-generic usr/share/doc/mailman3-core-doc/html/README.html (http://img.shields.io/pypi/v/mailman.svg) W: mailman3-core-doc: privacy-breach-generic usr/share/doc/mailman3-core-doc/html/README.html (http://img.shields.io/pypi/dm/mailman.svg) In the documentation package, your changes reintroduced the many layers of directories before the documentation files, e.g. ./usr/share/doc/mailman3-core-doc/html/src/mailman/commands/docs/withlist.html I had found a way to remove the src/mailman that is useless. Is there a way to keep the .rst files as you did and mangle a bit the paths? Otherwise, I still have to implement some suggestions of Mattia. In particular the ones regarding the owner/group of the installed files, he suggests we use a postinst script to set the owner appropriately. -- PEB signature.asc Description: PGP signature
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le jeudi 21 septembre 2017 à 20:08:30-0400, Barry Warsaw a écrit : > Hi guys, apologies for not responding earlier. I have taken a break from > Debian development, so I am not reading my @debian.org email much these days: > > https://lists.debian.org/debian-python/2017/08/msg00107.html > > That said... > > > On Sep 20, 2017, at 12:53, Jonas Meurer wrote: > > > @barry: I could do the uploads but as you're PEB's sponsor so far you > > might want to do that yourself. Maybe you also want to review the latest > > changes to the packages? That would be awesome. > > Jonas, Mattia, thank you very much for working with PEB, and thanks to PEB > for being so diligent about getting Mailman 3 into Debian! I wholeheartedly > support your sponsorship of these packages while I am on hiatus. > > I did a quick review of the core package, and noticed just a few things: > > d/copyright should really go back to 1998. Even though Mailman 3 was forked > from Mailman 2 only in the last few years, there’s enough code inherited from > the early days to warrant the earlier copyright start year. Done! > In d/tests/mailman3-core-tests, what do you think about using `python3 -m > nose2` instead of `nose2-3`? As I wasn't able to have working tests for this package, they're disabled in d/rules. Maybe I just should remove this file. > Another interesting integration test might be to start up MM3’s REST API and > GET the /3.1/system/versions resource, then either print the JSON or compare > its value to something expected. It’s at least a minimal sniff test that > some runners could be started up. I think this requires more background on mailman3 functionnalities that I currently have. Maybe I'll set this suggestion in debian/TODO for later! > If and when you get a real manpage, please write it in reST, convertible via > rst2man and contribute it back upstream! Sure! > autopkgtest fails for me with: > > After this operation, 159 MB of additional disk space will be used. > Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon amd64 > 1.0.0-2+b1 > 404 Not Found > E: Failed to fetch > http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb > 404 Not Found > E: Unable to fetch some archives, maybe run apt-get update or try with > --fix-missing? > autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to > download packages I guess I'm not able to do such test myself. Thanks for your time! Cheers, -- PEB signature.asc Description: PGP signature
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le vendredi 22 septembre 2017 à 11:30:22+0200, Pierre-Elliott Bécue a écrit : > Le jeudi 21 septembre 2017 à 20:08:30-0400, Barry Warsaw a écrit : > > Hi guys, apologies for not responding earlier. I have taken a break from > > Debian development, so I am not reading my @debian.org email much these > > days: > > > > https://lists.debian.org/debian-python/2017/08/msg00107.html > > > > That said... > > > > > On Sep 20, 2017, at 12:53, Jonas Meurer wrote: > > > > > @barry: I could do the uploads but as you're PEB's sponsor so far you > > > might want to do that yourself. Maybe you also want to review the latest > > > changes to the packages? That would be awesome. > > > > Jonas, Mattia, thank you very much for working with PEB, and thanks to PEB > > for being so diligent about getting Mailman 3 into Debian! I > > wholeheartedly support your sponsorship of these packages while I am on > > hiatus. > > > > I did a quick review of the core package, and noticed just a few things: > > > > d/copyright should really go back to 1998. Even though Mailman 3 was > > forked from Mailman 2 only in the last few years, there’s enough code > > inherited from the early days to warrant the earlier copyright start year. > > Done! > > > In d/tests/mailman3-core-tests, what do you think about using `python3 -m > > nose2` instead of `nose2-3`? > > As I wasn't able to have working tests for this package, they're disabled in > d/rules. Maybe I just should remove this file. > > > Another interesting integration test might be to start up MM3’s REST API > > and GET the /3.1/system/versions resource, then either print the JSON or > > compare its value to something expected. It’s at least a minimal sniff > > test that some runners could be started up. > > I think this requires more background on mailman3 functionnalities that I > currently have. Maybe I'll set this suggestion in debian/TODO for later! > > > If and when you get a real manpage, please write it in reST, convertible > > via rst2man and contribute it back upstream! > > Sure! > > > autopkgtest fails for me with: > > > > After this operation, 159 MB of additional disk space will be used. > > Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon > > amd64 1.0.0-2+b1 > > 404 Not Found > > E: Failed to fetch > > http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb > > 404 Not Found > > E: Unable to fetch some archives, maybe run apt-get update or try with > > --fix-missing? > > autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to > > download packages > > I guess I'm not able to do such test myself. > > Thanks for your time! > > Cheers, Hi, From now on, the mailman3-core git repository is on alioth, under pkg-mailman repository. As soon as the server is up to date, one will be able to find the repository on https://anonscm.debian.org/git/pkg-mailman/mailman3-core.git The github one stays for now, but one day or another I'll drop it. -- PEB signature.asc Description: PGP signature
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le vendredi 22 septembre 2017 à 13:51:26-0400, Barry Warsaw a écrit : > On Sep 22, 2017, at 09:28, Pierre-Elliott Bécue wrote: > >> > >>> In d/tests/mailman3-core-tests, what do you think about using `python3 -m > >>> nose2` instead of `nose2-3`? > >> > >> As I wasn't able to have working tests for this package, they're disabled > >> in > >> d/rules. Maybe I just should remove this file. > > Can you remember why the test suite doesn’t work in d/rules? > > I do think that if they can’t be run in d/rules, they should be run at some > point, and autopkgtests are a good alternative. While that doesn’t block > promotion in Debian (yet?) it does in Ubuntu, so there should be good > feedback when the autopkgtests fail. As far as I remember, at that time, it was trying to run a server but didn't find the binary as it was not at the appropriate path. Now, when I run the tests, there are a lot of errors, but I can't say exactly why. If you wish I can put a copy of the last attempt. > That said, in my own packages I always try to include a few other > autopkgtests. Things like: > > * Run the command line (e.g. ``mailman —help``) > * Try to create a simple list > * Do a simple ``mailman shell`` command > * Hit the REST API and just make sure it returns some non-error. > > >> Another interesting integration test might be to start up MM3’s REST API > >> and GET the /3.1/system/versions resource, then either print the JSON or > >> compare its value to something expected. It’s at least a minimal sniff > >> test that some runners could be started up. > >> > >> I think this requires more background on mailman3 functionnalities that I > >> currently have. Maybe I'll set this suggestion in debian/TODO for later! > > +1! Tests are an investment over time, so just get the bare minimum working > now, and it can always be improved. Yeah, especially as having the package into unstable will allow for some feedback! > >> autopkgtest fails for me with: > >>> > >>> After this operation, 159 MB of additional disk space will be used. > >>> Err:1 http://httpredir.debian.org/debian sid/main amd64 python3-falcon > >>> amd64 1.0.0-2+b1 > >>> 404 Not Found > >>> E: Failed to fetch > >>> http://httpredir.debian.org/debian/pool/main/p/python-falcon/python3-falcon_1.0.0-2+b1_amd64.deb > >>> 404 Not Found > >>> E: Unable to fetch some archives, maybe run apt-get update or try with > >>> --fix-missing? > >>> autopkgtest [20:07:28]: ERROR: testbed failure: apt repeatedly failed to > >>> download packages > >> > >> I guess I'm not able to do such test myself. > > You should be able to build the source package, and then if you have a > chroot, just do: > > $ autopkgtest mailman-core-blah-blah.dsc — schroot sid-amd64 Hm, I'll have a shot at some point! Cheers, -- PEB signature.asc Description: PGP signature
Bug#799281: ITP: mailman3-core -- Mailing list management system
Le vendredi 22 septembre 2017 à 18:57:00-0400, Barry Warsaw a écrit : > On Sep 22, 2017, at 18:53, Pierre-Elliott Bécue wrote: > > > Now, when I run the tests, there are a lot of errors, but I can't say > > exactly why. If you wish I can put a copy of the last attempt. > > Sure, post a link. I’ll let you know if I see anything obvious. https://peb.pimeys.fr/packages/mailman/mailman3-core/mailman3-core_3.1.0-1_amd64-2017-09-22T09:25:55Z.build There you are, I did SIGINT before the end because it was kind of frozen. -- PEB signature.asc Description: PGP signature
Bug#875427: ITP: django-mailman3 -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty
Control: retitle -1 ITP: django-mailman3 -- A common django base of tools for Mailman3's frontends Postorius and HyperKitty Renaming the package according to it's final name. It's now in NEW. -- PEB signature.asc Description: PGP signature
Bug#799287: ITP: hyperkitty -- Web archive browser for mailman3 server
Control: retitle -1 ITP: hyperkitty -- Web archive browser for mailman3 server Renaming the package. -- PEB signature.asc Description: PGP signature
Bug#799285: ITP: postorius -- Django web user interface for accessing GNU Mailman3
Control: retitle -1 ITP: postorius -- Django web user interface for accessing GNU Mailman3 Renaming the package. -- PEB signature.asc Description: PGP signature
Bug#1058931: ITP: kdsingleapplication -- KDAB's helper class for single-instance policy applications
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: kdsingleapplication Version : 1.0.0 Upstream Author : Klarälvdalens Datakonsult AB * URL : https://github.com/KDAB/KDSingleApplication * License : MIT Programming Lang: C++ Description : KDAB's helper class for single-instance policy applications KDSingleapplication provides a helper class to make sure that an application is single-instance, that is, can't be started more than once for an user. It is a replacement for QtSingleApplication which is not maintained anymore. It's a dependency of owncloud-client, that I intend to maintain in the owncloud packaging team
Bug#986382: DPL Jonathan Carter's passport number is ****909
Le dimanche 04 avril 2021 à 21:22:16+0200, crazy.mo...@lavache.com a écrit : > Package: wnpp > Severity: wishlist > X-Debbugs-CC: > debian-proj...@lists.debian.org,debian-v...@lists.debian.org,debian-de...@lists.debian.org > > > We are contributors to Debian > > The contribution of every one of us makes the name Debian respectable > > We can't allow a crazy woman who slept with a past project leader to hijack > the name of the project and use it to scar volunteers. This happened to many > times. It stops now. > > Please stop! Delete all fascism and defamation about any volunteer that has > been instigated from Debian in any form whatsoever. Delete it from the vote, > web pages, search engines. > > Please stop! Delete all negative options from the RMS vote. We only want > positive options or nothing. We will not tolerate any outcome that is > negative for a volunteer > > If the mob does not respect our request, we are making a data dump of all the > DebConf personal data. DPL Jonathan Carter's passport number is 909. > > Privacy for everybody or privacy for nobody Go to sleep, Dan, you're drunk. -- Pierre-Elliott Bécue
Bug#986412: O: monit -- utility for monitoring and managing daemons or similar programs
oad average * Check a file or directory timestamp * Alert, stop or restart a process based on its characteristics * MD5 checksum for programs started and stopped by monit * Alert notification for program timeout, restart, checksum, stop resource and timestamp error * Flexible and customizable email alert messages * Protocol verification. HTTP, FTP, SMTP, POP, IMAP, NNTP, SSH, DWP, LDAPv2 and LDAPv3 * An http interface with optional SSL support to make monit accessible from a webbrowser Description-md5: 2230ee5609e2789db9ac60b0d3fbac89 Homepage: https://mmonit.com/monit/ Section: admin Priority: optional Filename: pool/main/m/monit/monit_5.27.1-1~bpo10+1_amd64.deb Size: 346648 SHA256: ad30730f578dd0e3b83a0591c88b8fbc6813f22d2ab5cce161f5c277064d3031 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#986414: O: parser-mysql -- MySQL driver for Parser 3
rpichev Architecture: amd64 Depends: libc6 (>= 2.14), libltdl7 (>= 2.4.6), libstdc++6 (>= 4.1.1), parser3-common (>= 3.3.0), libmariadb-dev-compat Description-en: MySQL driver for Parser 3 This package provides driver for MySQL database connections directly from Parser 3 scripts. . Parser 3 - simple and convenient object-oriented language which allows creating good sites in short time. . Available features: * XML, XSL, XPath and DOM support * Available in documented source code * Uniformed database support * Support of object-oriented programmers * Detailed language documentation (160 pages!) * UTF-8 support Description-md5: d75b039dd00d2183a76eef0a76a72fcc Homepage: http://www.parser.ru/en/download/src/ Tag: devel::interpreter, implemented-in::c++, role::plugin Section: web Priority: optional Filename: pool/main/p/parser-mysql/parser3-mysql_10.8-3_amd64.deb Size: 15556 MD5sum: 470fcfc2ddafb083d6fc9a21ca37d409 SHA256: 46f40fb4261293f0b94414130352559c4053e4d31975f4bb6930b336aa8090f6 Package: parser3-mysql Source: parser-mysql Version: 10.7-4 Installed-Size: 42 Maintainer: Sergey B Kirpichev Architecture: amd64 Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libltdl7 (>= 2.4.6), libstdc++6 (>= 5), parser3-common (>= 3.3.0) Description-en: MySQL driver for Parser 3 This package provides driver for MySQL database connections directly from Parser 3 scripts. . Parser 3 - simple and convenient object-oriented language which allows creating good sites in short time. . Available features: * XML, XSL, XPath and DOM support * Available in documented source code * Uniformed database support * Support of object-oriented programmers * Detailed language documentation (160 pages!) * UTF-8 support Description-md5: d75b039dd00d2183a76eef0a76a72fcc Homepage: http://www.parser.ru/en/download/src/ Tag: devel::interpreter, implemented-in::c++, role::plugin Section: web Priority: optional Filename: pool/main/p/parser-mysql/parser3-mysql_10.7-4_amd64.deb Size: 14708 MD5sum: 61eb96b63404ca241b40f0d338135da1 SHA256: 565ba83707cbe79acb4861afe149f10d854c51934745dcf1cdf9411d83142682 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#986413: O: parser -- Parser 3, HTML-embedded scripting language (metapackage)
r3_3.4.5-4_amd64.deb Size: 463268 MD5sum: 46fd9d516e406661f81e8dcd1ca70a26 SHA256: bc1d9936338b5ab4480f03c21054d9e9b1c43e9234a7c9679b7ddce022e86ce6 Package: parser3-dev Source: parser Version: 3.4.6-2 Installed-Size: 13 Maintainer: Sergey B Kirpichev Architecture: all Depends: parser3-common (= 3.4.6-2) Description-en: Files for Parser 3 module development This package provides the files from the Parser 3 source needed for compiling additional modules. . Parser 3 - simple and convenient object-oriented language which allows creating good sites in short time. . Available features: * XML, XSL, XPath and DOM support * Available in documented source code * Uniformed database support * Support of object-oriented programmers * Detailed language documentation (160 pages!) * UTF-8 support Description-md5: a725a0bc7f47f404c259fd0acf1acc7e Multi-Arch: foreign Homepage: http://www.parser.ru/en/ Tag: devel::lang:c++, devel::library, devel::web, implemented-in::c++, role::devel-lib Section: devel Priority: optional Filename: pool/main/p/parser/parser3-dev_3.4.6-2_all.deb Size: 3108 MD5sum: c3081497e5d30b9a2d5ff61c4a25fd2a SHA256: 5699cbf5edd1636da2b34417ec77a34bc1bd5d9998eb7f8016424dc3314ad2d8 Package: parser3-dev Source: parser Version: 3.4.5-4 Installed-Size: 13 Maintainer: Sergey B Kirpichev Architecture: amd64 Depends: parser3-common (= 3.4.5-4) Description-en: Files for Parser 3 module development This package provides the files from the Parser 3 source needed for compiling additional modules. . Parser 3 - simple and convenient object-oriented language which allows creating good sites in short time. . Available features: * XML, XSL, XPath and DOM support * Available in documented source code * Uniformed database support * Support of object-oriented programmers * Detailed language documentation (160 pages!) * UTF-8 support Description-md5: a725a0bc7f47f404c259fd0acf1acc7e Homepage: http://www.parser.ru/en/ Tag: devel::lang:c++, devel::library, devel::web, implemented-in::c++, role::devel-lib Section: devel Priority: optional Filename: pool/main/p/parser/parser3-dev_3.4.5-4_amd64.deb Size: 3172 MD5sum: 0d3393d7838f0d33436421a9066e4bc6 SHA256: ebba299b6307f74429580102e3a5c11eb2d22d2ce7cf53b8dc84da9bed3c2452 -- Pierre-Elliott Bécue GPG: 9AE0 4D98 6400 E3B6 7528 F493 0D44 2664 1949 74E2 It's far easier to fight for one's principles than to live up to them. signature.asc Description: PGP signature
Bug#718032: Closing 718032
I'm dropping this one. roccat-tools is not maintained anymore, and depends on libgaminggear which also poses its own stash of issues. Sorry for that. -- PEB signature.asc Description: PGP signature
Bug#1033272: ITP: libre-graph-api-cpp-qt-client -- C++/Qt Libre Graph API client
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libre-graph-api-cpp-qt-client Version : 1.0.1 Upstream Author : Michael Barz * URL : https://github.com/owncloud/libre-graph-api-cpp-qt-client * License : Apache-2.0 Programming Lang: C++ Description : C++/Qt client implementation of Libre Graph API The Libre Graph API is an API for open Cloud Collaboration. It provides an open source standard for open Cloud Collaboration. See the Libre Graph Home for more details. This package is a new dependency on owncloud-client, and will be maintained in the Next-Owncloud Team.
Bug#1037487: ITP: trantor -- Non-blocking I/O cross-platform TCP network library
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: trantor Version : 1.5.11 Upstream Author : An Tao * URL : https://github.com/an-tao/trantor * License : BSD Programming Lang: C++ Description : Non-blocking I/O cross-platform TCP network library Trantor is a non-blocking I/O cross-platform TCP network library, using C++14. Drawing on the design of Muduo Library This package is needed by weakforced as a transitive dependency of drogon, which I also intend to package. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
Bug#1037495: ITP: drogon -- Daemon for detecting brute force attacks
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: drogon Version : 1.8.4 Upstream Author : An Tao * URL : https://github.com/drogonframework/drogon * License : MIT Programming Lang: C++ Description : C++14/17-based HTTP application framework Drogon can be used to easily build various types of web application server programs using C++. Drogon is the name of a dragon in the American TV series "Game of Thrones" that I really like. Drogon is a cross-platform framework, It supports Linux, macOS, FreeBSD, OpenBSD, HaikuOS, and Windows. Its main features are as follows: * Use a non-blocking I/O network lib based on epoll (kqueue under macOS/FreeBSD) to provide high-concurrency, high-performance network IO, please visit the TFB Tests Results for more details; * Provide a completely asynchronous programming mode; * Support Http1.0/1.1 (server side and client side); * Based on template, a simple reflection mechanism is implemented to completely decouple the main program framework, controllers and views. * Support cookies and built-in sessions; * Support back-end rendering, the controller generates the data to the view to generate the Html page. Views are described by CSP template files, C++ codes are embedded into Html pages through CSP tags. And the drogon command-line tool automatically generates the C++ code files for compilation; * Support view page dynamic loading (dynamic compilation and loading at runtime); * Provide a convenient and flexible routing solution from the path to the controller handler; * Support filter chains to facilitate the execution of unified logic (such as login verification, Http Method constraint verification, etc.) before handling HTTP requests; * Support https (based on OpenSSL); * Support WebSocket (server side and client side); * Support JSON format request and response, very friendly to the Restful API application development; * Support file download and upload; * Support gzip, brotli compression transmission; * Support pipelining; * Provide a lightweight command line tool, drogon_ctl, to simplify the creation of various classes in Drogon and the generation of view code; * Support non-blocking I/O based asynchronously reading and writing database PostgreSQL and MySQL(MariaDB) database); * Support asynchronously reading and writing sqlite3 database based on thread pool; * Support Redis with asynchronous reading and writing; * Support ARM Architecture; * Provide a convenient lightweight ORM implementation that supports for regular object-to-database bidirectional mapping; * Support plugins which can be installed by the configuration file at load time; * Support AOP with build-in joinpoints. * Support C++ coroutines This package is needed by weakforced, which I also intend to package. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
Bug#1037498: ITP: weakforced -- Daemon for detecting brute force attacks
Package: wnpp Severity: wishlist Owner: Pierre-Elliott Bécue X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: weakforced Version : 2.8.0 Upstream Author : Neil Cook * URL : https://github.com/PowerDNS/weakforced * License : GPL-3 Programming Lang: C++, Python Description : Daemon for detecting brute force attacks The goal of 'wforce' is to detect brute forcing of passwords across many servers, services and instances. In order to support the real world, brute force detection policy can be tailored to deal with "bulk, but legitimate" users of your service, as well as botnet-wide slowscans of passwords. The aim is to support the largest of installations, providing services to hundreds of millions of users. weakforced doesn't have any real alternative for now in Debian as far as I can see. For now these packages will be in collab-maint, but I'll see if they could go somewhere. I'm maintaining them as part of my work at Gandi.net. This is therefore a Gandi.net contribution to the Debian Project.
