Bug#1077755: ITP: python-picologging -- Fast and lightweight Python logging library
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org, Kathara Sasikumar * Package name: python-picologging Version : 0.9.3 Upstream Contact: Microsoft Corporation> * URL : https://github.com/microsoft/picologging * License : MIT/X, PSF-2.0 Programming Lang: Python Description : Fast and lightweight Python logging library Picologging is a high-performance logging library for Python, it's about 4-10x faster than the logging module in the standard library. . Picologging is designed to be used as a drop-in replacement for applications which already use logging, and supports the same API as the logging module. I plan to maintin this packagae within the DPT.
Bug#1078518: ITP: python-whey-pth -- Extension for Whey to support .pth files
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-whey-pth Version : 0.0.6 Upstream Contact: Dominic Davis-Foster * URL : https://github.com/repo-helper/whey-pth * License : Expat Programming Lang: Python Description : Extension to Whey to support .pth files whey-pth adds the ability to support site-specific paths through .pth files if the Whey library is used. This package extends python3-whey and is a build dependency for sphinx-jinja2-compat which then is a build dependency for sphinx toolbox where Kathara Sasikumar and I do work on right now. I plan to maintin this packagae within the DPT.
Who is taking care of storm.debian.net?
Hi, the certificate for the domain storm.debian.net has expired yesterday. The site is not listed on https://wiki.debian.org/DebianNetDomains Knows someone who runs this service so the certificate could get renewed? -- Regards Carsten
Re: Who is taking care of storm.debian.net?
Am 12.08.24 um 10:27 schrieb Carsten Schoenert: Hi, the certificate for the domain storm.debian.net has expired yesterday. The site is not listed on https://wiki.debian.org/DebianNetDomains Knows someone who runs this service so the certificate could get renewed? O.k., I was unable to find the dedicated wiki page for this service. :-( https://wiki.debian.org/Services/storm.debian.net I contacted Laura and Kyle. -- Regards Carsten
Bug#1078788: ITP: sphinx-removed-in -- Sphinx extension recognizes *removed[-in] directives
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: sphinx-removed-in Version : 0.2.3 Upstream Contact: Alexander Todorov * URL : https://github.com/MrSenko/sphinx-removed-in * License : BSD-3-clause Programming Lang: Python Description : Sphinx extension recognizes *removed[-in] directives This Sphinx extension recognizes the .. versionremoved:: and .. removed-in:: directives. These are missing from Sphinx'es core markup. This package is a dependency for python-sphobjinv ITP #1078565 https://bugs.debian.org/1078565 The maintenance of the package will happen within the DPT.
Re: Enable external repository on package installation
Hello Pau Garcia, Am 26.10.2014 um 11:00 schrieb Pau Garcia i Quiles: > Hello, > > I am the maintainer of witty, a C++ library for web development. > > In addition to the latest version of Debian, I provide backports of the > package for all the supported versions of Ubuntu in a PPA, and for > Debian oldstable in an OBS repository. I have been doing this for years. [snip] not so far away the same question arrives some days ago here on the list: https://lists.debian.org/debian-devel/2014/10/msg00623.html -- Regards Carsten Schoenert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/544cca1d.9050...@t-online.de
Bug#703226: ITP: patchwork -- a console or web based patch tracking system
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: patchwork Version : actual like 0.0.0-[git-SH1-ID] Upstream Author : Jeremy Kerr j...@ozlabs.org * URL : http://jk.ozlabs.org/projects/patchwork/ * License : GPL2 Programming Lang: Python, Shell, Django Framwork with jquery Description : a console or web based patch tracking system Patchwork is designed to facilitate the contribution and management of contributions to an open-source project with a patch tracking system. In case of high activity on a mailinglist patches are offen neglected because of the amount of new or reworked patches every day. Patchwork helps to keep the overview to all of them because every mail with a patch gets into a database. The collected patches are then visible in a WebGUI on the server there the patchwork software is running. Inside the WebGUI it is possible for registered people to mark every single patch like 'accepted', 'under review', 'rejected' and so on. It's also possible to assign patches to single persons. Patchwork includes a python script 'pwclient' that allows the user to control the patches from a remote client. Patchwork is not related to a specifiv VCS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130317094056.ga6...@x201s.cruise.homelinux.net
Transition of Icedove 24.2.0 to testing
Hello release team, as Mike asked a few days before for Iceweasel, would it be possible to force the transition of the current Icedove version 24.2.0 from unstable to testing before Christoph will prepare the package for stable-security? I'm currently able to build a version for Wheezy but it needs a little bit further tests before it can be uploaded by Christoph. -- Regards Carsten signature.asc Description: OpenPGP digital signature
Re: Transition of Icedove 24.2.0 to testing
tags 735234 pending thanks Hello Julien, Am 02.02.2014 14:52, schrieb Julien Cristau: > That version has two RC bugs. What's with that? one of them [1] contains included minimized JS source. Christoph fixed this in one of the commits [1] after the version 24.2.0 I add the pending state to the bug as well with this mail. The other problem around mozilla-gnome-keyring [3] needs a deeper look why this happens. I'm not using mozilla-gnome-keyring so I can't really help here. Guido, Christoph and myself talked already this issue, but Christoph and Guido didn't have enough time to get the reason for the behavior. Ximin wasn't able to add a log with debugging symbols, so we have to readjust it first. Hopefully we find next week some time to catch the error. In the end there is also another RC bug report [4] (to be honest) that relay on the same issue. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735234 [2] http://anonscm.debian.org/gitweb/?p=pkg-mozilla/icedove.git;a=commit;h=f4e6c0854b8f687a7bc6af39bf3395444bddf333 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732652 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724688 -- Regards Carsten signature.asc Description: OpenPGP digital signature
Bug#774928: ITP: libcoap -- library for the CoAP protocol written in C
Package: wnpp Severity: wishlist Owner: Carsten Schoenert -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: libcoap Version : 4.1.1 Upstream Author : Olaf Bergmann * URL : http://sourceforge.net/projects/libcoap/ * License : GPL2+ and BSD Programming Lang: C Description : C Library Implementation of CoAP The libcoap is basically a C implementation of the IETF CoAP (Constrained Application Protocol). The CoAP protocol is major standardized by the IETF in the RFC 7252 and is a application layer protocol for low power devices for the Internet of Things (IoT) and Machine to Machine (M2M) communication. CoAP is mostly used in 6loWPAN environments. The libcoap library provides functions to talk to such devices and makes it possible to interact with low power IPv6 based devices. There are some other frameworks written in Java, Python or JavaScript that implement CoAP bindings. As far as I know there is nothing yet packaged for the use of the CoAP protocol. That's the main reason why I want to package and maintain the libcoap package. Currently the upstream source is lacking some minor tweaks like versioning of the library and also symbol versioning. The build environment is improvable. I'm in contact with Olaf Bergmann to improve the situation here. He is willing to take some external hints and work so after tuning the build process it will be easier to package the libcoap. I don't need a sponsor, happily Guido Guenther is willing to upload the package after checking my work. http://coap.technology/ http://www.ietf.org/rfc/rfc7252.txt http://6lowapp.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJUr5JGAAoJEIMBYBQlHR2wlWQQAJVL/LoGm2vUQp4V79mMpiLP o3Dj3/cv73iAn4FWPDOoXdK7ic7OdA3u36nllYdYhMQGak2pNFtxe+foBGDxmISt 3I7cpolX8qmej+zOLb64aZ0XGRwjolXM5ZppID8aXpRHPWm0JPNEovyOqY83T33C 6qRJ3c96TuDN3Xn+k0oYW9uVRI5WwvtQfyUUk6A27gnPUnxaiq2jBJkYOWaS5mvu AlRExGj/koouB0k+C2VHfq6HYQd3JoS/suxYjWJC/PIRaO7HRiR87iHFxwsI39xl VsozSUzHw3WE+FcxC8aPmnrfFSMA65UgYtkjmgdv9JokT4r9hL3xB/n28ZS0XeZK 7Plr7yRYg1SzmYnjb2U4lCVkDwfCo32MQ+e5DdDE2dbDl3XOwnZ9RIXU812CzUoV nz+zdIvGhnwPSa+lahTXDGDENYGuPkhA46qqd3q7kVlRvEgECOo0XYe/0cjsrAnl C8ZX11RyAc2cvB+1pOFUb7ZOfmWzJI8L4m9UBkPjFL5kmSDoY1K/tJtOv7uycb9I xhUv8IsIaJusQSVlNyQeXFQ2Daq7JzilKC9L2Q3A2qRlQXtTAgtaLp5Rqrnoe9iQ XiQDa2iPpDUOR0j38oaT8wVpbzpgACPpPUIu2oDek3ugGRTWTfpaa5ZoweZ5qZPA tlH+sxDm9fNoyU3+o2Fp =cGu7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150109083310.18537.12719.report...@x201s.cruise.homelinux.net
Bug#783603: ITP: libvmime -- C++ class library for working with RFC-822 and MIME messages
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: libvmime Version : 0.9.1 Upstream Author : Vincent RICHARD * URL : http://www.vmime.org * License : GPL v3 Programming Lang: C++ Description : C++ class library for working with RFC-822 and MIME messages VMime is a powerful C++ class library for working with RFC-822 and MIME messages and Internet messaging services like IMAP, POP or SMTP. . With VMime you can parse, generate and modify messages, and also connect to store and transport services to receive or send messages over the Internet. The library offers all the features to build a complete mail client. . Main Features Overview * RFC-2822 and multipart messages * aggregate documents and embedded objects * 8-bit MIME and encoded word extensions * full support for attachments * POP3, IMAP, SMTP, maildir and sendmail * SSL/TLS security layer and X.509 certificates (using either GNU TLS or OpenSSL) * SASL authentication (using GNU SASL) * Internationalized Email Support (RFC-6532) libvmime is a build dependencie for the Zarafa packages and was removed from the repository with a request for removal on bug #774306 some times ago. The pakage will be maintained by the pkg-giraffe maintainers. https://alioth.debian.org/projects/pkg-giraffe/ Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150428101453.28364.30749.report...@lenovo.as-it.org
Bug#783640: ITP: zarafa-webaccess -- Next generation web interface for Zarafa
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: zarafa-webaccess Version : 2.0.2 Upstream Author : Zarafa BV, Delft, NL * URL : http://www.zarafa.com/ * License : AGPL3 Programming Lang: PHP, JS, CSS Description : Next generation web interface for Zarafa Collaborations Platform zarafa-webapp provides various plugins for the main zarafa-server application. The plugins are written in PHP with usage of CSS, JSON and Ext JS for usage in modern web browser for the use of the Zarafa Collaboration Platform. This package is recommended packae for the zarafa-server packages which will get some drive after changes to the license by Zarafa. See ITP #658433 for more infos on the zarafa-server packages. The package will be maintained by the pkg-giraffe maintainers. https://alioth.debian.org/projects/pkg-giraffe/ Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150428164429.4942.23014.report...@jessie.cruise.homelinux.net
Re: Script to generate common license texts
Hello Balasankar, Am 04.09.2015 um 19:38 schrieb Balasankar C: > Hi, > > Is there any script which takes abbreviation of a license (like > GPL-3+) as input and generates the license text that can be used in > debian/copyright (80 character wrapped, one space before each line, > paragraph separated with periods - the whole deal. > > For example, if the script is named 'genlicense', the command > $ genlicense gpl-3.0+ > > should give the following output > > License: GPL-3.0+ > This program is free software: you can redistribute it and/or modify it > under > the terms of the GNU General Public License as published by the Free > Software > Foundation, either version 3 of the License, or (at your option) any later > version. > . > This package is distributed in the hope that it will be useful, but WITHOUT > ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or > FITNESS > FOR A PARTICULAR PURPOSE. See the GNU General Public License for more > details. > . > You should have received a copy of the GNU General Public License along > with > this program. If not, see <http://www.gnu.org/licenses/>. > . > On Debian systems, the complete text of the GNU General Public License > version > 3 can be found in "/usr/share/common-licenses/GPL-3". > > > > Is there any script which does this already? If not, can I write one > that supports all DFSG-happy licenses and add it to devscripts? I was successful using the cme command [1] from the package libconfig-model-dpkg-perl [2] while refreshing the copyright information for Icedove to create a base for further working. But there are surly other tools. [1] https://ddumont.wordpress.com/2015/04/05/improving-creation-of-debian-copyright-file/ [2] https://packages.qa.debian.org/libc/libconfig-model-dpkg-perl.html -- Regards Carsten Schoenert
Re: wxWidgets GTK+ 3 build available
Hello Scott, Am 25.11.18 um 02:31 schrieb Scott Talbert: > Hi, > > Since ~March, we have a GTK+ 3 build of wxWidgets in Unstable/Testing. > Packages that use wxWidgets may switch over to this build if they desire, > although we are not pushing to remove the wx GTK+ 2 package in Buster, so > packages can continue to use the GTK+ 2 build for Buster. > > To switch a package over to the GTK+ 3 build, it could be as simple as > changing the Build-Depends from libwxgtk3.0-dev to libwxgtk3.0-gtk3-dev, > rebuilding, and testing. unfortunately I can't simply switch over to libwxgtk3.0-gtk3-dev for the kicad package as some of the applications become mostly unusable if the GTK+3 version of libwxgtk library is used. Upstream is working on this problem but I fear were won't be a GTK+3 ready source of kicad before the full freeze of Buster. KiCad is partially also depending on wxpython3.0. But here there are only GTK+3 linked binaries currently available and by this I need to disable a useful scripting feature (used for AddOns) in KiCad since the upload of 3.0.2.0+dfsg-7 [1]. For wxwidgets you are providing also "legacy" GTK+2 versions of the libraries. Would this also be possible for wxpython3.0? Currently all downstream distros are in the same position as me for the KiCad package. [1] https://tracker.debian.org/news/945651/accepted-wxpython30-3020dfsg-7-source-amd64-all-into-unstable-unstable/ -- Regards Carsten Schoenert
Bug#920199: ITP: ponyprog -- Serial device programmer
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: ponyprog Version : 3.0.0~rc0 Upstream Author : Claudio Lanconelli Eduard Kalinowski * URL : https://github.com/lancos/ponyprog * License : GPL-2+, LGPL-2.1 Programming Lang: C++, Description : Serial device programmer PonyProg is a serial device programmer software with a user friendly GUI framework available for Windows and Linux. Its purpose is reading and writing every serial device. With PonyProg and SI-Prog you can program Wafercard for SAT, eeprom within GSM, TV or CAR-RADIO. Furthermore it can be used as a low cost starter kit for PIC and AVR. . PonyProg supports AVR, SPI eeprom, AVR micro, 12C bus 8bit eeprom, PIC 16 micro, PIC 12 micro, AT89S micro and SDE2506 eeprom family chips. . You can open any HEX, e2p, mot, csm, rom, eep, bin files and burn them to uC or PIC. You can even backup the old program on the chip using Ponyprog. Ponyprog enables the user to write, verify and erase data on the microchip. . Set fuse bits and locks using PonyProg. You can save any HEX file to BIN file or eep file,BIN file to HEX file or MOT file and vice versa so you can use Ponyprog as converter too. PonyProg offers serial or parallel port programming for uC's. You can even change polarity of control lines without touching the wires using I/O port setup. . Using Ponyprog together with generic USB2serial adapters is currently not possible! There are plans by upstream to use libusb to add such functionality. This package will be maintained within the Debian Electronics team. Co-maintainers are welcome! Regards Carsten
Re: Recreating history of a package
Am 06.02.19 um 17:59 schrieb Carsten Leonhardt: > Ian Jackson writes: > >> There are utilities that will download all revisions of a particular >> package from snapshot.d.o and make them into a combined history. > > Would you care to name those you know of? I have been searching for > something like that but I didn't find anything useful. I know of at least git-buildpackage will do this with the option '--import-dscs' by importing all available versions from the Debian archives. I assume Ian's tool can do something similar. -- Regards Carsten Schoenert
Fwd: Thunderbird bugday April 8 and April 13
Hi there, as I'm subscribed within the (private) Thunderbird Drivers mailing list and the upstream people of Thunderbird asked a few linux distro people to forward the email you see further down to other people of their linux distro. So I will do. ;) If someone has some spare free time (hehe, I know we are in the hard freeze :-) ) here is another option to contribute to something useful. -- Regards Carsten Schoenert Forwarded Message Distro folks. Thunderbird bugdays are happening on Monday and Saturday, and we are keen to have linux participants. Can you help us by publicizing through your available channels, or if not you personally then pass this to someone who can do the publicity? Blog announcement at https://blog.mozilla.org/thunderbird/2019/04/all-bugs-fixed/ and short verbiage below [1]. Thanks Wayne and Ryan [1] Thunderbird bugday is back! In this "event", incomplete bug reports are triaged to get them to a level of quality needed for a developer to act on it. And you get to choose which bug reports interest you. Participants will get a Thunderbird Game of Bugs t-shirt! See design and announcement at https://blog.mozilla.org/thunderbird/2019/04/all-bugs-fixed/ ) Monday April 8: In EU and Americas time zones - morning, afternoon, and evening Saturday April 11: EU zones all day (morning, afternoon, evening); Americas zones morning and afternoon East coast, West coast until 2pm MDT/1pm PDT It is as easy as clicking a link in your browser. Follow the instructions for the bullet "mibbit web" at https://wiki.mozilla.org/Thunderbird:Bugdays#Where -- Regards Carsten Schoenert -- Regards Carsten Schoenert -- Regards Carsten Schoenert
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Am 13.04.19 um 11:15 schrieb Svante Signell: > Please give up on Debian. They clearly have no interest in anything > non-linux or non-systemd, that is fully clear. Let's make a joint > effort to make a Guix release of Hurd (and kFreeBSD) happen. Or, if you > still want to continue using apt-style distributions, join Devuan. > Please, don't support the non-universal OS movement driven by Debian > people! I can't follow that style of discussion. You seems to really want to not accept some facts about the kFreeBSD and Hurd architectures. On the one hand you complaining about Debian is a *non*-universal OS, on the other side I haven't seen a broader supporting from the people who wanting these architectures to stay in Debian on some important packages. Please stop to complain on non specific things and start to solve the problems you see or have! You know: Someone means YOU, it's all up to the people to keep things running. Or simply move over to other projects were you feel more comfortable with. There is enough space for all of us. Both architectures haven't seen any major development in the past years and for me as a maintainer of packages the workload on supporting these architectures between the new upstream releases costs a lot of time with no real gain in the end as the build dependencies later can not be fulfilled or most of the time while importing new source I'm working on readjust the patch queue! So I disagree on "One person is enough" as long this one person can not keep track on all the required main and corner cases so other maintainers get to do the workload here alone. -- Regards Carsten Schoenert
Re: Hurd-i386 and kfreebsd-{i386,amd64} removal
Samuel, Am 13.04.19 um 12:06 schrieb Samuel Thibault: >> I can't follow that style of discussion. > > Please don't, Svante is only trolling here, please don't feed him. yes, this is true. As you've answered in your other email, such emails bringing no real gain or progress. >> I haven't seen a broader supporting from the people who wanting these >> architectures to stay in Debian on some important packages. > > I can only agree. I hear a lot of people saying that the Hurd port > existing is a great thing, but a lot less people helping with it. > > (I do thank all the people who work on it without necessarily being > noticed). > >> Both architectures haven't seen any major development in the past years > > They have. O.k. need to be more specific, so the same as you mentioned further down, ..."in the context of Debian, the packages of Debian and it releases". > Patching software should be handled upstream indeed. Yes, but most upstreams are a bit reserved especially if it's about Hurd as they have no knowledge about (but I also don't) and fearing that patches will break and complicate other things, kFreeBSD is a bit easier or more accepted and known. But I here also see the porters to get also in touch with upstream as I'm as the maintainer of a package not necessarily have the knowledge to keep the specific architecture up to date in the upstream project or simply have no time or interest on this. >> So I disagree on "One person is enough" > > I meant only for the Debian-specific things, I am the only DD who > currently uses its key for signing packages, making CD images, etc. > That's what I meant by "the daily ports things". Well, I guess it's not that easy I fear as there are no parts that can be seen as separate standalone things, it's all connected in various ways. As I've not written this in my previous email, so to state it now, I've a big respect on your work on Hurd! But realistically it's not enough in my eyes to keep Hurd on even tracking the normal evolving of Debian. > For the non-Debian-specific things like patching packages, I am > thankfully really not alone, and I completely agree it can't be a > one-person thing. Sometimes it's amazing to see with what people can came up with, and gladly there are also porter people where I get patches for other ports to keep packages building successful. -- Regards Carsten Schoenert
Improving Reimburse workflow? (Re: Suspending Offer to Reimburse Expenses for Attending Future Bug Squashing Parties)
Hello Holger, hello Sam, Am 12.06.19 um 17:15 schrieb Holger Levsen: ... >> I do not feel valued in this interaction. > > as said, me really neither. I try to help and get yelled at. > > and then there are the are those contributors which right now are also > less valued then before, because the programm is suspended. 100 USD > might not be much for you and me, but for some 100 USD make a great > difference. I'm not that long in Debian than you both, but on some corners within the Debian universe I felt sometimes the processes are really old fashioned and some kind of ... nighties style. And I also fear we will find some more procedures that will not work well for the current DPL simply because Sam is a blind person and the workflows are really not made for such kind of disabled persons. So it's obvious to me that we will need to rethink some workflows so things like reimbursement will not be horrible thing to work on for both participating parties. As long I'm able to traveling within Germany or Europe and the travel costs aren't that much I have avoided to ask for an reimbursement simply because I found the process to complicated for me. A lot of email traffic is needed and because of this a lot of time I'd need to invest. But I know there is also the 'other' side that have to prove my request. So a wild guess, why isn't it possible to create a webui which is guiding me through a reimbursement request and also make it possible to collect all the requests to the persons which have to agree or disagree on the calls? And even a more wild guess, isn't creating such an UI or system something Debian can order somewhere if no person will jump into such an work? We have a lot of Devs which working in companies who are earning money by build any kind of WebUI for customers, or maybe we need to look for some synergy effects by combines things, I mean the SPI is also handling reimbursements. -- Regards Carsten Schoenert
Re: AMDGPU+OpenCL with Debian?
Hi, Am 17.06.19 um 21:15 schrieb PICCA Frederic-Emmanuel: > Same here... with WXX100 cards. > what about rocm packaging ? (I'm not using an AMD graphic card but ...) there was recently a new article added to the Debian wiki regarding this topic about using the official AMDGPU driver. Maybe this helps solving some questions? https://wiki.debian.org/How%20to%20install%20official%20AMDGPU%20linux%20driver%20with%20kernel%204.19.x%20on%20Stretch%20and%20Buster -- Regards Carsten Schoenert
Bug#930973: ITP: hiera-py -- Python language bindings for the hiera hierarchical database
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
* Package name: hiera-py
Version : 0.0.1
Upstream Author : Thomas Van Doren
* URL : https://github.com/agx/hiera-py
* License : BSD
Programming Lang: Python
Description : Python language bindings for the hiera hierarchical database
Hiera is a key/value lookup tool for configuration data, often used in Puppet
and created and built to make Puppet better and let you set node-specific data
without repeating yourself.
.
Hiera’s hierarchical lookups follow a “defaults, with overrides” pattern,
meaning you specify common data once, and override it in situations where the
default won’t work.
.
The hierarchical data can be organised as JSON, YAML, and EYAML files.
Thomas Van Doren has created this Python library mainly in 2013 but has
the further development stopped some time ago and archived his tree on
GitHub.
The original GitHub tree is forked since than several times and on some
of these forks people have added some own needed features and partially
added also Python3 compatibility. By the help of Guido Guenther the
current packaging is already completely Python3 compatible.
We use this Python library on my day job because we can structure
configuration item for a lot of measurement devices really nicely.
Getting config items is really easy by this library.
>>> import hiera
>>> hiera_client = hiera.HieraClient('/etc/hiera.yml', environment='dev')
>>> hiera_client.get('my_key')
'my_value'
I will maintain this package on Salsa on
https://salsa.debian.org/tijuca/hiera-py (to be created).
Bug#1037009: ITP: python-drf-spectacular-sidecar-nonfree -- Serve builds of Swagger UI and Redoc for Django REST framework
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-drf-spectacular-sidecar-nonfree Version : 2023.5.1 Upstream Contact: T. Franzel * URL : https://github.com/tfranzel/drf-spectacular-sidecar * License : Apache-2.0, BSD-3, MIT/X Programming Lang: Python, JS, CSS Description : Serve builds of Swagger UI and Redoc for Django REST framework Serve self-contained distribution builds of Swagger UI and Redoc with Django either via runserver or collectstatic. This Django app is an optional addition to drf-spectacular, but does not depend on it. It may also be used independently. It uses parts of Swagger UI version 4.18.3 Redoc version 2.0.0 The pulled in files for Swager-UI und Redoc are fetched from jsdelivr and are unfortunately only the minimized parts that probbaly make the package non-free as I'm unable to rebuild them. . The source for Redoc is available from https://github.com/Redocly/redoc but isn't packaged or available in some form in Debian. The same is true for Swagger UI, the source is also avaialbe on GitHub https://github.com/swagger-api/swagger-ui So far also no Debian packages are created yet for Swagger-UI which could be used to rebuild or reference the used minimized files in drf-spectacular-sidecar. This package is new dependency for NetBox (see ITP https://bugs.debian.org/1017079) as since version 3.5.0 NetBox Upstream has moved over to support using the OpenAPI 3.0 spec to generate the REST API schema. I plan to maintain the package within the an Debian Python Team. As like for NetBox I appreciate any help around how the minimized files could be rebuild so the package wouldn't needed to be placed in non-free. Regards Carsten
Bug#1051758: ITP: python-ruyaml -- YAML 1.2 loader/dumper package for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-ruyaml Version : 0.91.0 Upstream Contact: Anthon van der Neut, Ruamel bvba Sorin Sbarnea * URL : https://github.com/pycontribs/ruyaml * License : MIT Programming Lang: Python Description : YAML 1.2 loader/dumper package for Python The ruyaml package is a fork of ruamel.yaml aimed to made in order to secure the future of the library, mainly by having a pool of maintainers and can be used as a drop-in replacement for python3-ruamel.yaml. This package is a dependency for yamlfix (a simple opinionated yaml formatter that keeps your comments) which I intend to package to. Packaging will happen within the Debian Python Team.
Bug#1051978: ITP: python-yamlfix -- Simple opionated yaml formatter that keeps your comments
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-yamlfix Version : 1.13.0 Upstream Contact: Lyz * URL : https://github.com/lyz-code/yamlfix * License : GPL-3 Programming Lang: Python Description : Simple opionated yaml formatter that keeps your comments yamlfix is a Python based YAML file formatter which will fix any known formatting issue within your YAML files automatically. . It can read configuration settings from pyproject.toml, from configuration files or environment variables while it is called from the CLI or by including as Python library. . Main feature are: * Add the header --- to your file. * Correct truthy strings: 'True' -> true, 'no' -> 'false' * Remove unnecessary apostrophes: title: 'Why we sleep' -> title: Why we sleep. * Correct comments * Ensure that there is exactly one newline at the end of each file, to comply with the POSIX standard. * Split long lines. * Respect Jinja2 syntax. * Convert short lists to flow-style list: [item, item] * Convert lists longer than line-width to block-style This package will get maintained within the Debian Python Team.
Re: QDMR on Raspberry Pi OS?
Hello Dan, Am 10.10.23 um 03:28 schrieb Dan Tallant: Like the subject says, curious about bringing the QDMR cps software for Linux to the Raspberry Pi os (specifically 64 bit running on the Pi4 w/8gb RAM) like this one? $ apt search qdmr Sorting... Done Full Text Search... Done qdmr/testing 0.11.2-1+b1 amd64 GUI application to program DMR radio And looking at the project website should give more information about the status. https://dm3mat.darc.de/qdmr/install.html -- Regards Carsten
Re: ITP: art/6.1-1 --ASCII art
Hello Yogeswaran, Am 23.10.23 um 02:33 schrieb Yogeswaran Umasankar: * Package name : art Version : 6.1-1 Upstream contact : Sepand Haghighi * URL : https://github.com/sepandhaghighi/art * License : MIT * Vcs : https://salsa.debian.org/NGC2023/art Section : python Description: ASCII art the name 'art' is a very generic name, I suggest to use python-art according the source is a python library and a similar functionality could be also be provided by other programming languages. The same is true for the binary package name, usually and mostly the package name is prefixed by 'python3-'. PS: Please use reportbug to write your ITPs! It is setting all headers correctly. https://wiki.debian.org/reportbug -- Regards Carsten Schönert
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
Hello Steve, Am 31.01.24 um 21:59 schrieb Steve Langasek: ... Please find the patch for this NMU attached. If you have any concerns about this patch, please reach out ASAP. ^^ Although this package will be uploaded to experimental immediately, there will be a period of several days before we begin uploads to unstable; so if information becomes available that your package should not be included in the transition, there is time for us to amend the planned uploads. I'm a bit puzzled and disappointed. libcopap3 isn't a package that is within the QA group nor is it bit rotting. What is the rationale behind rising a bug report at 9:51pm my time and firing a *direct* NMU upload just 11min later (according to the time stamps from the emails)? I as the uploader for libcoap have no chance to do any action on this bug report! This behavior I'm not expecting within Debian. What are the plans now with forwarding the underlying issue to upstream? Upstream is very responsive and I've good contacts to the upstream authors, but who is doing this work now? I read the wiki page mentioned from the initial email again, also there I can't find a written plan that would explain me why the bug reporting together with a direct upload did happen. I see no plan there what will happen on what time. Why no usual muss bug filling did happen so groups and maintainers would have some knowledge about these planned changes? BTW: I've no problem with the technical thing what is happen, but I need to deal also with other things too like a CVE fix for libcopa3. -- Regards Carsten
Re: [Debian-iot-maintainers] Bug#1062257: libcoap3: NMU diff for 64-bit time_t transition
Am 01.02.24 um 09:30 schrieb Steve Langasek: What is the rationale behind rising a bug report at 9:51pm my time and firing a *direct* NMU upload just 11min later (according to the time stamps from the emails)? There are 1200+ source packages that require NMUing and the Debian archive is a moving target. In the past 3 days the list of packages requiring uploads has been regenerated 3 times with changes each time due to archive removals, new sonames in unstable, etc. Churning through the list of 1200 packages is at this rate going to take at least a week (after 4 days we've gotten bugs filed and NMUs to experimental completed for less than 400 of the 1200 packages). It is not practical to leave a gap of any significant length of time between the filing of bugs in patches and the uploads to experimental. Then the text of the email that was raised against any package makes no real sense to me. Who should I reach out ASAP? In which time span. No sorry, I can't follow. And I still see no real reason for rushing now anything. We had other similar transitions that worked also without that rather rude behavior to me. And yes, unstable is a moving target, but that it is for more than 2 decades every day. So that's the normal case. There will be a pause between the uploads to experimental, and the uploads to unstable, which gives space for maintainer feedback while we run analysis against the contents of experimental with regards to usrmerge. That doesn't really helping me, as this set just pressure on me . Again, I've nothing against this technically, but the communication about what is happening and why this is happening is terrible as it just doesn't exit to me. This is an ABI change resulting from a change to compiler flags. You will see the diff includes no changes to upstream source. There is nothing to forward. Great, would be good if that was also communicated by the email. Since this has only been uploaded to experimental, I would expect this does not interfere with your CVE handling? Well, not directly, but at a time this all needs to get melt together. And this take time on my side as *I* need then to grab the other things manually to get this into the VCS. -- Regrads Carsten
Bug#1065749: ITP: flask-debugtoolbar -- Debugging toolbar overlay information for Flask applications
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: flask-debugtoolbar Version : 0.14.1 Upstream Contact: Pallets * URL : https://github.com/pallets-eco/flask-debugtoolbar * License : BSD-3-clause Programming Lang: Python, JS Description : Debugging toolbar overlay information for Flask applications Flask is a micro web framework for Python based on Werkzeug, Jinja 2 and good intentions. . This python3 package adds a toolbar overlay to Flask applications containing useful information for debugging. This package is the equivalent of python-django-debug-toolbar but for Flask. I intend to maintain this packge within the DPT.
Bug#977605: ITP: arduino-core-avr -- Arduino Core for AVR microcontroller
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: arduino-core-avr Version : 1.8.3 Upstream Author : Arduino * URL : https://github.com/arduino/ArduinoCore-avr * License : BSD-3-clause, Expat, GPL-2+, ISC, LGPL-2.1+ Programming Lang: Assembler, C, C++, Description : Arduino Core for AVR microcontroller This package contains the source code and configuration files of the Arduino Core for Atmel's AVR microcontroller used on the Arduino Yún, Uno, Uno WiFi, Diecimila, Nano, Mega, MegaADK, Leonardo, Leonardo Ethernet, Micro, Esplora, Min, Ethernet, Fio, BT, LilyPadUSB, Lilypad, Pro, ATMegaNG, Robot Control, Robot Motor, Gemma, Yún Mini. . It also contains some basic interfaces for interacting with the internal non-volatile storage (aka EEPROM) in AVR based Arduino boards. Also interfaces for interacting with plugable USB infrastructure (HID), for the Serial Programming Interface (SPI), for serial communication on any digital pins and for communicaton by I2C and Two Wire Interfaces devices. This package is a new dependency for an updated Arduino package. It will be maintained within the Electronics team.
Bug#987417: ITP: libcoap3 -- C-Implementation of CoAP, API version 3
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libcoap3 Version : 4.3.0~rc2 Upstream Author : Olaf Bergmann * URL : https://libcoap.net * License : BSD-2-clause Programming Lang: C Description : C-Implementation of CoAP, API version 3 Lightweight application-protocol for devices that are constrained their resources such as computing power, RF range, memory, bandwidth, or network packet sizes. This protocol, CoAP, is developed in the IETF working group "CoRE", <http://6lowapp.net> and was standardized in RFC 7252. The libcoap library has been evolved and has now reached the API version 3 which includes changes that makes the library not backward compatible. To keep the packages from libcoap3 co-installable to the current upstream version of libcoap will go into a new source package. The packaging will be done within the IoT packaging group as a team managed package. Regards Carsten
Bug#988971: ITP: python-django-crispy-forms-foundation -- django-crispy-forms layout objects for Foundation for sites
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-django-crispy-forms-foundation
Version : 0.8.0
Upstream Author : David THENON
* URL : https://github.com/sveetch/crispy-forms-foundation
* License : Expat
Programming Lang: Python
Description : django-crispy-forms layout objects for Foundation for sites
This is a Django application to add django-crispy-forms layout objects for
the CSS framework Foundation for sites. It depends on the
python3-crispy-forms library.
.
django-crispy-forms provides you with a |crispy filter and {% crispy %} tag
that will let you control the rendering behavior of your Django forms in a
very elegant and DRY way. Have full control without writing custom form
templates. All this without breaking the standard way of doing things in
Django, so it plays nice with any other form application.
.
django-crispy-forms supports several frontend frameworks, such as Twitter
Bootstrap (versions 3 and 4), Uni-form and Foundation. You can also easily
adapt your custom company's one, creating your own, see the docs for more
information. You can easily switch among them using CRISPY_TEMPLATE_PACK
setting variable.
This package is a depending package we use at our infrastructure on my
day job.
It will be maintained within the DPT.
Bug#989527: ITP: python-markuppy -- module to generate HTML/XML content
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-markuppy Version : 1.14 Upstream Author : Tyler Bakke * URL : https://pypi.org/project/MarkupPy * License : MIT public-domain Programming Lang: Python Description : module to generate HTML/XML content MarkupPy is a Python module that attempts to make it easier to generate HTML/XML from a Python program in an intuitive, lightweight, customizable and pythonic way. MarkupPy is derived from markup.py. There is a GitHub project for this library, unfortunately it's lagging far behind the visible data on PyPi. https://github.com/tylerbakke/MarkupPy This library is a new build and install dependency for python3-tablib which I intend updating to the current usptream version. This package will get maintained within The Python Modules Team.
Bug#989811: ITP: python-funcy -- Collection of fancy functional tools focused on practicality
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-funcy Version : 1.16 Upstream Author : Alexander Schepanovski * URL : https://github.com/Suor/funcy * License : BSD-3-clause, MIT Programming Lang: Python Description : Collection of fancy functional tools focused on practicality Funcy is designed to be a layer of functional tools over Python. It provides some possible often wanted functionality like: * Merge collections of same type (works for dicts, sets, lists, tuples, iterators and even strings). * Walk through collection, creating its transform (like map but preserves type). * Select a part of collection. * Manipulate sequences. * And functions. * CreAbstract control flowate decorators easily. * Abstract control flow. * Ease debugging. This package is a (build) dependency for django-cachops which hasn't a ITP yet. django-cacheops itself is a dependency for netbox I consider to package. The package will get maintained within the Debian Python Team.
Bug#990085: ITP: django-rq -- Django integration with RQ (Redis Queue)
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-rq Version : 2.4.1 Upstream Author : Selwin Ong * URL : https://github.com/rq/django-rq * License : MIT Programming Lang: Python Description : Django integration with RQ (Redis Queue) Django-RQ is a simple app that allows you to configure your queues in django's settings.py and easily use them in your project. This package is a (build) dependency for netbox I consider to package. The package will get maintained within the Debian Python Team.
Bug#990289: ITP: django-pglocks -- Django based context manager for PostgreSQL advisory locks
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-pglocks Version : 1.0.4 Upstream Author : Christophe Pettus * URL : https://github.com/Xof/django-pglocks * License : MIT Programming Lang: Python Description : Django based context manager for PostgreSQL advisory locks django-pglocks is a context manager for Django. Advisory locks are application-level locks that are acquired and released purely by the client of the database; PostgreSQL never acquires them on its own. They are very useful as a way of signalling to other sessions that a higher-level resource than a single row is in use, without having to lock an entire table or some other structure. It's entirely up to the application to correctly acquire the right lock. Advisory locks are either session locks or transaction locks. A session lock is held until the database session disconnects (or is reset); a transaction lock is held until the transaction terminates. Currently, the context manager only creates session locks, as the behavior of a lock persisting after the context body has been exited is surprising, and there's no way of releasing a transaction-scope advisory lock except to exit the transaction. This package is a dependency for netbox I consider to package. The package will get maintained within the Debian Python Team.
Bug#990341: ITP: swagger-spec-validator -- Validation of Swagger specifications
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: swagger-spec-validator Version : 2.7.3 Upstream Author : core-servi...@yelp.com Semir Patel Stephan Jaensch * URL : https://github.com/Yelp/swagger_spec_validator * License : Apache-2.0 Programming Lang: Python Description : Validation of Swagger specifications Swagger Spec Validator is a Python library that validates Swagger Specs against the Swagger 1.2 (https://github.com/swagger-api/swagger-spec/blob/master/versions/1.2.md) or Swagger 2 (https://github.com/swagger-api/swagger-spec/blob/master/versions/2.0.md) specification. The validator aims to check for full compliance with the Specification. This package is a dependency for netbox I consider to package. The package will get maintained within the Debian Python Team.
Bug#990420: ITP: django-cacheops -- Django app adding automatic or manual queryset caching
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-cacheops Version : 6.0 Upstream Author : Alexander Schepanovski * URL : https://github.com/Suor/django-cacheops * License : BSD-3-clause Programming Lang: Python Description : Django app adding automatic or manual queryset caching django-cacheops is a slick app that supports automatic or manual queryset caching and automatic granular event-driven invalidation. . It uses redis as backend for ORM cache and redis or filesystem for simple time-invalidated one. . And there is more to it: . * decorators to cache any user function or view as a queryset or by time * extensions for django and jinja2 templates * transparent transaction support * dog-pile prevention mechanism * a couple of hacks to make django faster This package is a dependency for netbox I consider to package. django-cacheops has build depenendency on python3-funcy which is currently waiting in the NEW queue (see ITP #989811). The package will get maintained within the Debian Python Team.
Bug#990874: ITP: drf-yasg-nonfree -- Yet another Swagger generator
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: drf-yasg-nonfree Version : 1.20.0 Upstream Author : Cristi V. * URL : https://github.com/axnsan12/drf-yasg * License : BSD-3-clause Programming Lang: Python Description : Yet another Swagger generator Generate real Swagger/OpenAPI 2.0 specifications from a Django Rest Framework API. Features of drf-yasg: * full support for nested Serializers and Schemas * response schemas and descriptions * model definitions compatible with codegen tools * customization hooks at all points in the spec generation process * JSON and YAML format for spec * bundles latest version of swagger-ui (https://github.com/swagger-api/swagger-ui) and redoc (https://github.com/Rebilly/ReDoc) for viewing the generated documentation * schema view is cacheable out of the box * generated Swagger schema can be automatically validated by swagger-spec-validator (https://github.com/Yelp/swagger_spec_validator) * supports Django REST Framework API versioning with URLPathVersioning and NamespaceVersioning; other DRF or custom versioning schemes are not currently supported Some parts of the upstream data are shipped pre-generated within the source, the package built isn't able to rebuild these files from source for various reasons. Mainly because the used JS files aren't packaged yet for Debian. This makes the resulting package non-free from the DFSG PoV. That's why I decided to use the suffix '-nonfree' for now. Resulting also the binary packages will go into non-free. If someone is willing to help making this package DFSG compatible I'd really be glad to take such an offer. This package is a dependency for netbox I consider to package. The package will get maintained within the Debian Python Team.
Bug#991679: ITP: python-text-unidecode -- most basic Python port of the Text::Unidecode Perl library
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-text-unidecode Version : 1.3 Upstream Author : Mikhail Korobov * URL : https://github.com/kmike/text-unidecode/ * License : Artistic, GPL Programming Lang: Python Description : most basic Python port of the Text::Unidecode Perl library This library is an alternative of other Python ports of Text::Unidecode (unidecode and isounidecode). unidecode (in Debian available as python3-unidecode) is licensed under GPL; isounidecode uses too much memory, and it also didn’t support Python 3 when text-unidecode was created. This package is an indirect dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991692: ITP: python-promise -- Implementation of Promises in Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-promise Version : 2.3.0 Upstream Author : Syrus Akbary * URL : https://github.com/syrusakbary/promise * License : MIT Programming Lang: Python Description : Implementation of Promises in Python It is a super set of Promises/A+ designed to have readable, performant code and to provide just the extensions that are absolutely necessary for using promises in Python. Its fully compatible with the Promises/A+ spec. This package is an indirect dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991736: ITP: graphql-relay -- Relay Library for GraphQL Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: graphql-relay Version : 3.1.0 Upstream Author : Syrus Akbary * URL : https://github.com/graphql-python/graphql-relay-py * License : MIT Programming Lang: Python Description : Relay Library for GraphQL Python This package contains the Relay (https://relay.dev/) library for GraphQL-core. . It allows the easy creation of Relay-compliant servers using GraphQL-core. GraphQL-Relay-Py is a Python port of graphql-relay-js (https://github.com/graphql/graphql-relay-js), while GraphQL-Core is a Python port of GraphQL.js (https://github.com/graphql/graphql-js), the reference implementation of GraphQL for JavaScript. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991740: ITP: graphql-core -- GraphQL implementation for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: graphql-core Version : 3.1.5 Upstream Author : Christoph Zwerschke * URL : https://github.com/graphql-python/graphql-core * License : MIT Programming Lang: Python Description : GraphQL implementation for Python GraphQL-core 3 is a Python 3.6+ port of GraphQL.js, the JavaScript reference implementation for GraphQL, a query language for APIs created by Facebook. GraphQL-core provides a reference implementation for the GraphQL specification but is also a useful utility for operating on GraphQL files and building sophisticated tools. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991775: ITP: graphene -- GraphQL Framework for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: graphene Version : 2.1.9 Upstream Author : Syrus Akbary * URL : https://github.com/graphql-python/graphene * License : MIT Programming Lang: Python Description : GraphQL Framework for Python Graphene is a Python library for building GraphQL schemas/types fast and easily. . * Easy to use: Graphene helps you use GraphQL in Python without effort. * Relay: Graphene has builtin support for Relay. * Data agnostic: Graphene supports any kind of data source: SQL (Django, SQLAlchemy), NoSQL, custom Python objects, etc. Upstream believes that by providing a complete API you could plug Graphene anywhere your data lives and make your data available through GraphQL. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991812: ITP: django-graphene -- Django integration for Graphene
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-graphene Version : 2.15.0 Upstream Author : Syrus Akbary * URL : https://github.com/graphql-python/graphene-django * License : MIT Programming Lang: Python Description : Django integration for Graphene Graphene-Django is built on top of Graphene. Graphene-Django provides some additional abstractions that make it easy to add GraphQL functionality to your Django project. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Bug#991872: ITP: python-graphene -- GraphQL Framework for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-graphene Version : 2.1.9 Upstream Author : Syrus Akbary * URL : https://github.com/graphql-python/graphene * License : MIT Programming Lang: Python Description : GraphQL Framework for Python Graphene is a Python library for building GraphQL schemas/types fast and easily. . * Easy to use: Graphene helps you use GraphQL in Python without effort. * Relay: Graphene has builtin support for Relay. * Data agnostic: Graphene supports any kind of data source: SQL (Django, SQLAlchemy), NoSQL, custom Python objects, etc. Upstream believes that by providing a complete API you could plug Graphene anywhere your data lives and make your data available through GraphQL. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team. Additional information, due a mistake of me by not safely checking for the availability of the intended source package name I raised a similar ITP (#991775) some days ago. Due this my upload went to the already existing source package graphene. https://tracker.debian.org/pkg/graphene I've requested the removal of my upload into the NEW queue.
Bug#992446: ITP: django-graphiql-debug-toolbar -- Django Debug Toolbar for GraphiQL IDE
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-graphiql-debug-toolbar Version : 0.1.4 Upstream Author : mongkok * URL : https://github.com/flavors/django-graphiql-debug-toolbar * License : MIT Programming Lang: Python Description : Django Debug Toolbar for GraphiQL IDE This package adds a debug toolbar within your Django application for the GraphiQL IDE. This package is an direct dependency for the next major version of NetBox (will be version 3) which I consider to package. The package will get maintained within the Debian Python Team.
Re: gbp vs. vcswatch - how to create automatic debian tags?
Hello Adrian, Am 05.10.21 um 12:06 schrieb John Paul Adrian Glaubitz: > Hi Timo! > > On 10/5/21 12:04, Timo Röhling wrote: >> * John Paul Adrian Glaubitz [2021-10-05 >> 11:45]: >>> Could anyone tell me what the proper gbp command is for creating the >>> changelog >>> entries for the new release including the proper tag. The gbp manual [1] >>> mentions >>> Debian tags but it doesn't seem to explain how to create them. >> >> I usually run "gbp dch -R -c" first, then build and upload the >> package, and finalize with "gbp tag && gbp push". >> >>> And if I wanted to add the tags later manually and push them, what is the >>> expected >>> format of the tags? Just "debian/$VERSION"? >> >> Yes. > > Perfect, thank you. This answers all my questions. I usually sign all the tags I've made (or gbp is doing for me e.g. while importing). So the tagging within a Debian branch looks then $ $ gbp tag --sign-tags $ $(other further things to be done) -- Regards Carsten
Bug#998222: ITP: mssql-django -- Django backend for Microsoft SQL Server
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mssql-django Version : 1.0 Upstream Author : Microsoft * URL : https://github.com/microsoft/mssql-django * License : BSD-3-clause Programming Lang: Python Description : Django backend for Microsoft SQL Server This package is a fork of django-mssql-backend which isn't getting developed any more. The package provides an MSSQL database connectivity option for the Django Web Framework, with support for Microsoft SQL Server and Azure SQL Databases. This package will be maintained within the Python Packaging team.
Bug#1002633: ITP: mkdocs-material-extensions -- Markdown extension resources for MkDocs for Material
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocs-material-extensions Version : 1.0.3 Upstream Author : Isaac Muse * URL : https:/github.com/facelessuser/mkdocs-material-extensions * License : MIT Programming Lang: Python Description : Markdown extension resources for MkDocs for Material MkDocs Material provides numerous icons from Material, FontAwesome, and Octicons, but it does so by inlining the SVG icons into the source. Currently there is no easy way access these icons and arbitrarily insert them into Markdown content. Users must include the icon fonts themselves and do it with HTML. . This module allows you to use PyMdown Extensions' Emoji extension to enable easy insertion of MkDocs Material's SVG assets using simple :emoji-syntax:. This is done by creating our own emoji index and emoji generator. The custom index provides a modified version of the Emoji extensions Twemoji index. This package uses pymdown-extensions to extend the functionality of mkdoc-material. Both packages from above are uploaded to NEW while writing this ITP. https://ftp-master.debian.org/new/pymdown-extensions_9.1-1.html https://ftp-master.debian.org/new/mkdocs-material_8.1.3-1.html mkdocs-material is a new dependency for NetBox, pymdown-extensions and also mkdocs-material-extensions are new indirect dependencies for MetBox. I plan to maintain this package within the Debian Python Team.
Bug#1002695: ITP: python-markdown-include -- Extension to Python-Markdown
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-markdown-include Version : 0.6.0 Upstream Author : Chris MacMackin * URL : https://github.com/cmacmackin/markdown-include * License : GPL-3 Programming Lang: Python Description : Extension to Python-Markdown This package is an extension for python3-markdown and provides an "include" function, similar to that found in LaTeX (and also the C pre-processor and Fortran). This package is another indirect dependency for NetBox. I plan to maintain this package within the DPT.
Bug#1004681: ITP: wcag-contrast-ratio -- Library computing contrast ratios required by WCAG 2.0
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: wcag-contrast-ratio Version : 0.9 Upstream Author : Geoffrey Sneddon * URL : https://github.com/gsnedders/wcag-contrast-ratio * License : MIT Programming Lang: Python Description : Library computing contrast ratios required by WCAG 2.0 This package provides a Python library that calculates the contrast ratio of colors based on the Web Content Accessibility Guidelines (WCAG) 2 standard, published by the Web Accessibility Initiative (WAI). The actual WCAG technical documents are created by the Accessibility Guidelines Working Group (AG WG), which are part of the WAI. . This library also provides some checking if contrast meets the required level. This packge is a new build dependency for recent versions of pygments. It will be maintained within the Python Team.
Bug#1006163: ITP: pyyaml-env-tag -- Custom YAML tag for referencing environment variables
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pyyaml-env-tag Version : 0.1 Upstream Author : Waylan Limberg * URL : https://github.com/waylan/pyyaml-env-tag * License : MIT Programming Lang: Python Description : Custom YAML tag for referencing environment variables This library is the Python port of yaml-env-tag, a Ruby library to use referenced environment variables within YAML files. This library is a new build dependency for recent versions of python-mkdocs. It will be maintained under the umbrella of Debian Python Team.
Bug#1006479: ITP: mergedeep -- Deep merge function for Python
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mergedeep Version : 1.3.4 Upstream Author : Travis Clarke * URL : https://github.com/clarketm/mergedeep * License : MIT Programming Lang: Python Description : Deep merge function for Python This library can help if you need to do some deep merge without mutating the source dicts or while you want to deep merging into an existing dict. It provides various merge strategies (Replace, Additive, Typesafe replace, or Typesafe additive). This package is a new build dependency for python-mkdocs and will be maintained within the DPT.
Bug#1006480: ITP: mkdocs-redirects -- Plugin for mkdocs to create page redirects
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocs-redirects Version : 1.0.1 Upstream Author : Dustin Burke * URL : https://github.com/datarobot/mkdocs-redirects * License : MIT Programming Lang: Python Description : Plugin for mkdocs to create page redirects MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains an addon for mkdocs to create page redirects (e.g. for moved/renamed pages). This package is a new build dependency for python-mkdocs and will be maintained within the DPT.
Bug#1008086: ITP: python-lunr -- Python implementation of Lunr.js
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-lunr Version : 0.6.1 Upstream Author : Yeray Diaz Diaz * URL : https://github.com/yeraydiazdiaz/lunr.py * License : MIT/X, BSD Programming Lang: Python Description : Python implementation of Lunr.js This package includes the Python version of Lunr.js aims to bring the simple and powerful full text search capabilities into Python guaranteeing results as close as the original implementation as possible. . Lunr is a simple full text search solution for situations where deploying a full scale solution like Elasticsearch isn't possible, viable or you're simply prototyping. Lunr parses a set of documents and creates an inverted index for quick full text searches in the same way other more complicated solution. . The trade-off is that Lunr keeps the inverted index in memory and requires you to recreate or read the index at the start of your application. This package is a new dependency for newer versions of pydoctor and will get maintained within the DPT. Regards Carsten
Bug#1009221: ITP: pytkdocs -- Legacy Python handler for mkdocstrings
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: pytkdocs Version : 0.16.1 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/pytkdocs * License : ISC Programming Lang: Python Description : Load Python objects documentation This Python library is used to load Python objects documentation. It accepts JSON on standard input and writes JSON on standard output. . It is typically used to read data from standard input while writing processed data line by line. Especially mkdocstrings is wanting this behavior. This package is a new indirect dependency for the recent released minor version of NetBox 3.2.x. It will be maintained within the Debian Python Team.
Bug#1009255: ITP: mkdocs-autorefs -- Plugin for MkDocs to automatically link across pages
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocs-autorefs Version : 0.4.1 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/autofefs * License : ISC Programming Lang: Python Description : Plugin for MkDocs to automatically link across pages MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains an plugin for MkDocs that can add linking across the various sites created by MkDocs. This package is a new indirect dependency for the recent released minor version of NetBox 3.2.x. It will be maintained within the Debian Python Team.
Bug#1009892: ITP: mkdocstrings -- Automatic Python documentation from sources for MkDocs
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocstrings Version : 0.17.0 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/mkdocstrings * License : ISC Programming Lang: Python Description : Automatic Python documentation from sources for MkDocs MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains an plugin for MkDocs to build automatic documentation from docstrings within your source code files. This package is a new direct dependency for the recent released minor version of NetBox 3.2.x. It will be maintained within the Debian Python Team.
Bug#1010382: ITP: mkdocstrings-python-legacy -- Legacy Python handler for mkdocstrings
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocstrings-python-legacy Version : 0.2.2 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/python-legacy * License : ISC Programming Lang: Python Description : Legacy Python handler for mkdocstrings MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains an legacy Python handler used within mkdocstrings. This package is a new dependency for mkdocstrings >= 0.18 which due a split of existing legacy Python functions moved into a own library. It will be maintained within the Debian Python Team.
Bug#1011192: ITP: python-griffe -- Signatures for entire Python programs
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-griffe Version : 0.18.0 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/griffe * License : ISC Programming Lang: Python Description : Signatures for entire Python programs Extract the structure, the frame, the skeleton of your project, to generate API documentation or find breaking changes in your API. This package is a new indirect dependency for mkdocstrings >= 0.18.0 because mkdocstrings got refactored into more dedicated libraries and tools since version 0.18.0. In detail python-griffe is a dependency of mkdocstings-python-handlers which itself is a dependency of mkdocstrings-python-legacy. It will be maintained within the Debian Python Team.
Bug#1011194: ITP: mkdocstrings-python-handlers -- Python handler for mkdocstrings
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocstrings-python-handlers Version : 0.6.6 Upstream Author : Timothée Mazzucotelli * URL : https://github.com/mkdocstrings/python * License : ISC Programming Lang: Python Description : Python handler for mkdocstrings MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains a Python handler required by various helping libraries around mkdocstrings. This package is a new direct dependency for mkdocstrings >= 0.18.0 because mkdocstrings got refactored into more dedicated libraries and tools since version 0.18.0. In detail mkdocstings-python-handlers is a dependency of mkdocstings-python-legacy which is now required by mkdocstrings >= 0.18.0. It will be maintained within the Debian Python Team.
Bug#1013194: ITP: django-rich -- Extensions for using Rich with Django
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: django-rich Version : 1.4.0 Upstream Author : Adam Johnson * URL : https://github.com/adamchainz/django-rich * License : MIT Programming Lang: Python Description : Extensions for using Rich with Django Rich is a Python library for writing rich text (with color and style) to the terminal, and for displaying advanced content such as tables, markdown, and syntax highlighted code. . The djano-rich library is adding such functionality into a Django integration so colourized outputs and nice traceback rendering is possible. This Django extension is an upcoming new requirement for NetBox next minor version 3.3 (not yet released). It will be maintained within the Debian Python Team.
Bug#1017079: ITP: netbox -- WebUI based tool designed to manage and document computer networks
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: netbox Version : 3.2.8 Upstream Author : Jeremy Stretch * URL : https://github.com/netbox-community/netbox * License : Apache-2.0 and MIT/X Programming Lang: Python Description : WebUI based tool designed to manage and document computer networks NetBox is a Django based web application, initially conceived by the network engineering team at DigitalOcean, NetBox was developed specifically to address the needs of network and infrastructure engineers. It encompasses the following aspects of network management: . * Hierarchical regions, site groups, sites, and locations * Racks, devices, and device components * Cables and wireless connections * Power distribution * Data circuits and providers * Virtual machines and clusters * IP prefixes, ranges, and addresses * VRFs and route targets * FHRP groups (VRRP, HSRP, etc.) * AS numbers * VLANs and scoped VLAN groups * Organizational tenants and contacts . In addition to its extensive built-in models and functionality, NetBox can be customized and extended through the use of: . * Custom fields * Custom links * Configuration contexts * Custom model validation rules * Reports * Custom scripts * Export templates * Conditional webhooks * Plugins * Single sign-on (SSO) authentication * NAPALM integration * Detailed change logging . NetBox also features a complete REST API as well as a GraphQL API for easily integrating with other tools and systems. . While NetBox strives to cover many areas of network management, the scope of its feature set is necessarily limited. This ensures that development focuses on core functionality and that scope creep is reasonably contained. To that end, it might help to provide some examples of functionality that NetBox does not provide: . * Network monitoring * DNS server * RADIUS server * Configuration management * Facilities management I plan to maintain netbox within the Debian Python Team ideally together with some more interested people in managing the maintenance. Right now all needed build and binary package dependencies are fulfilled, as NetBox is getting actively developed it constantly bugfixes and new added features which might need new dependencies in the near future which are not packed yet. I'd like to see (if possible) the netbox package within the bookworm release. The NetBox UI is using some comprehensive JS files which are shipped as minimized files. Currently I'm unable to drop the shipped minimized code and rebuild all the needed files from scratch. If possible I'd like to get some help on this, currently netbox will need to go into non-free due the non rebuild-able minimized files. OTOH netbox can't go into main as it requires at least one package from non-free, it requires drf-yasg-nonfree for some Swagger functionality. Regards Carsten
Bug#1020611: ITP: python-trio-websocket -- Server and client Python library of the WebSocket protocol
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-trio-websocket Version : 0.9.2 Upstream Author : John Belmonte * URL : https://github.com/HyperionGray/trio-websocket * License : MIT/X Programming Lang: Python Description : Server and client Python library of the WebSocket protocol This library implements both server and client aspects of the WebSocket protocol, striving for safety, correctness, and ergonomics. It is based on the wsproto project, which is a Sans-IO state machine that implements the majority of the WebSocket protocol, including framing, codecs, and events. This library handles I/O using the Trio framework. This library passes the Autobahn Test Suite. This package is a new dependency for python-selenium and will be maintained within the Debian Python team.
Bug#1022155: ITP: mkdocs-click -- MkDocs extension to generate documentation for Click command line applications
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocs-click Version : 0.8.0 Upstream Author : packa...@datadoghq.com * URL : https://github.com/DataDog/mkdocs-click * License : Apache-2.0 Programming Lang: Python Description : MkDocs extension to generate documentation for Click command line applications This package contains a MkDocs extension that lets you generate the documentation for the Click command line applications within your documentation dynamic created from the source code files. This package is new build dependency for python-mkdocs >= 1.4.1. It will be maintained within the Debian Python Team.
Bug#1023891: ITP: mkdocs-literate-nav -- MkDocs extension to specify the navigation in Markdown
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: mkdocs-literate-nav Version : 0.5.0 Upstream Author : Oleh Prypin * URL : https://github.com/oprypin/mkdocs-literate-nav * License : MIT/Expat Programming Lang: Python Description : MkDocs extension to specify the navigation in Markdown MkDocs is a fast, simple and downright gorgeous static site generator that's geared towards building project documentation. Documentation source files are written in Markdown, and configured with a single YAML configuration file. . This package contains the mkdocs-literate-nav extension, which allows one to use Markdown instead of YAML to define a navigation structure within your MkDocs based documentation files. This package is a new additional build requirement for the documentation of the MkDocs project itself since a few versions. But is also used by some other MkDocs based project documentations. It will be maintained within the Debian Python Team.
Bug#1023892: ITP: markdown-callouts -- Python-Markdown extension adding a new block-level syntax
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: markdown-callouts Version : 0.3.0 Upstream Author : Oleh Prypin * URL : https://github.com/oprypin/markdown-callouts * License : MIT/Expat Programming Lang: Python Description : Python-Markdown extension adding a new block-level syntax This package extends the functionality of Python Markdown by turning a paragraph of text into a block that's specially highlighted and set apart from the rest of the text. . This extension produces the same results as the admonition extension, but with a syntax that is much less intrusive and has a very reasonable fallback look for "vanilla" renderers. This package is a build dependency for mkdocs-literate-nav (ITP #1023891). It will be maintained within the Debian Python Team.
Bug#1026261: ITP: markdown-exec -- Utilities to execute code blocks in Markdown files
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: markdown-exec Version : 1.0.0 Upstream Contact: Timothée Mazzucotelli * URL : https://pawamoy.github.io/markdown-exec * License : ISC Programming Lang: Python Description : Utilities to execute code blocks in Markdown files This package enhances the functionality of PyMdown Extensions (provided within Debian as package python3-pymdownx). You can use markdown-exec if you write e.g a Python code block that computes some HTML and you want to place the generated HTML within a code block. This package is new build dependency for mkdocstrings >= 0.19.1 It will be maintained within the Debian Python Team.
Bug#1028188: ITP: python-validate-pyproject -- Automated checks on pyproject.toml by JSON Schema definitions
Package: wnpp Severity: wishlist Owner: Carsten Schoenert X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-validate-pyproject Version : 0.10.1 Upstream Contact: Anderson Bravalheri * URL : https://github.com/abravalheri/validate-pyproject * License : BSD, MIT, MPL-2.0 Programming Lang: Python Description : Automated checks on pyproject.toml by JSON Schema definitions With the approval of PEP 517 and PEP 518, the Python community shifted towards a strong focus on standardisation for packaging software, which allows more freedom when choosing tools during development and make sure packages created using different technologies can interoperate without the need for custom installation procedures. . This shift became even more clear when PEP 621 was also approved, as a standardised way of specifying project metadata and dependencies. . validate-pyproject was born in this context, with the mission of validating pyproject.toml files, and make sure they are compliant with the standards and PEPs. Behind the scenes, validate-pyproject relies on JSON Schema files, which, in turn, are also a standardised way of checking if a given data structure complies with a certain specification. This package is a dependency for pdm-backend (not yet filed a ITP) and will be maintained within the Debian Python team. Upstream uses a vendored version of fastjsonschema shipped in the folder src/validate_pyproject/_vendor/. The reasoning isn't currently clear why this is needed. Due this vendoring there are multiple licenses comes to play. I've tried to entagle this vendoring but hadn't luck until yet. pdm-backend calles itself it is the successor for pdm-pep517 but hasn't reached a stable version number yet.
Re: Opera 12.16 on Debian 10 is not working
Am 30.10.19 um 18:30 schrieb Andrej Shadura: Hi, On Wed, 30 Oct 2019, 17:43 , <mailto:patrick.dre...@gmx.net>> wrote: Dear Woman and Man! Opera 12.16 on Debian 10 is not working. http://ftp.opera.com/ftp/pub/opera/linux/1216/ How is the problem solved? Debian doesn't ship Opera. Patrick is doing writing to -devel with various topics from time to time. :) https://lists.debian.org/debian-devel/2019/06/msg00357.html https://lists.debian.org/debian-devel/2019/06/msg00358.html https://lists.debian.org/debian-devel/2019/06/msg00359.html ... https://lists.debian.org/debian-devel/2019/06/msg00362.html https://lists.debian.org/debian-devel/2019/08/msg00370.html -- Regards Carsten Schoenert
Re: Q: what's the blocker for firefox-esr update migrates to testing
Am 31.10.19 um 16:28 schrieb Aron Xu: This could be a reminder that we should start thinking about whether we want to keep armel as a release architecture for bullseye. No, but some X-based applications might simply get excluded from the that architecture. There are still a lot armv5 based hardware outside which is simply working fine with recent Debian releases. I see no real reason to make all this hardware obsolete simply because some software which requires some X features isn't build-able on armel. -- Regards Carsten Schoenert
Re: Q: what's the blocker for firefox-esr update migrates to testing
Am 01.11.19 um 14:55 schrieb Aron Xu: I'm not implying to remove it altogether, but it could be moved it to debian-ports, even RPi4 is alreay aarch64 capable. This is not the question (of course arm64 != armel) and I don't see why a still well maintained and working architecture should move to ports. I'm really happy that even my 10+ years old armv5 based hardware is still supported by Debian, otherwise I had a lot of electronic waste. The main problem with armel was the support by buildd infrastructure but this is thanks to the effort made by Steve this is no actual problem anymore. -- Regards Carsten Schoenert
Bug#950536: ITP: iconnect-tools -- system administration helping tools for Iomega iConnect
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: iconnect-tools Version : 0.1 Upstream Author : Carsten Schoenert * URL : https://salsa.debian.org/tijuca/iconnect-tools * License : MIT Programming Lang: Shell Description : system administration helping tools for Iomega iConnect The Iomega iConnect is a Marvell Kirkwood (ARM) Linux-based NAS device which comes with 4 USB ports, GbE and wireless support (802.11g). This package contains some small helpers for using a Debian installation on the Iomega iConnect. . It contains a systemd service file for controlling the info LEDs on the front of the device but also a simple UDEV rule and helper script to show recognized USB devices a user has plugged in. It also serve a Sysctl configuration file to decrease the sync rate of the Linux kernel for writing data to the swap file on a USB device. . The package provides also a configuration file for the u-boot-tools package so the U-Boot environment can be read and modified from a running Debian installation. Additional notes The Iomega iConnect is not a recent peace of hardware, it's about 10 years old but is still running without problems. As long Debian is providing packages for the armel architecture this hardware will running smoothly. The iConnect is avaialable for cheap money on Amazon or EBay e.g. I've recently adjusted the debian-installer as WIP and can install Debian in the iConnect without further needed modifications (except the U-Boot environment). https://people.debian.org/~tijuca/iconnect/ The people from OpenWRT have probably the best hardware overview if you don't know about the Iomeag iConnect. https://openwrt.org/toh/iomega/iconnect
Bug#963237: ITP: raritan-json-rpc-sdk -- JSON-RPC SDK for various Raritan product series like PDUs and Transfer Switches
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: raritan-json-rpc-sdk Version : 3.6.0 Upstream Author : Raritan Inc. * URL : https://www.raritan.com/support/product/px3 (look for JSON-RPC Bindings) * License : GPL+2, BSD-3 Programming Lang: C#, Perl, Python, Java Description : JSON-RPC SDK for Raritan PDU product series PXE, PX2, PX3, PXC, PXO, PX3TS, BCM2 and EMX2 Raritan is providing various components around power distribution within e.g. data center which all have a of course a network interface to interact with. Recent PDUs (Power Distribution Units) come along with a lot of features for managing power switching and measurement, user management and more. Raritan has integrated a powerful RestAPI within their products and is providing library binding for C#, Perl, Python and Java by their JSON-RPC SDK. Contrary to other companies Raritan decided to provide their management SDK by a DFSG compatible license. So far I know all other similar products from other companies doesn't have FOSS libraries for managing their components. I use parts of the provided API on my day job to control a big amount of PDUs in different cities. I intent to package the Python part and also the Perl library with help from Gregor Herrmann (thx!). C# and Java should be doable too but this needs volunteers as I don't have enough experience for these languages and packaging. Upstream is also providing a Doxygen generated documentation for the JSON-RPC bindings. https://help.raritan.com/json-rpc/pdu/v3.6.0/ I intent to package this too, right now only the pre build html, js and CSS files are available. I'm in contact with upstream to get all required files for getting this rebuild. Regards Carsten
Re: Backports needed for Firefox/Thunderbird ESR 78 in Buster/Stretch
Hello Félix, Am 20.09.20 um 11:33 schrieb Félix Sipma: > Hello Emilio and others, > > On 2020-09-10 19:32+0200, Emilio Pozuelo Monfort wrote: >> I'm currently attempting a build of Firefox 78.2.0 ESR for buster. If that >> goes >> well I'll start uploading things to buster (coordinating with the SRMs). > > Was the build successful? Did you also try to build Thunderbird? Is > there something else missing? for Thunderbird there is still some work to do, currently not related to the work of Emilio. There wasn't any attempt from my side to merge the unstable/testing tree into the buster related one until now. First I need to get Thunderbird into unstable and hopefully soon to testing. If there are no big problems to fix first then we can go on to work on Thunderbird for Buster (and Stretch). Thunderbird is again suffering a bit from a big API change for Add-ons as you might know. And as a lot of users are using GPG for encryption we shouldn't make the migration to the included OpenPGP support not harder as needed. --- Regards Carsten Schoenert
Bug#844643: ITP: flatcam -- 2D Computer-Aided PCB Manufacturing on a CNC router
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: flatcam Version : 8.5 Upstream Author : Juan Pablo Caram * URL : http://flatcam.org/ * License : MIT Programming Lang: Python Description : 2D Computer-Aided PCB Manufacturing on a CNC router FlatCAM is a program for preparing CNC jobs for creating prototyps of PCBs on a CNC router. You can open Gerber, Excellon or G-code, edit it or create from scratch, and output G-Code. Isolation routing is one of many tasks that FlatCAM is perfect for. There seems to be no other packaged software for PCB milling in Debian, as this peace of software is rather small and not complex I think it's useful, at least for me. I'd like to place this package into the pkg-electronics team as other PCB related package are workend on there. I will need a sponsor. Regards Carsten
Re: Where can build scripts be found?
Hello Thomas, Am 25.01.2017 um 23:05 schrieb Thomas Nyberg: ... > I'm trying to compile my own version of icedove to see if I can > understand certain bugs I'm running into (at the moment I just get > random crashes, so I can't really report anything useful). I tried the > following steps on a new machine: the src:icedove package has a huge list of needed dependencies to get the package build. So mainly at least one dependency that is missing will break the build. For this we (the package maintainers) use usually a chroot to build the icedove package. As you also probably want to change the source of the Icedove you will need to handle the debian patches then. The icedove packages are using git-buildpackage to document and utilize the changes we have made. So I would suggest to follow the hints we've written into the wiki for people like you who want to rebuild Icedove. https://wiki.debian.org/Icedove/Devel#Icedove_Package_Development You will need to create a chroot first before you can start if you use the gbp workflow. We use cowbuilder/pbuilder for that, but sbuild will also work. For creating a cowbuilder/pbuilder chroot you can use git-pbuilder (from git-buildpackage). Please see the wiki page for that. https://wiki.debian.org/git-pbuilder Feel free to contact me directly if you need more help while (re)creating Icedove packages. -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Hello, Am 16.02.2017 um 17:49 schrieb Michael Biebl: > Am 16.02.2017 um 12:01 schrieb Nick Morrott: >> Could it not migrate to $HOME/.mozilla/thunderbird, to be consistent >> with firefox? > > ~/.thunderbird is the upstream default location for some reason and I > think it makes sense to not diverge from upstream in that regard. exactly for that reason! We simply have not the manpower to do such things that doesn't bring really much effort. -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Hello Adam, Am 15.02.2017 um 22:12 schrieb Adam Borowski: >> * Copy the contents of the old profile folder into the new folder >> ~/.icedove_moved_by_thunderbird_starter > > I see no deletion step. This is bad for a couple of reasons: > * my .icedove takes north of 2GB (mostly imap cache of multiple servers), > one of my users clocks above 7GB for a single server > * if you have some sensitive mail and delete it, you really don't want a > copy to stick forever. Especially if you then go through a border... there is a reason why we decided to not delete anything here that is related to the users scope. We don't want delete user files and configuration as the impact of a deleted folder or files is much bigger as not used backup of a folder. So we have to go into one direction in the end. And I don't see a needed discussion about that small issue as mostly every singe MP3 file is bigger than the common users profile folder for Mozilla Thunderbird. -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Am 15.02.2017 um 19:49 schrieb Contact Webmasteur: > Thunderbird in Debian Jessie and Debian Stretch ? When ? There is simple answer for this, it's done if it's done. This will mean, Stretch is on the way and for now it looks good I think. For Jessie we need to start the packaging work, but also modify the existing wrapper script as we don't have planned to switch the Thunderbird profiles folder to the upstream default. -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Am 16.02.2017 um 19:26 schrieb Michael Biebl: > You already have a NEWS entry for the de-branding which talks about the > user profile. Maybe add an additional section there, that the old > profile is kept as ~/.icedove and that the user can delete that manually > if the upgrade has been completed successfully. Yes, that's a good point. We will add something like this in one of the future uploads. -- Regards Carsten Schoenert
Bug#888104: ITP: kicad-symbols -- schematic symbols for KiCad's eeschema
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: kicad-symbols Version : 5.x.x+$date Upstream Author : KiCad Community * URL : https://kicad.github.io/symbols/ * License : CC-BY-SA 4.0 with exception* Programming Lang: Plain text Description : schematic symbols for KiCad's Eeschema editor Eeschema is a powerful schematic capture software distributed as part of KiCad. A schematic design with Eeschema is heavily based on the availability of schematic symbols which needed to be used for creating of own schematics. Due the flexibility of Eeschema and the nature of community driven development of schematics for KiCad with a fast evolution of symbols for Eeschema it's difficult to keep track of the new and updated symbols with the more static releases of KiCad itself (currently the schematic symbols are available by kicad-common). Thus it makes sense to keep the packaging of symbols for Eeschema in a own source package as this makes it easier to provide updated packages not only for unstable/testing. kicad-symbols will be a part of the transition of the existing kicad-common package into own pieces. The package will be maintained in the pkg-electronics-team together with Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu). We will try to keep the package the same in Debian and Ubuntu. More Co maintainers are welcome! *License exception "To the extent that the creation of electronic designs that use 'Licensed Material' can be considered to be 'Adapted Material', then the copyright holder waives article 3 of the license with respect to these designs and any generated files which use data provided as part of the 'Licensed Material'." more license information http://kicad-pcb.org/libraries/license/
Bug#888108: ITP: kicad-footprints -- footprint libraries for KiCad's Pcbnew editor
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: kicad-footprints Version : 5.x.x+$date Upstream Author : KiCad Community * URL : https://kicad.github.io/footprints/ * License : CC-BY-SA 4.0 with exception* Programming Lang: Plain Text Description : footprint libraries for KiCad's Pcbnew editor Pcbnew is a powerful printed circuit board software and part of the KiCad suite. Pcbnew manages libraries of footprints. Each footprint is a drawing of the physical component including its land pattern (the layout of pads on the circuit board). Footprints have a strong relationship to the schematic symbols that are used in Eeschema and both parts (kicad-symbols and kicad-footprints) depending on each other in some way. Like for the schematic symbols the footprints are also evolving and growing fast and this brings in some difficulty to provide actual footprint data for KiCad within Debian and like planned for the schematic symbols the footprints need to go also into a own source package. This is another part of transitioning the existing kicad-common package into dedicated smaller packages. The package will be maintained in the pkg-electronics-team together with Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu). We will try to keep the package the same in Debian and Ubuntu. More Co maintainers are welcome! *License exception "To the extent that the creation of electronic designs that use 'Licensed Material' can be considered to be 'Adapted Material', then the copyright holder waives article 3 of the license with respect to these designs and any generated files which use data provided as part of the 'Licensed Material'." more license information http://kicad-pcb.org/libraries/license/
Bug#888116: ITP: kicad-packages3d -- 3d model libraries for KiCad's Pcbnew editor
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: kicad-packages3d Version : 5.x.x+$date Upstream Author : KiCad Community * URL : https://kicad.github.io/packages3d/ * License : CC-BY-SA 4.0 with exception* Programming Lang: Plain Text Description : 3d model libraries for KiCad's Pcbnew editor Pcbnew is a powerful printed circuit board software and part of the KiCad suite. The 3d models are intended to be rendered by the Pcbnew 3d viewer or other MCAD software. These 3d models are completely optional and not really needed for developing any PCB layout but they give a great possibility to see how your PCB would look like. A downside of the 3d models are the size of each model. That's one of the reasons for this ITP, the current available 3d models are that big to be packaged in the existing kicad-common package and a own source package is easier to handle in the long term. The package will be maintained in the pkg-electronics-team together with Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu). We will try to keep the package the same in Debian and Ubuntu. More Co maintainers are welcome! *License exception "To the extent that the creation of electronic designs that use 'Licensed Material' can be considered to be 'Adapted Material', then the copyright holder waives article 3 of the license with respect to these designs and any generated files which use data provided as part of the 'Licensed Material'." more license information http://kicad-pcb.org/libraries/license/
Bug#888476: ITP: kicad-templates -- read to use project templates for KiCad
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: kicad-templates Version : 5.x.x+$date Upstream Author : KiCad Community * URL : https://github.com/KiCad/kicad-templates * License : CC-BY-SA 4.0 with exception* Programming Lang: Plain text Description : read to use project templates for KiCad KiCad is a cross platform and Open Source EDA (Electronics Design Automation) suite which can be used for the creation of electronic schematic diagrams and PCB artwork. The flexibility is mainly based on libraries for schematic symbols, footprints and 3D models. But it also offers a template mechanism which makes it easy for user to base their work on prepared projects which can include prearranged schematic and or basic PCB layouts. Really common examples for such templates are well prepared PCB layouts for the Arduino boards but also for Raspberry PI or BeagleBone. Such templates are currently installed by kicad-common. Due the regular updates to the kicad-templates library it's difficult to follow that dynamic development with the more contrary static preparation of point releases of KiCad without (the mostly unneeded) completely rebuild of the existing src:kicad package. Like done for the schematic symbols, footprints and 3d-packages this ITP is to move out the templates into a own source package and make package maintenance easier. For the users this brings more frequent updates of the KiCad community templates. The package will be maintained in the pkg-electronics-team together with Jean-Samuel Reynaud (maintainer of the daily build PPA for Ubuntu). We will try to keep the package the same in Debian and Ubuntu. More Co maintainers are welcome! *License exception "To the extent that the creation of electronic designs that use 'Licensed Material' can be considered to be 'Adapted Material', then the copyright holder waives article 3 of the license with respect to these designs and any generated files which use data provided as part of the 'Licensed Material'." more license information http://kicad-pcb.org/libraries/license/
Bug#888489: ITP: ngspice-dfsg -- Spice circuit simulator - DFSG compatible parts
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: ngspice-dfsg Version : 27 Upstream Author : various (mainly Holger Vogt, Paolo Nenzi, Robert Larice) * URL : http://ngspice.sourceforge.net/ * License : BSD-3-clause, LGPL-2(+), GPL-2(+) Programming Lang: C, TclTk, plain text Description : Spice circuit simulator - DFSG compatible parts Packages for NGspice are available due license incompatibilities in old versions to the DFSG only in non-free. With version 27 (released in September 2017) most of the used non DFSG compatible licensed files/folders have been moved over to BSD 3-clause (upstream uses here the name 'New BSD') and by this the build-able files and binary stuff can now be considered as free enough by the DFSG. There are still parts that uses licenses that aren't compatible with the DFSG. All those parts can be excluded and the binaries are built without support of that software parts. NGspice upstream has updated their online available FAQ [2] about the used licenses, please look at point 1.5. I prepared a wiki site to collect and track the status for files and folders in question [3]. My working tree can be found on GitHub [4] for now. I'd really happy if someone can have a look at this especially for the license issues which the new version shouldn't have any longer. I had some nice communication with upstream which gave me some guidance for the needed removal of still not free enough licensed files and folders, which would bring in some packages could still only served by non-free. I will probably also maintain the src:ngspice package later as there are otherwise some overlapping files between both source packages. I'm in contact to the current Uploader Gudjon I. Gudjonsson about this. I will maintain this package in the pkg-electronics-team, co-maintainers are welcome! It's a build dependency for KiCad 5 which come with schematic simulation based on the libngspice library which isn't available in the non-free packages. [1] https://tracker.debian.org/pkg/ngspice [2] http://ngspice.sourceforge.net/faq.html [3] https://wiki.debian.org/KiCad/ngspice [4] https://github.com/tijuca/ngspice-dfsg
Re: Completed: lists.alioth.debian.org migration
Hello Dominic, Am 20.04.2018 um 12:21 schrieb Dominic Hargreaves: ... >> Except that we would want the forward to only forward user emails and not >> automatic emails sent by the BTS, DAK, etc. since we already get those >> through the package tracker. I'm not sure that they are willing to do >> something like this, it would require local delivery to something like >> procmail. >> >> Still I'm ccing them to get their feedback on this. > > That is not an option on alioth-lists.debian.net. It's not too late > (for a few weeks) to request late migration of lists, though. maybe i missed something, but I need to ask some further questions about this. So far I've read the overview on alioth-lists.d.n [1] the correct address to get in contact for requests like this is mail...@alioth-lists.debian.net. We have two old mailing list from the pkg-giraffe-group that aren't migrated (and we have no migration related questing found in the inbox) so I've wrote a email some days ago about this and also a wishlist's question if the lists could still be migrated targeted to this address. But I haven't a feedback yet. So, need I to be more patient or tried I the wrong contact for such late migrations? The wiki page [2] nor the information on alioth-lists.d.n [3] hold some information about how the possibilities are for such possible migrations after the main change. What need people to do with a similar situation? [1] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo [2] https://wiki.debian.org/Alioth/MailingListContinuation [3] https://alioth-lists.debian.net/ -- Regards Carsten Schoenert
Re: Completed: lists.alioth.debian.org migration
Hello Alex, Am 25.04.2018 um 10:02 schrieb Alex Muntada: > Hi Carsten, > >> So far I've read the overview on alioth-lists.d.n [1] the correct >> address to get in contact for requests like this is >> mail...@alioth-lists.debian.net. > > AFAICR it's always been admin@. In fact, I don't remember any > mention of mailman@. Where did you find that mailman address? it's the only mentioned email contact on https://alioth-lists.debian.net/cgi-bin/mailman/listinfo I suggest to change the text passage in the site then. > Maybe you missed the last announcement on d-d-annouce on this > topic: > > https://lists.debian.org/debian-devel-announce/2018/04/msg4.html I've seen and read this announcement, due some other stuff I probably don't have understand it the way it was intended. ... > The https://alioth-lists.debian.net/ lists several means of > contact with the team (salsa issues, email and irc). I'd suggest > salsa issues to better keep track of such requests. Hmm, then this is mostly different from the typical workflow by the Debian BTS. But o.k., I'll open a new issue for the migration of our lists. Thanks for answering. -- Regards Carsten Schoenert signature.asc Description: OpenPGP digital signature
Re: Firefox 60esr on Stretch ?
Hi, Am 04.05.18 um 18:38 schrieb The Wanderer: ... >> I guess so, yes. There's not much we can do if there is no support >> for newer versions. > > Though please do take note of other applications which may still work > with them. > > Even leaving other Mozilla-based browsers aside, ISTR there being (or > having been?) some extensions which would work just fine in both Firefox > and Thunderbird, and since Thunderbird is retaining XUL support - at > least for now - there may be some value in retaining such "overlap" > extensions for people who use them there. well, there is some support for legacy extensions in Thunderbird > 57.0 <= 60.x. But, the authors of such plugins need to make some adjustments within their AddOns to get them work with the upcoming TB ESR 60.x https://wiki.mozilla.org/Thunderbird/Add-ons_Guide_57 My experience right now is this is simply not happen for a significant amount of Thunderbird AddOns, all my extensions I normally want to use do not work with TB 60. So it will be a long road to walk. For Thunderbird there are probably more problems to fix. The old way of packaging XUL based extensions into /u/s/xul-ext/$extension isn't working out of the box anymore and I've no idea why nor had I time to take a deeper look at this issue. I can't speak for Firefox but I expect a similar situation here. The last FF version in Debian right now is 59.0.2. Maybe Mike can say something on this. We will also need to fix some build issues before any version uploaded to unstable can enter testing. https://bugzilla.mozilla.org/show_bug.cgi?id=1434589 -- Regards Carsten
Re: Bug#903815: ITP: pw -- A simple command-line password manager
Am 15.07.18 um 12:07 schrieb Dashamir Hoxha: > All your assertions/assumptions are wrong. > Either you did not look close enough to the code, or you are not > an expert on bash scripting (bash is a bit cryptic and difficult > to understand even for experts). Hmm, do you have tried to validate your shell code? https://www.shellcheck.net/ I just pasted https://raw.githubusercontent.com/dashohoxha/pw/master/src/pw.sh into and got quite a lot of problematic remarks. Have you test cases to prevent things Philipp has raised? The concerns Philipp mentioned are valid, creating safe shell code isn't easy and writing correct syntax isn't enough. Your ITP about password managing isn't the first of course, as far I can remember the common sense was that using Bash or any other Shell isn't the best choice for doing things like this. -- Regards Carsten Schoenert
Bug#903953: ITP: python-ilorest -- Python based library for HPE iLO RESTful API on HPE iLO 4 and iLO 5
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: python-ilorest Version : 2.3.1 Upstream Author : 2016-2018 Hewlett Packard Enterprise Restful API Group Jack Garcia Matthew Kocurek Prithvi Subrahmanya * URL : https://github.com/HewlettPackard/python-ilorest-library * License : Apache2.0 Programming Lang: Python Description : Python based library for HPE iLO RESTful API on iLO 4 and iLO 5 The Python iLO RESTful library is the platform on which the HPE RESTful tool was built on. It’s main purpose is to simplify the inband and outband communication to the HPE RESTful API. The HPE RESTful API for iLO is a RESTful application programming interface for the management of iLO and iLO Chassis Manager based HPE servers. REST (Representational State Transfer) is a web based software architectural style consisting a set of constraints that focus on a system’s resource. HPE REST library performs the basic HTTP operations GET, POST, PUT, PATCH and DELETE on resources using the HATEOS (Hypermedia as the Engine of Application) REST architecture. The API allows the clients to manage and interact with iLO through a fixed URL and several URIs. I've to deal with HPE hardware and servers mostly every day and the python library provided by HPE seems to be useful for managing mass configuration of that hardware. As HPE is one of the main contributors of the Debian project and also using hardware from HPE I guess it's worth to package this library. The source is also providing a Sphinx based documentation and some examples how to library can be used. I'm not an experienced Python library packaging person so I'm happy to find other people to co-maintain this library, talk to me on DC18 please or by email! So far I could read and study the ilorest-library isn't fully python3 ready, I'd start by packaging only the python2 variant for now. Regards Carsten
Bug#903954: ITP: sphinxcontrib-restbuilder -- Sphinx extension to build reST (reStructuredText) files
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: sphinxcontrib-restbuilder Version : 0.2 Upstream Author : 2012-2013, Freek Dijkstra (gnidan) * URL : https://github.com/sphinx-contrib/restbuilder * License : BSD-2-clause Programming Lang: Python Description : 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 package is a build dependency for python-ilorest (#903953). As for python-ilorest I'm happy to find people who interested in co-maintaining. The package should be python3 ready now since upstream made some small adjustments recently. Regards Carsten
Bug#905134: ITP: libcoap2 -- C-Implementation of CoAP, API version 2
Package: wnpp Severity: wishlist Owner: Carsten Schoenert * Package name: libcoap2 Version : 4.2.0alpha Upstream Author : Olaf Bergmann * URL : https://libcoap.net * License : BSD-2-clause Programming Lang: C Description : C-Implementation of CoAP, API version 2 Lightweight application-protocol for devices that are constrained their resources such as computing power, RF range, memory, bandwidth, or network packet sizes. This protocol, CoAP, is developed in the IETF working group "CoRE", <http://6lowapp.net> and was standardized in RFC 7252. The existing libcoap package in the archive isn't able to use any cryptography features. libcoap2 will provide an updated library which also provides encryption based on the library libssl1.1. It's planned to also support encryption based on GnuTLS at a later time. A first RC is expected to be released soon. The resulting upstream modifications to libcoap are not backwards compatible. To keep the existing library coinstallable with the current version I want to package the newest version within a separate source package. The packaging will be done within the IoT packaging group as a team managed package. Regards Carsten
Re: changing git tags on the remote repo
Hi Holger, Am 12.08.18 um 14:17 schrieb Holger Wansing: > Hi, > > Alf Gaida wrote: >> git push --tags --force - if one have the needed rights and the remote >> settings allow it. > > This goes at least so far, that I get a clear error message: > > remote: GitLab: You are not allowed to change existing tags on this project. that's a feature. Normally you don't want this and nobody can delete tags unintentionally as there is normally no reason to change history on a public git tree. The normal case is to create new tag with the according commit SHA reference. https://docs.gitlab.com/ee/user/project/protected_tags.html You can modify the behavior for your git tree, but really be careful if you remove this protection! As said, you really don't want to do this! :) -- Regards Carsten Schoenert
Re: Bug#906907: ITP: pw -- A simple command-line password manager
This is the third ITP about 'pw'. The last one has produced a longish thread on d-d. https://lists.debian.org/debian-devel/2018/07/msg00199.html The information about this new ITP says nothing about the addressed concerns from the last one. What has been changed since then that would qualify this ITP to been accepted into the archive? Am 22.08.18 um 06:32 schrieb Dashamir Hoxha: > Package: wnpp > Severity: wishlist > > Description: > A simple command-line password manager that keeps passwords inside a > gpg encrypted tgz archive. The content of the archive is a directory tree > with a file for each password entry. The first line of the file is the > password, and the rest can optionally be additional or related info. > It provides commands for manipulating the passwords, allowing the user > to add, remove, edit, generate passwords etc. > > Repository: https://gitlab.com/dashohoxha/pw > Documentation: https://dashohoxha.gitlab.io/pw/man/ > https://bugs.debian.org/903814 https://bugs.debian.org/903814 https://bugs.debian.org/906907 -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Hello, Am 19.02.2017 um 07:12 schrieb Josh Triplett: > Mike Hommey wrote: >> Why not just create a ~/.thunderbird symlink to ~/.icedove if >> ~/.icedove exists? > > This seems like the right solution. (Or, equivalently, rename > ~/.icedove to ~/.thunderbird and place a symlink in the other > direction.) > > Any particular reason not to do this? given to the feedback on the list and BTS we will change the current behavior to "just" symlink to ~/.icedove. While starting the process of the package migration we (mostly me) was worry about we have to do much more changes inside a users profile and it would be good to have a full backup. But now it turns out it isn't that much. I'd like to thank all the people who gave us suggestions and helpful feedback in the past days and weeks! We can make Thunderbird great again in Debian. :-) -- Regards Carsten Schoenert
Re: De-Branding of Icedove, reintroducing Thunderbird packages into Debian
Hello Lionel, Am 21.02.2017 um 11:38 schrieb Lionel Elie Mamane: > If home directories are shared between machines, one machine has > icedove and the other thunderbird, will they collaborate decently on > the same profile directory? this should work as the "real" old Icedove packages uses ~/.icedove and Thunderbird now uses ~/.thunderbird as default. But that you probably wont do. You probably want to use Icedove on one machine and Thunderbird on another machine and you want to use the profile folder for booth, that will also work if you use versions that not differ that much. The best would be to only Thunderbird or only Icedove with the same version. Combining usage of booth profile folders with symlinking is the thing we currently talk about to not copy .icedove into .thunderbird. -- Regards Carsten Schoenert
Re: Ambientcapabilities - solved was: (Re: thoughts about freeradius package (especially dhcp))
Hello Kamil, Am 05.09.2017 um 05:04 schrieb Kamil Jońca: > kjo...@poczta.onet.pl (Kamil Jońca) writes: > >> Russ Allbery writes: >> >>> kjo...@poczta.onet.pl (Kamil Jońca) writes: >>> >>>> Hm. I tried to add >>> >>>> AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE > > It was my fault. > I used > #setcap "" /usr/sbin/freeradius > > but I should > #setcap -r /usr/sbin/freeradius > > Now all works as expected. could you please add your information about the changes to the wiki please? Maybe a now paragraph on the Hardening site? I'm not sure if this is the right place for this but content can be moved anyways later. https://wiki.debian.org/Hardening -- Regards Carsten Schoenert
