Bug#982417: Python louvain packages naming confusion.
On Wed, 2021-02-10 at 01:49 +, Paul Wise wrote: > On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > > > The fairly popular (in the world of bioinformatics) ScanPy package > > uses > > a Python version of the louvain clustering algorithm implemented > > by: > ... > > However currently in the Debian archive there's a different louvain > > package > > I think this is something that the two upstream projects should > discuss and come to an agreement on the right outcome, since the > current set of names is confusing and overlapping. Perhaps the two > projects will end up getting merged into one project, or one of them > deprecated or one or both of them renamed. >From the perspective of pypi. One is "louvain" (which installs into "louvain" and one is "python- louvain", which installs into "community". If you're using pip you can easily install both of them if you want. > > > I was wondering if the python3-louvain's binary package should be > > renamed to python3-community to match the python package name, and > > then > > the other louvain-igraph package could provide a bin package named > > python3-louvain which would match the package name. > > There are no reverse dependencies in Debian, but this is going to be > tricky for users who previously installed python3-louvain.deb from > python-louvain upstream and then after upgrading they suddenly get > python3-louvain.deb from louvain-igraph with presumably an > incompatible API etc. > Cleaning it up seemed hard. Currently the version python3-louvain in unstable based on python- louvain is 0.0+20181013git3fc1f575 and the current upstream version is 0.15. For the louvain igraph package their current version is 0.7.0. At the very least, the current python3-louvain package needs to be renamed to python3-community to meet python policy and to make the CI autodep8 import test work. So that seems like make a new release of python-louvain using the 0.0git convention with a transition package that depends on a new python3-community package. And then leave that alone for "a while". At some point then the new python3-louvain package based on the louvain igraph module could have a check in the maintainer script to tell the user to switch to python3-community if it's the older python-louvain version. Once the packages are renamed then the python-louvain version could switch from the 0.0git convetion to the pypi version. (Upstream didn't bother to put tags on github, so the only version numbers come from pypi). I have no idea how long the transition package should sit around for though. Diane
Bug#982402: marked as done (Firmware needs prober)
Your message dated Wed, 10 Feb 2021 04:45:47 +0300 with message-id <1436711612921...@mail.yandex.ru> and subject line Re: Firmware needs prober has caused the Debian Bug report #982402, regarding Firmware needs prober to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 982402: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982402 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Sure, one can install all the firmware-* packages in Debian, and thus be sure one has all the firmware one needs. However that is a big waste. Many megabytes of wasted updates for who knows what, some IBM printer from 1967, who knows? Therefore there should be a package, that probes the system, to see exactly what firmware packages one really needs. Yes, it needs to be a highly specialized script that knows what kinds of places to probe for what. (like lshw.) And in its man page it needs to say "turn on / plug in all your devices for best results." Sure, a lot of firmware needs just cannot be probed, and one must wait for problems to occur before one starts searching Google with the symptoms, finally finding the answer, hopefully. Yes, it would be nice if each hardware that needed firmware could be probed in a standard way so that it would respond saying what firmware it needed. Etc. --- End Message --- --- Begin Message --- Hi, This part of BTS is devoted to packaging of already existing software. If there is software which may be used as you described, then you may open correct RFP bug report for packaging it. If there is no such software you may discuss your ideas in debian-de...@lists.debian.org mailing list. And maybe someone will be interested enough to implement them in code. [1] https://lists.debian.org/debian-devel/2021/02/maillist.html Best wishes, Boris--- End Message ---
Bug#982417: Python louvain packages naming confusion.
On Tue, Feb 9, 2021 at 10:21 PM Diane Trout wrote: > The fairly popular (in the world of bioinformatics) ScanPy package uses > a Python version of the louvain clustering algorithm implemented by: ... > However currently in the Debian archive there's a different louvain > package I think this is something that the two upstream projects should discuss and come to an agreement on the right outcome, since the current set of names is confusing and overlapping. Perhaps the two projects will end up getting merged into one project, or one of them deprecated or one or both of them renamed. > I was wondering if the python3-louvain's binary package should be > renamed to python3-community to match the python package name, and then > the other louvain-igraph package could provide a bin package named > python3-louvain which would match the package name. There are no reverse dependencies in Debian, but this is going to be tricky for users who previously installed python3-louvain.deb from python-louvain upstream and then after upgrading they suddenly get python3-louvain.deb from louvain-igraph with presumably an incompatible API etc. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#928970: marked as done (RFP: jj -- FIFO-based jabber client)
Your message dated Wed, 10 Feb 2021 03:16:39 +0300 with message-id <102201612916...@mail.yandex.ru> and subject line Close bug has caused the Debian Bug report #928970, regarding RFP: jj -- FIFO-based jabber client to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 928970: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928970 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Homepage: https://23.fi/jj jj is simple FIFO and filsystem-based Jabber client. It was inspired by "ii" IRC client. pgpfc5eX6OAqA.pgp Description: PGP signature --- End Message --- --- Begin Message --- Dead link to the project + too basic name of project for searching.--- End Message ---
Bug#740741: marked as done (RFP: xmpp-client -- console XMPP client written in pure Go.)
Your message dated Wed, 10 Feb 2021 03:05:12 +0300 with message-id <31361612915...@mail.yandex.ru> and subject line Close bug has caused the Debian Bug report #740741, regarding RFP: xmpp-client -- console XMPP client written in pure Go. to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 740741: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740741 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Owner: Jacob Appelbaum * Package name: xmpp-client Version : 0.1~20140304-1 Upstream Author : Adam Langley * URL : http://www.github.com/agl/xmpp * License : BSD Programming Lang: Golang Description : console XMPP client written in pure Go. xmpp-client is a minimal console instant messaging client for the XMPP protocol. It supports Off-The-Record encryption natively and may optionally use Tor or connect to XMPP servers hosted as Tor Hidden Services. . --- End Message --- --- Begin Message --- Project does not exist anymore.--- End Message ---
Bug#887799: RFP: atomtopubsub -- parse Atom feeds and send them to XMPP PubSub nodes
Original project looks dead, but there is an active fork: https://github.com/edhelas/atomtopubsub/network https://github.com/imattau/atomtopubsub
Bug#892384: marked as done (RFP: jabbercat -- modern XMPP client)
Your message dated Wed, 10 Feb 2021 02:55:34 +0300 with message-id <1416331612914...@mail.yandex.ru> and subject line Close bug has caused the Debian Bug report #892384, regarding RFP: jabbercat -- modern XMPP client to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 892384: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892384 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist Package name: jabbercat Version : git snapshot 2018-03-08 Upstream Author : Jonas Wielicki URL : https://jabbercat.org/ License : GPL3 Programming Lang: Python (with Qt5) Description : modern XMPP client "If you are intrigued by the User Experience provided by modern, non-XMPP and/or non-free chat applications, this is for you. We aim to provide Conversations-like chat experience based on XMPP on the Desktop!" This is pretty much a work in progress and should be packaged only for experimental for now. --- End Message --- --- Begin Message --- Project looks dead: https://github.com/jabbercat/jabbercat/commits/devel https://github.com/jabbercat/jabbercat/network--- End Message ---
Processed: Fix titles
Processing commands for cont...@bugs.debian.org:
> retitle 974678 RFP: openh264 -- H.264 encoding and decoding
Bug #974678 [wnpp] RFP: openh264 - H.264 encoding and decoding
Changed Bug title to 'RFP: openh264 -- H.264 encoding and decoding' from 'RFP:
openh264 - H.264 encoding and decoding'.
> retitle 700412 O: kst -- A KDE application used for displaying scientific data
Bug #700412 [wnpp] O: kst -- A KDE application used for displaying
Changed Bug title to 'O: kst -- A KDE application used for displaying
scientific data' from 'O: kst -- A KDE application used for displaying'.
> retitle 808074 O: fbreader -- e-book reader
Bug #808074 [wnpp] RFA: fbreader -- e-book reader
Changed Bug title to 'O: fbreader -- e-book reader' from 'RFA: fbreader --
e-book reader'.
> retitle 980433 ITP: buf -- Better way to work with Protocol Buffers
Bug #980433 [wnpp] ITP: buf --
Changed Bug title to 'ITP: buf -- Better way to work with Protocol Buffers'
from 'ITP: buf -- '.
> retitle 944878 O: palabos -- CFD solver based on the lattice Boltzmann method
Bug #944878 [wnpp] O: palabos
Changed Bug title to 'O: palabos -- CFD solver based on the lattice Boltzmann
method' from 'O: palabos'.
> retitle 881910 ITA: libcdio-paranoia -- library to read and control digital
> audio CDs
Bug #881910 [wnpp] ITA: libcdio-paranoia
Changed Bug title to 'ITA: libcdio-paranoia -- library to read and control
digital audio CDs' from 'ITA: libcdio-paranoia'.
> retitle 914035 RFA: influxdb -- Scalable datastore for metrics, events, and
> real-time analytics
Bug #914035 [wnpp] RFA: influxdb
Changed Bug title to 'RFA: influxdb -- Scalable datastore for metrics, events,
and real-time analytics' from 'RFA: influxdb'.
> retitle 969001 O: python-asynctest -- unittest extension for testing asyncio
> libraries
Bug #969001 [wnpp] O: python-asynctest
Changed Bug title to 'O: python-asynctest -- unittest extension for testing
asyncio libraries' from 'O: python-asynctest'.
> retitle 970377 ITA: python-libtrace -- Python bindings for the libtrace API
Bug #970377 [wnpp] ITA: python-libtrace
Changed Bug title to 'ITA: python-libtrace -- Python bindings for the libtrace
API' from 'ITA: python-libtrace'.
> retitle 974914 ITA: cdrkit -- collection of computer programs for CD and DVD
> authoring
Bug #974914 [wnpp] ITA: cdrkit
Changed Bug title to 'ITA: cdrkit -- collection of computer programs for CD and
DVD authoring' from 'ITA: cdrkit'.
> retitle 975985 ITA: geda-gaf -- Electronics design software
Bug #975985 [wnpp] ITA: geda-gaf
Changed Bug title to 'ITA: geda-gaf -- Electronics design software' from 'ITA:
geda-gaf'.
> retitle 976707 O: kopanocore -- Complete and feature rich groupware solution
Bug #976707 [wnpp] O: kopanocore - Complete and feature rich groupware solution
Changed Bug title to 'O: kopanocore -- Complete and feature rich groupware
solution' from 'O: kopanocore - Complete and feature rich groupware solution'.
> retitle 976708 O: kopano-webapp -- WebApp for the Kopano Collaboration
> Platform
Bug #976708 [wnpp] O: kopano-webapp - WebApp for the Kopano Collaboration
Platform
Changed Bug title to 'O: kopano-webapp -- WebApp for the Kopano Collaboration
Platform' from 'O: kopano-webapp - WebApp for the Kopano Collaboration
Platform'.
> retitle 976709 O: kopano-webapp-plugins-files -- Kopano WebApp plugin for
> managing attachments
Bug #976709 [wnpp] O: kopano-webapp-plugins-files - Kopano WebApp plugin for
managing attachments
Changed Bug title to 'O: kopano-webapp-plugins-files -- Kopano WebApp plugin
for managing attachments' from 'O: kopano-webapp-plugins-files - Kopano WebApp
plugin for managing attachments'.
> retitle 976710 O: z-push -- open source implementation of the ActiveSync
> protocol
Bug #976710 [wnpp] O: z-push - open source implementation of the ActiveSync
protocol
Changed Bug title to 'O: z-push -- open source implementation of the ActiveSync
protocol' from 'O: z-push - open source implementation of the ActiveSync
protocol'.
> retitle 977266 O: python-bsddb3 -- Python interface for Berkeley DB
Bug #977266 [wnpp] O: python-bsddb3 - Python interface for Berkeley DB
Changed Bug title to 'O: python-bsddb3 -- Python interface for Berkeley DB'
from 'O: python-bsddb3 - Python interface for Berkeley DB'.
> retitle 975732 ITP: xmppc -- command line xmpp client
Bug #975732 {Done: Stefan Kropp } [wnpp] ITP: xmppc -
command line xmpp client
Changed Bug title to 'ITP: xmppc -- command line xmpp client' from 'ITP: xmppc
- command line xmpp client'.
> retitle 720456 ITP: solarized -- solarized colorscheme for Vim
Bug #720456 {Done: Marco Villegas } [wnpp] ITP: solarized
colorscheme for Vim
Changed Bug title to 'ITP: solarized -- solarized colorscheme for Vim' from
'ITP: solarized colorscheme for Vim'.
> retitle 981140 ITP: xbanish -- banish the mouse cursor when typing, show it
> again when the mouse moves
Bug #981140 {Done: Scupake } [wnpp] ITP: xbanish: banish
the mouse cursor when typing, show it again when the
Bug#982417: Python louvain packages naming confusion.
Hello, The fairly popular (in the world of bioinformatics) ScanPy package uses a Python version of the louvain clustering algorithm implemented by: https://github.com/vtraag/louvain-igraph https://pypi.org/project/louvain/ which installs into the "louvain" dist-packages directory. (from debc) ./usr/lib/python3/dist-packages/louvain/ I have it mostly packaged However currently in the Debian archive there's a different louvain package https://github.com/taynaud/python-louvain https://pypi.org/project/python-louvain/ https://salsa.debian.org/python-team/packages/python-louvain It installs into (according to debc) ./usr/lib/python3/dist-packages/community/ Unfortunately for this package we now automatically run autodep8 which fails because the import name is community and not louvain. autopkgtest [13:29:03]: test autodep8-python3: set -e ; for py in $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import louvain; print(louvain)" ; done autopkgtest [13:29:03]: test autodep8-python3: [--- Testing with python3.9: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'louvain' autopkgtest [13:29:03]: test autodep8-python3: ---] autopkgtest [13:29:03]: test autodep8-python3: - - - - - - - - - - results - - I think having a python3-louvain-igraph package which installs into louvain, while there is a separate python3-louvain package which installs into community is really confusing. I was wondering if the python3-louvain's binary package should be renamed to python3-community to match the python package name, and then the other louvain-igraph package could provide a bin package named python3-louvain which would match the package name. But this is clearly a thing that needs to be discussed. Diane
Bug#982417: ITP: python-louvain-igraph -- Louvain is an algorithm for methods of community detection
Package: wnpp Severity: wishlist Owner: Diane Trout X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-louvain-igraph Version : 0.7.0 Upstream Author : V.A. Tragg * URL : https://github.com/vtraag/louvain-igraph * License : GPL-3+ Programming Lang: (Python Description : Louvain is an algorithm for methods of community detection Louvain is a general algorithm for methods of community detection in large networks. . This provides a python module named 'louvain'. This is the version of louvain used by ScanPy https://scanpy.readthedocs.io/en/stable/ It's also based on igraph and not networkx like the other louvain implementation python-louvain. It should probably live in the Debian med team.
Bug#972573: marked as done (RFP: crowdsec -- lightweight and collaborative security engine)
Your message dated Tue, 9 Feb 2021 21:12:09 +0200 with message-id <20210209191209.GA31529@localhost> and subject line crowdsec is now in unstable has caused the Debian Bug report #972573, regarding RFP: crowdsec -- lightweight and collaborative security engine to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 972573: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972573 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: wnpp Severity: wishlist * Package name: crowdsec Version : 0.3.5 Upstream Author : Crowd Security * URL : https://crowdsec.net/ * License : MIT/Expat? Programming Lang: Golang Description : lightweight agent to detect and respond to bad behaviours Crowdsec is an open-source, lightweight software, detecting peers with aggressive behaviors to prevent them from accessing your systems. Its user friendly design and assistance offers a low technical barrier of entry and nevertheless a high security gain. Processing is done in 5 steps: 1. Read Data sources (log files, streams, trails, messages ...), normalize and enrich signals 2. Matching those signals to behavior patterns, aka scenarios (*) 3. If an unwanted behavior is detected, deal with it through a bouncer : a software component integrated into your applicative stack that supports various remediations such as block, return 403, and soon captcha, 2FA, etc. 4. (ONLY) The aggressive IP, the scenario name triggered and a timestamp is then sent to our curation platform (to avoid poisoning & false positives) 5. If verified, this IP is then integrated to the block list continuously distributed to all CrowdSec clients (which is used as an enrichment source in step 1) By detecting, blocking and sharing the threat they faced, all clients are reinforcing each-others (hence the name Crowd-Security). Crowdsec is designed for modern infrastructures, with its "Detect Here, Remedy There" approach, letting you analyse logs coming from several sources in one place and block threats at various levels (applicative, system, infrastructural) of your stack. (*) CrowdSec ships by default with scenario (brute force, port scan, web scan, etc.) adapted for most context, but you can easily extend it by picking more of them from the hub. It is also very easy to adapt an existing one or create one yourself. This is similar to fail2ban and sshguard, but with the extra touch that it allows for federation and distribution of blocklists. It also integrates with Prometheus, also packaged in Debian. I haven't tested it. I guess it could be maintained by the Go team? Source code is available here: https://github.com/crowdsecurity/crowdsec The software is free (MIT), but to get access to the crowd-sourced reputation data, you must also share it. The server-side of things is also non-free. --- End Message --- --- Begin Message --- crowdsec is now in unstable: https://tracker.debian.org/pkg/crowdsec cu Adrian--- End Message ---
Bug#982402: Firmware needs prober
Package: wnpp Severity: wishlist Sure, one can install all the firmware-* packages in Debian, and thus be sure one has all the firmware one needs. However that is a big waste. Many megabytes of wasted updates for who knows what, some IBM printer from 1967, who knows? Therefore there should be a package, that probes the system, to see exactly what firmware packages one really needs. Yes, it needs to be a highly specialized script that knows what kinds of places to probe for what. (like lshw.) And in its man page it needs to say "turn on / plug in all your devices for best results." Sure, a lot of firmware needs just cannot be probed, and one must wait for problems to occur before one starts searching Google with the symptoms, finally finding the answer, hopefully. Yes, it would be nice if each hardware that needed firmware could be probed in a standard way so that it would respond saying what firmware it needed. Etc.
Bug#982341: ITP: simlib -- SIMulation LIBrary for C++
It looks interesting. Unfortunately, the description is somewhat hard to understand. On Tue, Feb 09, 2021 at 03:03:51AM +0100, Roman Ondráček wrote: > This library allows you to create models directly in C++ language using > simulation abstractions and tools from the library. > SIMLIB allows object-oriented description of continuous, discrete, combined, > and various experimental (2D/3D vector, fuzzy) models. Simulation of what? Abstraction from what? I am just a random one of 1000 or so Debian Developers, so if I offer a suggestion, you can regard or ignore as you like. I gather that the package does some kind of time-domain, frequency-domain, eigenvalue, integral-equation, or other kind of mechanical simulation for purpose of checking analyses and for other purposes. However, I gather this only because I happen to have done work of this general kind. Consider adding a brief introductory sentence that orients the reader to the *kind* of thing the package is or does. For example, suppose that the user were looking for libcairo (to generate 2-D graphics) or libunbound (to resolve Internet domain names). Your description's first line should probably, very briefly, inform the reader that your library is not the kind of library such a user seeks. Also consider writing, "C++ library" rather than "library ... in C++," at your discretion. For example, your description *might* begin: SIMLIB is C++ library that models [foo] using continuous, discrete and combined techniques. Or, for less accuracy but more punch: SIMLIB is C++ library that models continuous, discrete and combined [foo]. I like that your description is short. signature.asc Description: PGP signature
Bug#982378: ITP: libmoox-thunking-perl -- Allow Moo attributes to be "thunked"
Package: wnpp Owner: Andrius Merkys Severity: wishlist * Package name: libmoox-thunking-perl Version : 0.08 Upstream Author : Ed J * URL : https://metacpan.org/release/MooX-Thunking * License : Artistic-2.0 Programming Lang: Perl Description : Allow Moo attributes to be "thunked" MooX::Thunking is a Moo extension allowing another value for the "is" parameter to "has" in Moo: "thunked". If used, this will allow you to transparently provide either a real value for the attribute, or a "CodeLike" in Types::TypeTiny that when called will return such a real value. This package is a dependency of GraphQL, which I intend to eventually package. Remark: This package is to be maintained with Debian Perl Group at https://salsa.debian.org/perl-team/modules/packages/libmoox-thunking-perl Andrius
Processed: bts
Processing commands for cont...@bugs.debian.org: > retitle 951837 ITP: netdata-go.d.plugin -- netdata plugins written in Go Bug #951837 [wnpp] ITP: netdata-go.d -- plugins for netdata written in Go Changed Bug title to 'ITP: netdata-go.d.plugin -- netdata plugins written in Go' from 'ITP: netdata-go.d -- plugins for netdata written in Go'. > thanks Stopping processing here. Please contact me if you need assistance. -- 951837: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951837 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: bts
Processing commands for cont...@bugs.debian.org: > close 982200 Bug #982200 [wnpp] ITP: athenacli -- CLI client for AWS Athena Marked Bug as done > thanks Stopping processing here. Please contact me if you need assistance. -- 982200: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982200 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#982250: TAG: mmsd-mm -- mmsd is a lower level daemon that transmits and recieves MMSes. It works with both the ofono stack and the Modem Manager stack. This packaging only works with modem manager
Good Morning Evanelgos, I agree with you! I think this would be excellent to have the DebianOnMobile team to maintain. I have been working with several memebers of that team to get it packaged for Debian (which has been greatly appreciated!). I also want to call out that I have contacted the upstream devs to get my patches into upstream: https://lists.ofono.org/hyperkitty/list/of...@ofono.org/thread/CVOWCDC7H4G4F3N4RTUPPLOTJQ7LCHDY/ However, in an unrelated conversation with their team, they mentioned that mmsd upstream has not been maintained in at least 8 years. I mention this because I would appreciate guidance on the best course of action in case the patches do not get upstreamed (hope for the best, prepare for the worst). -- Respectfully, Chris Talbot On Tue, 2021-02-09 at 12:57 +0100, Evangelos Ribeiro Tzaras wrote: > Hi Christopher, > > Package: wnpp > > Severity: ITP > > > > mmsd-mm mmsd is a lower level daemon that transmits and recieves > > Multimedia Service Messages. It works with both the ofono stack and > > the > > Modem Manager stack. This packaging only works with modem manager. > > > > The original upstream is here: > > https://git.kernel.org/pub/scm/network/ofono/mmsd.git > > > > and my package is maintained here: > > > > https://source.puri.sm/kop316/mmsd/ > > > > The "Master" Branch is the same as the upstream branch: > > https://source.puri.sm/kop316/mmsd/-/tree/master > > > > and all of my patches are maintained in the "ModemManager" branch: > > https://source.puri.sm/kop316/mmsd/-/tree/ModemManager > > > > The Debian packaging is here: > > https://source.puri.sm/kop316/mmsd/-/tree/debian/modemmanager/latest > > > > To the submitter's knowledge, no other package exists that does > > this, > > and MMSD is not packaged for Debian. In addition, to the > > submitter's > > knowledge, no stack exists in Modem Manager that supports MMS. > > > > As of now, the submitter has been working primarily alone, but has > > had > > the support of both the Mobian community and the Purism Community. > > The > > Submitter will welcome co-maintainers, especially for the Ofono > > side of > > the packaging/testing. > > I think this would be a good candidate for maintaining as a part of > the > DebianOnMobile-team [0]. > > > [0] https://salsa.debian.org/DebianOnMobile-team > > > -- > Cheers, > Evangelos
Bug#982250: TAG: mmsd-mm -- mmsd is a lower level daemon that transmits and recieves MMSes. It works with both the ofono stack and the Modem Manager stack. This packaging only works with modem manager
Hi Christopher, Package: wnpp Severity: ITP mmsd-mm mmsd is a lower level daemon that transmits and recieves Multimedia Service Messages. It works with both the ofono stack and the Modem Manager stack. This packaging only works with modem manager. The original upstream is here: https://git.kernel.org/pub/scm/network/ofono/mmsd.git and my package is maintained here: https://source.puri.sm/kop316/mmsd/ The "Master" Branch is the same as the upstream branch: https://source.puri.sm/kop316/mmsd/-/tree/master and all of my patches are maintained in the "ModemManager" branch: https://source.puri.sm/kop316/mmsd/-/tree/ModemManager The Debian packaging is here: https://source.puri.sm/kop316/mmsd/-/tree/debian/modemmanager/latest To the submitter's knowledge, no other package exists that does this, and MMSD is not packaged for Debian. In addition, to the submitter's knowledge, no stack exists in Modem Manager that supports MMS. As of now, the submitter has been working primarily alone, but has had the support of both the Mobian community and the Purism Community. The Submitter will welcome co-maintainers, especially for the Ofono side of the packaging/testing. I think this would be a good candidate for maintaining as a part of the DebianOnMobile-team [0]. [0] https://salsa.debian.org/DebianOnMobile-team -- Cheers, Evangelos
Processed: retitle 900958 to ITP: barebox -- bootloader and its host tools
Processing commands for cont...@bugs.debian.org: > retitle 900958 ITP: barebox -- bootloader and its host tools Bug #900958 [wnpp] ITP: itp bootloader and its host tools Changed Bug title to 'ITP: barebox -- bootloader and its host tools' from 'ITP: itp bootloader and its host tools'. > thanks Stopping processing here. Please contact me if you need assistance. -- 900958: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900958 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#981913: ITP: ognibuild -- Wrapper with common interface for invoking any kind of build tool
Hi Jelmer, On 2021-02-05 17:55, Jelmer Vernooij wrote: > ognibuild provides no such guarantees and newer versions > may behave slightly differently, as support for more build systems is > added or tweaked. debhelper is specific Debian, ognibuild is > not. Thanks for the detailed description. I see benefit in having non-Debian-specific generic builder. Best, Andrius
